Server-Side vs Client-Side Rendering: Trade-offs Explained

The short answer

Quick answer: The difference is where the HTML is built. With client-side rendering (CSR), the server sends a nearly empty page plus a JavaScript bundle, and the browser builds the interface. With server-side rendering (SSR), the server builds the full HTML for each request and sends it ready to display. With static site generation (SSG), the HTML is built once in advance and served as files. SSR and SSG show content sooner and are easier for search engines. CSR is simpler to host and gives fluid, app-like navigation once loaded. Modern frameworks mix these per page, and the right choice depends on how dynamic and how public each page is.

Client-side rendering

The server's response is minimal:

<!doctype html>
<html>
  <head><title>App</title></head>
  <body>
    <div id="root"></div>
    <script src=/bundle.js></script>
  </body>
</html>

Then:

1. The browser downloads the JavaScript bundle.
2. It parses and runs it.
3. The app requests data from an API.
4. It builds the page in the browser.

This is a classic single-page application (SPA). After the first load, navigation happens in the browser without full page reloads.

Strengths

• Smooth, app-like interactions and transitions.
• Cheap hosting: static files on a CDN.
• A clean split between front end and API.

Weaknesses

• Slow first view. Nothing meaningful appears until the JavaScript has downloaded, run and fetched data. On a slow phone that can take seconds.
• SEO is less dependable. Search engines can run JavaScript, but it may be delayed and is less reliable; many other crawlers and link-preview tools do not run it at all.
• Large bundles. See why JavaScript bundles get so big.

Server-side rendering

1. A request arrives.
2. The server fetches the data and renders the complete HTML.
3. The browser displays it immediately.
4. JavaScript loads and hydrates the page to make it interactive.

Strengths

• Content appears quickly, since the first response already contains it.
• Good for SEO and social sharing. Crawlers get real HTML.
• Works, at least for reading, even if JavaScript is slow or fails.

Weaknesses

• Slower response. The server does work for every request, so time to first byte is higher.
• Server cost and complexity. You need running servers, not just file hosting.
• A gap before interactivity. The page looks ready before it responds.

Hydration

Server-rendered HTML is static. Buttons do nothing until JavaScript attaches event handlers. Hydration is that process: the framework loads in the browser, runs the components again to rebuild its internal picture of the page, and connects it to the existing HTML.

It has three costs:

• The work is done twice: once on the server to produce HTML, once in the browser to make it interactive.
• You still ship the JavaScript for every component.
• The "uncanny valley": for a moment the page is visible and unresponsive. A user taps a button and nothing happens.

A hydration mismatch occurs when the server and the browser produce different output, for example from a date formatted in different time zones or a random value. Frameworks warn about it, and it can cause visible glitches.

Static site generation

Pages are rendered at build time. The output is a set of HTML files, deployed to a CDN.

Strengths

• The fastest option. Files are served from the edge with no server work.
• Cheap, reliable and secure. There is very little to break or attack.
• Excellent for SEO.

Weaknesses

• Content is only as fresh as the last build.
• Build time grows with the number of pages.
• No per-user content in the HTML itself.

Incremental static regeneration (ISR) softens the first two: pages are regenerated in the background after a set time or when content changes, so you get static speed with fresher data and no full rebuild.

Side by side

These show up directly in the performance metrics. The web.dev article Rendering on the Web compares the options in terms of time to first byte, first contentful paint and interactivity. For how the browser turns the HTML into pixels, see how browsers render a web page.

Newer approaches

Frameworks have spent the last few years reducing the cost of hydration.

• Streaming SSR. The server sends the page in pieces. The shell and fast parts arrive at once; slow sections follow when their data is ready, with placeholders shown in the meantime.
• Selective or progressive hydration. Hydrate the parts the user is interacting with first.
• Islands architecture. The page is static HTML with small, independent interactive "islands". Only those ship JavaScript. Astro is the best-known example.
• React Server Components. Some components run only on the server. Their code and dependencies never reach the browser. Only components marked as interactive are hydrated.
• Resumability. The server records enough state in the HTML that the browser can pick up where the server stopped, without re-running everything. Qwik takes this approach.
• Edge rendering. Run SSR in data centres near the user to cut latency. See what serverless really means.

The common theme: send less JavaScript, and do less work twice.

What about SEO?

Search engines index HTML most reliably. Server-rendered and static pages put the content, title and metadata directly in the response.

With pure client-side rendering:

• Indexing depends on the crawler running your JavaScript, which may be deferred.
• Social media and messaging apps that generate link previews usually do not run JavaScript, so they see an empty page.
• Slow rendering can hurt Core Web Vitals, which are a ranking consideration.

For content that needs to be found through search, such as articles, product pages and landing pages, render on the server or statically.

How to choose

You rarely have to choose once for a whole site. Frameworks such as Next.js, Nuxt, SvelteKit, Remix and Astro let you pick per route. A typical site has static marketing pages, server-rendered product pages and a client-rendered account area.

Caching blurs the lines further: a server-rendered page cached at a CDN behaves much like a static one. See caching strategies.

Common mistakes

• Using a client-rendered SPA for a content site, then struggling with SEO and load time.
• Server-rendering a private dashboard where it adds cost and no benefit.
• Shipping the full bundle anyway. SSR shows content sooner but does not make the page interactive sooner if the JavaScript is huge.
• Code that assumes a browser (window, localStorage) running on the server and crashing.
• Fetching data in a waterfall, one request after another, in place of in parallel.

Frequently asked questions

What is the difference between SSR and CSR?

In server-side rendering, the server sends complete HTML. In client-side rendering, the server sends JavaScript and the browser builds the HTML.

What is hydration?

The process in which JavaScript takes over server-rendered HTML in the browser, attaching event handlers and state so the page becomes interactive.

Is SSR better for SEO?

Yes, generally. The content is in the initial HTML, which all crawlers can read without running JavaScript.

What is the difference between SSR and SSG?

SSR builds the HTML for each request. SSG builds it once at build time and serves the same file to everyone.

Conclusion

Rendering strategy is a question of where and when HTML gets made. Static generation is fastest when content rarely changes, server rendering suits dynamic public pages, and client rendering suits private, highly interactive apps. Choose per page, cache what you can, and keep the JavaScript you send as small as the page allows.

Related articles

• How Browsers Render a Web Page
• Why JavaScript Bundles Get So Big (and How to Shrink Them)
• How CDNs Make Websites Load Faster Worldwide
• What Is the Virtual DOM and Why Did React Use It?

Sources and further reading

• Rendering on the Web (web.dev)
• Critical Rendering Path (web.dev)