Client-Side Rendering (CSR): Definition and Trade-offs

What is client-side rendering (CSR)?

Client-side rendering (CSR) means the browser builds the page's HTML with JavaScript instead of receiving it finished from the server. The server sends a small HTML shell and a JavaScript bundle; the script fetches data, usually from an API, and creates the content in the DOM. MDN defines it as the opposite of server-side rendering, and notes the two can be combined in one application.

How client-side rendering works

1. The browser requests a URL and receives a minimal HTML document, often just an empty container element and script tags.
2. It downloads, parses and runs the JavaScript bundle.
3. The app requests its data from an API.
4. The app builds the DOM and the user sees the content.
5. Later navigation stays in the browser: the app swaps views and fetches only data, not whole pages. This is how a single-page app works.

Example

A dashboard built with React loads an HTML file of a few hundred bytes. The visitor sees a blank page or spinner until the bundle has loaded, the API has answered and the charts have been drawn. Clicking between tabs afterwards feels instant, because only JSON travels over the network.

Advantages

• Fast in-app navigation. After the first load, views change without a full page reload.
• Rich interactivity. Dashboards, editors and tools suit an app that lives in the browser.
• Simple hosting. The shell and bundle are static files that any CDN can serve; only the API needs servers.

Drawbacks

• Slower first content. Nothing meaningful appears until JavaScript has run. web.dev notes that the amount of JavaScript tends to grow with the app, which can hurt INP, and that CSR can be hard to keep fast on mobile devices.
• SEO needs care. Google processes JavaScript pages in three phases: crawling, rendering and indexing. Pages wait in a render queue, "a few seconds, but it can take longer" (Google Search Central). Google also says server-side or pre-rendering is still a great idea, because not all bots run JavaScript.
• Depends on the device. Parsing and running a large bundle takes more time on a slow phone than on a developer laptop.

Common mistakes

• Shipping one huge bundle. Split code by route and lazy-load what the first screen does not need.
• Fetching data in a waterfall. A component that waits for its parent to load before requesting its own data adds a full round trip per level.
• Putting noindex in the HTML shell and removing it with JavaScript. Google says it may skip rendering when it sees noindex, so the removal may never run.
• Testing only on fast hardware. Check with throttled CPU and network, or on real mid-range devices.
• Skipping meaningful HTML for key pages. Marketing and content pages usually do better with static generation or server rendering, and a client-rendered app behind the login.

CSR, SSR and SSG compared

The choice is about when the HTML is produced. Rendering can happen in the browser (CSR), on each request on the server (SSR) or at build time (SSG). Frameworks such as Next.js mix them per page, and hydration then makes server-produced HTML interactive. A public page that must be found in search is a poor fit for pure CSR; a logged-in tool often is a good one.

Testing and monitoring a CSR app

Lab and field numbers matter because the browser does the work. LoadFocus page speed monitoring runs scheduled Lighthouse audits and Core Web Vitals checks from 25 cloud regions and alerts you when a page slows down; the Core Web Vitals checker gives a one-off reading, and the guide to monitoring Core Web Vitals with alerts and reports covers the setup. The API behind the app is a separate concern: a JMeter or k6 load test exercises its endpoints, not the browser rendering.

FAQ: Client-side rendering

What is the difference between CSR and SSR?

With CSR the browser builds the HTML using JavaScript. With SSR the server sends HTML that is already built for that request. SSR usually shows content sooner; CSR makes later navigation inside the app quicker.

Is client-side rendering bad for SEO?

Not automatically. Google can render JavaScript, but pages wait in a render queue and not all bots run scripts. For pages that must rank, server rendering or pre-rendering is the safer choice.

Which frameworks use client-side rendering?

React, Angular and Vue all build single-page apps that render in the browser by default. Meta-frameworks such as Next.js and Nuxt add server rendering and static generation on top.

Does CSR hurt Core Web Vitals?

It can. A large bundle delays the main content and keeps the main thread busy, which affects loading and INP. Code splitting, lazy loading and a smaller bundle reduce the risk.

When should I choose client-side rendering?

For logged-in tools, dashboards and highly interactive apps where search visibility is not needed for the screens themselves. For public content pages, consider server rendering or static generation.