SSR vs SSG vs CSR: choosing a rendering strategy in 2026

TL;DR

For anyone hearing SSR, SSG, and CSR thrown around in a rebuild discussion, the essentials:

• There is no best rendering strategy, only a best strategy per route. Modern frameworks let your marketing pages be static, your search results server-rendered, and your account dashboard client-rendered, all on one site. Treating rendering as a site-wide choice is the first mistake.
• The decision that matters most is server versus browser. Anything rendered on the server or at build time is guaranteed visible to search engines and AI crawlers. Anything assembled in the browser is a gamble that gets worse every year.
• Static is back. The industry spent a decade adding server complexity, then noticed most pages on most sites do not change between deploys. Astro’s growth and its islands architecture are the clearest signs of that correction.
• React Server Components change the React equation, not the fundamentals. They cut the JavaScript shipped to the browser, which shows up directly in Core Web Vitals, but they are a framework decision inside the server-first camp, not a new answer to the server-versus-browser question.
• Freshness is the real reason to leave static. If content must appear seconds after publishing, you need server rendering or on-demand revalidation, and the revalidation wiring is where high-frequency publishers quietly break.

What each rendering mode actually does

Rendering strategy answers one question: at what moment does your HTML get assembled, and by what machine?

• Static site generation (SSG) assembles every page once, at build time. Visitors get pre-built HTML from a CDN. Fastest possible delivery, cheapest possible serving, and the page is only as fresh as the last build.
• Server-side rendering (SSR) assembles the page on a server at request time, for every request. Always fresh and easy to personalize, but you now run and pay for a server on every page view.
• Client-side rendering (CSR) ships a mostly empty HTML shell plus JavaScript, and the visitor’s browser assembles the page. The server does almost nothing; the user’s device and network do everything.
• Incremental static regeneration (ISR) is the pragmatic middle: pages are served statically but rebuilt one at a time in the background, on a timer or on demand when the CMS publishes.

Every framework worth considering lets you mix these per route. That flexibility, which Next.js normalized, is the real story. The question is never “should our site be SSR or SSG?” It is “which of our routes have any business being rendered at request time?”

SSR vs SSG: the trade that matters most

Server rendering buys you exactly one thing over static generation: request-time freshness. Personalization, live inventory, search results, paywalled content, anything that differs per visitor or per minute. If a route needs that, SSR earns its keep.

Everything else favors static. A pre-built page cannot go down under traffic, costs close to nothing to serve, has no rendering compute between the visitor and the HTML, and its worst-case performance is a CDN cache miss rather than a slow origin. Static also fails at build time, in CI where you can see it, instead of at request time, in production where your visitors can.

The mistake we see in audits is defaulting the whole site to SSR because a handful of routes genuinely need it. A typical content-heavy estate is overwhelmingly pages that change on publish, not on request: the marketing site, the blog, the docs, the product stories. Rendering those per request buys nothing and adds a server dependency to every page view. The default should run the other way: static until a route proves it needs a server.

Build times, the classic argument against static at scale, are a real constraint that modern tooling has mostly tamed: incremental builds, ISR, and content-addressed caching mean a ten-thousand-page site no longer rebuilds the world to fix a typo. When Backlinko, a site whose business is organic traffic, replatformed onto our build, the entire site was pre-rendered by default, and it got 3x faster.

SSR vs CSR: the comparison with a wrong answer

SSR versus SSG is a trade-off. SSR versus CSR, for anything with content in it, is not: one of these is simply wrong for pages that need to be found.

A client-rendered page delivers its content only after the JavaScript bundle downloads, parses, and executes. Google can usually render it eventually, with delays and a crawl-budget cost. The fetchers behind AI assistants and answer engines mostly cannot: they do not execute JavaScript and do not come back for a second pass. A CSR page that looks fine in your browser can be an empty div to the systems that increasingly decide whether you get cited at all. We unpacked that failure mode, and the rest of the silent ones, in Headless CMS SEO: what actually breaks.

The performance story points the same direction. CSR puts your Largest Contentful Paint at the end of a JavaScript pipeline and makes interactivity wait on that same bundle, which is why client-rendered content pages struggle with the Core Web Vitals thresholds that server-rendered pages clear by default.

None of this makes CSR useless. Logged-in dashboards, editors, configurators, anything behind authentication that search engines will never see: client rendering is fine there, often ideal. The rule is boring and reliable: if the page should be found, its content belongs in the initial HTML. If it lives behind a login, render it wherever your team is most productive.

ISR: the middle ground, and where it quietly breaks

Incremental static regeneration keeps static delivery but lets individual pages rebuild without a full deploy: after a timeout, or on demand when your CMS fires a webhook at publish. For content sites on a headless CMS, on-demand ISR is usually the right default: editors publish, the affected pages regenerate within seconds, and everything else stays cached.

