CSR

Client-Side Rendering

Updated September 30, 20262 min read

In short

CSR is a rendering approach where the browser downloads a mostly empty HTML page plus JavaScript, then builds the page content on the user's device.

What is CSR?

With client-side rendering, the server sends a minimal HTML file, often little more than an empty <div id="root"></div>, together with a JavaScript bundle. The browser downloads and runs that JavaScript, which fetches data from an API and creates the page content by building the DOM directly on the user's device.

CSR is the classic way single-page applications work. After the first load, navigation is fast because only data needs to travel over the network, and the server can be a simple static file host or CDN. That makes CSR a good fit for highly interactive apps behind a login, such as dashboards, editors, and admin panels.

The main drawback is the first load. Users see a blank screen or a spinner until the JavaScript has downloaded and run, which is especially slow on low-end phones and poor networks. Crawlers that do not run JavaScript, including many AI crawlers, may see only the empty shell, which hurts SEO.

CSR, SSR, and SSG differ mainly in where and when the HTML is built. With CSR it is built in the browser when the page is viewed, with SSR on the server for each request, and with SSG on a build machine ahead of time. Many modern sites mix all three, for example static marketing pages, server-rendered product pages, and a client-rendered account dashboard.

Key takeaways

CSR builds the page in the browser with JavaScript.
The server sends a minimal HTML shell and a script bundle.
Navigation after the first load is fast and needs only data.
The first load is slower, and crawlers that skip JavaScript see little content.
CSR renders in the browser, SSR on the server per request, and SSG at build time.

Example

A page rendered entirely in the browserhtml

<!-- What the server sends: an empty shell and a script -->
<body>
  <ul id="app">Loading...</ul>
  <script type="module">
    // The browser fetches data and builds the content itself
    const res = await fetch("/api/products");
    const products = await res.json();
    const items = products.map((p) => {
      const li = document.createElement("li");
      li.textContent = p.name;
      return li;
    });
    document.querySelector("#app").replaceChildren(...items);
  </script>
</body>

Readers ask

What is the difference between CSR and SSR?

With CSR, the browser receives an almost empty page and builds the content with JavaScript. With SSR, the server sends finished HTML for each request, so content appears sooner and crawlers can read it without running scripts.

Is client-side rendering bad for SEO?

It can be. Google can render JavaScript, but indexing may be delayed, and many other crawlers, including AI crawlers, read only the initial HTML. Pages that need to rank in search are usually rendered with SSR or SSG instead.

When should I use client-side rendering?

CSR suits highly interactive pages that do not need to appear in search results, such as dashboards, admin panels, and tools behind a login. For public content pages, SSR or SSG usually gives a faster first view.

Often compared

SSR vs CSRServer-side rendering (SSR) builds full HTML on the server for each request, so content shows fast, while CSR builds the page in the browser with JavaScript.

CSR