What Is Client-Side Rendering?

How Client-Side Rendering Works

In client-side rendering, defined by the Chrome team as “rendering an app in a browser, using JavaScript to modify the DOM,” the server’s job is minimal. It returns a bare HTML document — often little more than a <div id="root"> and a <script> tag — and the browser does the rest. It downloads the JavaScript bundle, parses and executes it, fetches any data the app needs from an API, and only then constructs the DOM the user sees. The page you view is assembled in place, milliseconds or seconds after the HTML arrives.

This model is the default for single-page applications built with frameworks like React, Angular, and Vue. It has real strengths: after the initial load, navigation between views feels instant because the app updates the DOM without round-trips to the server, and the server itself stays cheap because it isn’t generating HTML per request. The tradeoff is front-loaded. Time to first byte is fast, but First Contentful Paint is slow, because a user stares at a blank shell until the bundle finishes running. On low-end mobile devices, a heavy bundle also pushes out Time to Interactive, the point at which the page actually responds to input.

For search, CSR reframes the whole indexing question. The content a crawler wants doesn’t exist in the server response — it exists only after the crawler renders the page. Googlebot does render JavaScript, but in a deferred queue, which introduces both delay and the possibility that the render comes back incomplete. That is the entire reason JavaScript SEO exists as a discipline.

Why CSR Complicates Indexing

Three failure modes recur with client-side rendered sites:

• The empty-shell index. If the render is delayed or a script errors on Googlebot’s Chromium, the crawler may index the near-empty HTML it first received rather than the finished page.
• Undiscoverable routes. CSR apps that navigate via onclick handlers or # fragments instead of real <a href> links give the crawler nothing to follow, so deep pages never get found.
• Blocked or race-condition metadata. Canonical tags, robots directives, and titles injected by JavaScript arrive after the initial parse. If a crawler acts on the first HTML, it acts on the wrong tags.

Example of Client-Side Rendering

The canonical documented account of CSR and its costs comes from “Rendering on the Web,” the reference article by Google engineers Addy Osmani and Jason Miller, first published in February 2019 and maintained since. It lays out the rendering spectrum from fully server-rendered to fully client-rendered and is explicit about where CSR sits. The article defines client-side rendering as building the app in the browser via JavaScript, and it documents the specific performance shape: CSR tends toward a fast TTFB but a slower FCP and, with large bundles, a worse TTI, because “getting large JavaScript payloads” to run is what gates interactivity.

The article’s SEO framing is the load-bearing part for practitioners. It notes that client-side rendered content “works but needs testing,” because crawlers have limitations, while server-rendered HTML “delivers a complete experience to crawlers.” That is not a company case study with invented numbers; it is the documented consensus position from the team that builds Chrome, and it is why the same guidance recommends moving work back toward the server — through server-side rendering, static rendering, or hydration — whenever content needs to be reliably discoverable. The generalizable lesson is simple: CSR optimizes for the returning, JavaScript-capable user, and search engines are neither of those things by default.

Client-Side Rendering vs Server-Side Rendering

The two are ends of a spectrum, not enemies. Many production sites use server-side rendering or prerendering for the first paint and then hydrate into a client-side app for subsequent interactions, capturing most of the SEO safety of SSR with the navigation feel of CSR.

Frequently Asked Questions

The Bottom Line

Client-side rendering hands the browser an empty stage and a script, and trusts it to build the scene. It keeps servers cheap and interactions snappy once loaded, but it makes the content conditional on JavaScript running — for users on slow devices and for crawlers rendering in a queue. When search visibility matters, the safer pattern is to deliver meaningful HTML from the server and use client-side JavaScript to enhance it, not to produce it from scratch.