When ISR breaks, it breaks silently. If the webhook wiring misfires, or the revalidation call targets the wrong path, nothing errors: the site keeps serving stale pages while the CMS insists the change is live. For a marketing site that is an annoyance; for a publisher shipping corrections it is an incident. This is why “edit a live page, confirm the change reaches the published site” sits in the pre-launch gate of every migration we run: cache invalidation wiring is infrastructure, and it gets tested like infrastructure.

If your stack is Next.js, the specifics, including where time-based revalidation beats on-demand and how the App Router changes the defaults, sit one level down in our Next.js evaluation.

What React Server Components change

React Server Components are the biggest shift in the React world since hooks, and the most misunderstood entry in this list, because they answer a different question than SSR does.

SSR determines where the initial HTML is assembled. RSC determines how much JavaScript ships to the browser afterward. Classic server-rendered React sends the HTML, then sends the entire component tree as JavaScript anyway and re-executes it in the browser to make the page interactive. That hydration step is why a server-rendered React site could still ship megabyte bundles and score poorly on interactivity. With RSC, components marked as server components execute only on the server and ship no JavaScript at all; the browser receives their rendered output plus code for just the genuinely interactive parts.

For a content-heavy site, where most of any page is text, images, and links that need no client-side behavior, that is a structural win: the bundle shrinks to roughly the size of your interactive components. It is also real engineering complexity: a server/client boundary your team has to reason about, a data-fetching model that reshapes how components are written, and a debugging story that is still maturing. RSC is the right default if you are on Next.js’s App Router anyway. It is not a reason to adopt Next.js for a site that a simpler model serves better, which brings us to the correction the industry has been making.

The return of static: islands and Astro

The clearest trend of the past few years is the industry walking back a decade of doing too much in the browser. The React single-page-app era made “ship the framework to every visitor” the default, even for sites that were mostly documents. The correction has a name and a fast-growing ecosystem behind it.

Astro’s model, islands architecture, inverts the SPA default: every component renders to plain HTML at build time, ships zero JavaScript, and interactivity is opted into per component. The newsletter form hydrates; the other 95% of the page is inert HTML that loads instantly and cannot break. It is partial hydration made mainstream, and it maps exactly onto how content sites are actually shaped, which is why Astro became the default answer for marketing sites, blogs, and docs. Most of what we build for content-heavy sites is Astro, including this site and bejamas/ui, the open-source Astro component library we maintain. When we rebuilt Carbon Removal Alliance on Astro and Storyblok, session duration rose 15% and bounce rate fell 20%, on a site that ships almost no JavaScript.

Islands do have a limit: when most of the page is interactive and stateful, you are building an application rather than a document. That is Next.js and RSC territory. The two models are converging on the same insight from opposite directions: send HTML, ship JavaScript only where a component earns it. Our Astro vs Next.js comparison covers where the line falls; the short version is that the shape of your pages decides, not the trend cycle.

How we choose, route by route

In an audit, the rendering conversation is a table, not a philosophy. For each route class: how fresh must it be, who has to see it, and how interactive is it?

Two principles hold the table together. Findable content lives in server-produced HTML, no exceptions. And every route pays for the machinery it actually uses: no request-time compute for pages that change quarterly, no full-page rebuilds for content that changes hourly.

Common questions

Is SSG or SSR better for SEO?

For crawlers they are equivalent when implemented well: both deliver complete HTML. In practice static generation has the edge, because it removes the ways SSR degrades under load: slow origin responses, timeouts under crawl spikes, and cache misconfiguration. Speed and reliability both feed into rankings, and static maximizes both by default.

Is client-side rendering bad for SEO?

For content you want indexed, yes, and it is worse for AI search than for Google. Googlebot renders JavaScript with delays and budgets; most AI crawlers do not render it at all, so client-assembled content is invisible to them. Keep CSR for authenticated experiences crawlers will never see.

What is incremental static regeneration?

ISR serves pre-built static pages while regenerating individual pages in the background, on a schedule or on demand when the CMS publishes. It combines static speed with near-real-time freshness, at the cost of cache-invalidation wiring that must be tested: its failure mode is silently serving stale content.

Do React Server Components replace SSR?

No, they complement it. SSR decides where the initial HTML comes from; RSC decides how much JavaScript follows it. A Next.js App Router site typically uses both: server-rendered HTML, with server components keeping the client bundle down to the interactive parts.

Which rendering strategy should we choose?

Per route, not per site: static for everything that changes on publish, server rendering where request-time freshness or personalization earns it, client rendering behind login. If a partner proposes one mode for your whole site, ask which of your routes actually needs it. That single question is a small version of the audit itself.