"Should this page be server-rendered?" is the wrong question. By 2026 a single application routinely mixes four rendering strategies, and picking the right one per route is what separates a fast, well-ranked site from a slow one that Google quietly buries. Here is how we decide on real projects.
The four strategies, in plain terms
- CSR (Client-Side Rendering). The server ships an almost-empty HTML shell plus JavaScript; the browser builds the page. Great for private, highly interactive screens. Bad for anything that needs to rank or load instantly on a mid-range phone.
- SSR (Server-Side Rendering). HTML is built on each request. The user (and Googlebot) gets a complete page immediately, then JavaScript "hydrates" it for interactivity. The right call for content that changes per request or per user but still needs SEO.
- SSG (Static Site Generation). HTML is built once at deploy time and served from a CDN. Unbeatable speed and cost. Perfect when content is the same for everyone and doesn't change minute to minute.
- ISR (Incremental Static Regeneration). SSG that refreshes itself: pages are static, but regenerate in the background on a schedule or on demand. You get CDN speed with content that stays reasonably fresh — no full rebuild required.
The decision actually comes down to two questions
1. Does this page need to be found in Google? If yes, the meaningful content must exist in the initial HTML response. That rules out pure CSR for anything public. Modern crawlers can execute JavaScript, but rendering is deferred, budget-limited and unreliable for large sites — never bet your organic traffic on it.
2. How often does the content change, and is it the same for everyone?
| Same for everyone? | Changes how often? | Use |
|---|---|---|
| Yes | Rarely (deploys) | SSG |
| Yes | Periodically | ISR |
| No (per user/request) | Every request | SSR |
| No, and private/no SEO | Constantly, interactive | CSR |
Where each one wins
Use SSG for marketing pages, landing pages, documentation and most blog posts. The content is identical for every visitor, so paying to render it on every request is pure waste. A static page off a CDN gives you the best possible Largest Contentful Paint and near-zero hosting cost.
Use ISR for catalogues, news and listings — pages that must feel fresh but don't need per-request accuracy. An e-commerce category with thousands of products is the classic case: regenerate each page every few minutes (or on a content webhook) instead of rebuilding the whole site.
Use SSR when the HTML genuinely differs per request: a logged-in dashboard that must still be crawlable, search results, geo- or currency-specific pricing, A/B-tested landing pages. You pay for compute on every hit, so reserve it for pages that truly need it.
Use CSR for the parts of the app behind login where SEO is irrelevant and interactivity is everything — an admin panel, a drawing tool, a chat UI. There's no reason to server-render a screen only its owner will ever see.
React Server Components changed the framing
With the App Router and React Server Components (RSC), "SSR vs CSR" is no longer a whole-page decision — it's per-component. Server Components render on the server and ship zero JavaScript to the browser; you opt specific interactive pieces into the client with "use client". Streaming then sends the shell instantly and fills in slower data as it resolves, so a slow database query no longer blocks your whole page from painting.
In practice this means: render as much as possible on the server, keep client components small and pushed to the leaves of the tree, and reach for CSR data-fetching (e.g. TanStack Query) only for genuinely dynamic, post-load interactions.
The SEO and Core Web Vitals angle
Rendering choice maps almost directly onto the metrics Google ranks on:
- LCP — static/ISR pages off a CDN win by a mile. SSR is fine if your server responds fast (watch your TTFB). CSR is the worst case: the browser must download and run JS before the main content even exists.
- Crawlability — SSG/ISR/SSR all deliver complete HTML, so content is indexed reliably. CSR depends on the crawler running your JavaScript, which is slower and not guaranteed.
- Hydration cost (INP) — every interactive component you ship costs main-thread time. Over-hydrating an SSR page can make it feel slower than a static one. Ship less client JS.
A pragmatic per-site blueprint
For a typical business site or store in 2026 we usually land on:
- Home, landing, services, blog → SSG
- Product and category pages → ISR (revalidate on stock/price change)
- Search, cart, checkout, account → SSR (dynamic, but parts still need SEO/links)
- Admin, dashboards, builders → CSR
Get this split right and you rank well, load fast, and don't pay to render pages that never needed it.
Need help choosing?
If you're not sure which strategy fits which page of your product — or your current stack is server-rendering everything and burning money doing it — that's exactly the kind of architecture review we do. Tell us about your project and we'll map the right rendering strategy to each route.