By Rohit V.7 min readArticle
SSR vs CSR vs SSG: Rendering Explained (2026)
TF
ToolsFuel Team
Web development tools & tips
Photo by Unsplash on Unsplash
Table of Contents
The Short Version
> Quick answer: CSR ships an empty HTML shell and lets JavaScript build the page in the browser. SSR builds the HTML on the server for every request. SSG builds it once at deploy time and serves the same file to everyone. The right choice depends on how often the data changes and whether the page needs to be personalised.
These three names get thrown around like competing frameworks, which confuses the decision. They're really answers to one narrow question: where does the HTML come from?
I've shipped all three on different projects and the switching cost is usually low. What matters is picking per route rather than per app — a marketing page and a logged-in dashboard have almost nothing in common, and forcing one strategy across both is how apps end up slow.
So it's worth understanding what each one actually costs before defaulting to whatever the framework template gave you.
These three names get thrown around like competing frameworks, which confuses the decision. They're really answers to one narrow question: where does the HTML come from?
I've shipped all three on different projects and the switching cost is usually low. What matters is picking per route rather than per app — a marketing page and a logged-in dashboard have almost nothing in common, and forcing one strategy across both is how apps end up slow.
So it's worth understanding what each one actually costs before defaulting to whatever the framework template gave you.
Client-Side Rendering, Concretely
With CSR the server sends an HTML file containing roughly nothing — a `<div id="root"></div>` and a script tag. The browser downloads the JavaScript bundle, runs it, fetches data from an API and builds the DOM.
That means three round trips before anything appears: HTML, then JS, then data. On a fast laptop it's invisible. On a mid-range phone on 4G, it's the difference between a page that feels instant and one that shows a spinner for two seconds.
The payoff is that navigation after the first load is genuinely fast, because the app is already running and only needs new data. Single-page apps feel snappy for a reason.
CSR is the right answer for anything behind a login where SEO doesn't matter and users stay for a while. An admin panel, a dashboard, an internal tool. Nobody's Googling your settings page, so the empty initial HTML costs you nothing.
That means three round trips before anything appears: HTML, then JS, then data. On a fast laptop it's invisible. On a mid-range phone on 4G, it's the difference between a page that feels instant and one that shows a spinner for two seconds.
The payoff is that navigation after the first load is genuinely fast, because the app is already running and only needs new data. Single-page apps feel snappy for a reason.
CSR is the right answer for anything behind a login where SEO doesn't matter and users stay for a while. An admin panel, a dashboard, an internal tool. Nobody's Googling your settings page, so the empty initial HTML costs you nothing.
Server-Side Rendering, Concretely
SSR runs your component code on the server for each request, produces real HTML and sends that. The browser paints something immediately, then downloads the JavaScript and hydrates the markup so it becomes interactive.
The first paint is dramatically faster because the HTML arrives complete. Crawlers get real content without executing JavaScript, which matters if search traffic pays your bills.
The cost is server time on every request, and a subtler cost people underestimate: hydration. The browser still downloads the same bundle and walks the tree to attach event handlers, so a heavy page can look ready while being unclickable for a moment. That gap shows up directly in Core Web Vitals, particularly in interaction latency.
SSR fits pages that are public, dynamic and personalised — a product page with live stock, a feed, a search results page. Anything where the content differs per request and needs to be indexable.
The first paint is dramatically faster because the HTML arrives complete. Crawlers get real content without executing JavaScript, which matters if search traffic pays your bills.
The cost is server time on every request, and a subtler cost people underestimate: hydration. The browser still downloads the same bundle and walks the tree to attach event handlers, so a heavy page can look ready while being unclickable for a moment. That gap shows up directly in Core Web Vitals, particularly in interaction latency.
SSR fits pages that are public, dynamic and personalised — a product page with live stock, a feed, a search results page. Anything where the content differs per request and needs to be indexable.
Static Site Generation, Concretely
SSG runs the same rendering work once, at build time, and writes plain HTML files. A request just gets a file off a CDN.
Nothing beats it for speed. There's no server computation, no database call, no cold start — just a file served from an edge node near the user. If you've read about how CDNs work, SSG is the strategy that takes full advantage of one.
The constraint is obvious: the content is frozen until the next build. A blog post is fine. A stock ticker is not.
Incremental regeneration softens this. Most modern frameworks let a static page be rebuilt in the background after a set interval or when a webhook fires, so you get static delivery with content that refreshes every few minutes. That covers a surprising number of cases people assume need SSR — documentation, blogs, pricing pages, catalogues that change hourly rather than per-request.
Nothing beats it for speed. There's no server computation, no database call, no cold start — just a file served from an edge node near the user. If you've read about how CDNs work, SSG is the strategy that takes full advantage of one.
The constraint is obvious: the content is frozen until the next build. A blog post is fine. A stock ticker is not.
Incremental regeneration softens this. Most modern frameworks let a static page be rebuilt in the background after a set interval or when a webhook fires, so you get static delivery with content that refreshes every few minutes. That covers a surprising number of cases people assume need SSR — documentation, blogs, pricing pages, catalogues that change hourly rather than per-request.
The Hybrid Reality
Nobody picks one anymore. Modern frameworks let you choose per route, and the sensible setup mixes all three in a single app.
A typical layout: marketing pages and docs static, product and category pages server-rendered, the logged-in dashboard client-rendered. Three strategies, one codebase, each page paying only for what it needs.
Streaming complicates the picture in a good way. Instead of waiting for the whole page to render on the server, you can send the shell immediately and stream slower parts as they resolve. The user sees a layout in 200ms and the slow widget fills in later.
Partial prerendering pushes further — a static shell from the CDN with dynamic holes filled per request. I'd treat these as refinements rather than new categories. They're still answering the same question about where HTML comes from, just with a finer-grained answer.
A typical layout: marketing pages and docs static, product and category pages server-rendered, the logged-in dashboard client-rendered. Three strategies, one codebase, each page paying only for what it needs.
Streaming complicates the picture in a good way. Instead of waiting for the whole page to render on the server, you can send the shell immediately and stream slower parts as they resolve. The user sees a layout in 200ms and the slow widget fills in later.
Partial prerendering pushes further — a static shell from the CDN with dynamic holes filled per request. I'd treat these as refinements rather than new categories. They're still answering the same question about where HTML comes from, just with a finer-grained answer.
How to Actually Choose
Ask three questions about the route. Does it need to be indexed by search engines? Does the content differ per user? How often does the underlying data change?
Indexed plus identical for everyone plus rarely changing means static, and it isn't close. Indexed plus personalised means server rendering. Not indexed means client rendering is fine and probably simpler.
The mistake I see most is server-rendering a page that could be static because the data "might" change. Might isn't a requirement. Measure how often it actually changes, then set a regeneration interval and move on.
The second mistake is client-rendering a public landing page because the app template did it that way. That page is the one thing that needs to be fast and indexable, and CSR makes it neither.
MDN's rendering overview is a solid primer if you want the underlying request model rather than the framework vocabulary.
Indexed plus identical for everyone plus rarely changing means static, and it isn't close. Indexed plus personalised means server rendering. Not indexed means client rendering is fine and probably simpler.
The mistake I see most is server-rendering a page that could be static because the data "might" change. Might isn't a requirement. Measure how often it actually changes, then set a regeneration interval and move on.
The second mistake is client-rendering a public landing page because the app template did it that way. That page is the one thing that needs to be fast and indexable, and CSR makes it neither.
MDN's rendering overview is a solid primer if you want the underlying request model rather than the framework vocabulary.
What Each One Does to Your Metrics
Largest Contentful Paint favours SSG, then SSR, then CSR — in that order, consistently. The HTML either contains the content or it doesn't, and no amount of bundle optimisation changes that ordering.
Time to First Byte runs the opposite way for SSR: the server has to do work before responding, so TTFB rises even as LCP falls. That trade is usually worth it, but it means you can't judge SSR by TTFB alone.
Interaction readiness is where CSR and SSR converge, because both ship the same JavaScript. A server-rendered page that's visually complete but not yet hydrated frustrates users in a specific way — they tap and nothing happens.
Bundle size is the variable that hurts everywhere. Rendering strategy decides when the HTML appears, but JavaScript weight decides when the page becomes usable, and tree shaking does more for that number than switching strategies ever will.
Time to First Byte runs the opposite way for SSR: the server has to do work before responding, so TTFB rises even as LCP falls. That trade is usually worth it, but it means you can't judge SSR by TTFB alone.
Interaction readiness is where CSR and SSR converge, because both ship the same JavaScript. A server-rendered page that's visually complete but not yet hydrated frustrates users in a specific way — they tap and nothing happens.
Bundle size is the variable that hurts everywhere. Rendering strategy decides when the HTML appears, but JavaScript weight decides when the page becomes usable, and tree shaking does more for that number than switching strategies ever will.
A Practical Migration Path
If you're on a fully client-rendered app and the marketing pages are underperforming in search, don't rewrite everything. Move those specific routes to static generation and leave the app alone. It's usually a day of work and it's the whole win.
Going the other direction — from static to server-rendered — usually means you've added personalisation. Check whether it can live client-side instead: a static page that fetches the user's name after load keeps the CDN benefits and costs one small request.
Watch for code that assumes a browser. Anything touching `window`, `localStorage` or `document` at module scope breaks the moment it runs on a server, which is the single most common error in a CSR-to-SSR move. If you're relying on localStorage or sessionStorage, that code has to move inside an effect or a client-only boundary.
And test on a throttled connection, not your laptop. Every one of these tradeoffs is invisible on fast hardware, which is exactly why so many apps ship the wrong choice.
Going the other direction — from static to server-rendered — usually means you've added personalisation. Check whether it can live client-side instead: a static page that fetches the user's name after load keeps the CDN benefits and costs one small request.
Watch for code that assumes a browser. Anything touching `window`, `localStorage` or `document` at module scope breaks the moment it runs on a server, which is the single most common error in a CSR-to-SSR move. If you're relying on localStorage or sessionStorage, that code has to move inside an effect or a client-only boundary.
And test on a throttled connection, not your laptop. Every one of these tradeoffs is invisible on fast hardware, which is exactly why so many apps ship the wrong choice.
Frequently Asked Questions
What is the difference between SSR and SSG?
SSR builds the HTML on the server for every incoming request, so the content can be fresh and personalised. SSG builds the HTML once at deploy time and serves the same file to everyone, which is faster but frozen until the next build or regeneration.
Is client-side rendering bad for SEO?
It's a handicap rather than a death sentence. Google can execute JavaScript, but rendering is queued and slower, and other crawlers often don't run JS at all. For any page where search traffic matters, server rendering or static generation is the safer choice.
Can I mix rendering strategies in one app?
Yes, and you should. Modern frameworks let you set the strategy per route, so marketing pages can be static, product pages server-rendered and the dashboard client-rendered — all in the same codebase.
Which rendering method is fastest?
Static generation, by a clear margin, because a request just returns a file from a CDN with no computation. Server rendering comes second and client rendering last for first paint, though CSR feels fastest for navigation once the app is loaded.
Does SSR make my site slower to respond?
It raises time to first byte because the server renders before replying, while lowering the time until content appears. If you're tuning those numbers, our [Core Web Vitals guide](/blog/core-web-vitals-explained-for-developers-2026) covers which metric to optimise for first.
Try ToolsFuel
23+ free online tools for developers, designers, and everyone. No signup required.
Browse All Tools