If you’re scoping a new web app, or wondering why your current one feels sluggish on a mid-range phone, the rendering strategy you choose early on will shape your Core Web Vitals, your SEO, your hosting bill and how hard every future feature is to build. This guide is for founders, product leads and CTOs who need to make that call with a development partner, or sanity-check a decision a team has already made. You’ll come away knowing the real trade-offs between SSR vs SSG vs CSR, where incremental static regeneration and server components fit in, and a simple framework for choosing per page rather than guessing once and living with it.
SSR vs SSG vs CSR: what “rendering strategy” actually means
Every web page has to turn into HTML in a browser eventually. The question is where and when that happens:
- Client-side rendering (CSR) — the server sends a near-empty HTML shell plus a JavaScript bundle; the browser builds the page after the bundle downloads and runs.
- Server-side rendering (SSR) — the server builds the full HTML for every request, then sends it down ready to display.
- Static site generation (SSG) — the HTML is built once, at deploy time, and served straight from a CDN for every visitor.
- Incremental static regeneration (ISR) — a hybrid: pages are static most of the time but can be rebuilt in the background on a schedule or on demand, without a full redeploy.
None of these is universally “best”. They’re trade-offs between freshness, speed, infrastructure cost and how much JavaScript you ship — and most real products end up mixing more than one across different routes.
Client-side rendering: when it earns its keep
CSR makes sense for logged-in, highly interactive screens where search engines never need to see the content: dashboards, admin panels, in-app editors, anything behind authentication. The browser does the work, the server stays simple (often just an API), and the experience can feel very snappy once the bundle has loaded and cached.
The catch is that first load. Largest Contentful Paint (LCP) has to wait for JavaScript to download, parse and execute before anything meaningful appears, and Interaction to Next Paint (INP) — now a confirmed Google ranking signal — punishes pages that keep the main thread busy with heavy client-side work. For anything public-facing that needs to rank or load instantly on a patchy connection, pure CSR is usually the wrong default.
Server-side rendering: when freshness matters more than cost
SSR is the right call when content genuinely differs per request: personalised dashboards with public-facing elements, live pricing or inventory, search results, paywalled previews, anything where stale content would actively mislead a user. Because the server does the rendering, the browser gets usable HTML immediately, which is good for both perceived speed and for crawlers.
The trade-off is compute. You’re paying for a render on every single page view, which means your infrastructure needs to scale with traffic rather than sitting behind a CDN. For most SaaS products this is manageable with sensible caching layers, but it’s worth budgeting for properly — our guide to cloud cost optimisation for startups covers how to keep server-rendered infrastructure from becoming a surprise line item.
Static site generation: the fastest, cheapest option — with a catch
SSG wins when the same content goes to every visitor and doesn’t change minute to minute: marketing pages, documentation, most blog content, pricing pages. Because the HTML is built once and served from a CDN, you get the best achievable LCP and close to zero serving cost per visitor. There’s no server doing work on the critical path at all.
The obvious limitation is freshness — content is only as current as your last build. For a handful of pages that update occasionally, a rebuild on deploy is fine. For content that changes constantly, pure SSG becomes a chore, which is exactly the gap ISR is designed to close.
The practical answer: mix strategies per route
Modern frameworks don’t force a single, site-wide choice any more. Next.js’s App Router, Nuxt, SvelteKit and Remix all let you pick a rendering strategy per route, and increasingly per component. A typical SaaS product might use SSG for the marketing site and docs, ISR for a blog that updates a few times a week, SSR for account and billing pages where content is personalised, and CSR for the in-app product experience behind login.
React Server Components take this further by letting a single page mix server-rendered and client-rendered pieces, so you only ship JavaScript for the parts that genuinely need interactivity. If your stack is Next.js specifically, this is also the point where a lot of teams reconsider their whole rendering setup — our Next.js website migration guide walks through doing that without losing search rankings in the process.
How this decision affects Core Web Vitals and SEO
Rendering strategy is one of the biggest levers you have over Core Web Vitals, because it determines how much work happens before a user sees anything. Server-rendered and statically generated pages tend to clear LCP thresholds by default; heavily client-rendered pages have to fight for every millisecond. INP is particularly unforgiving of CSR-heavy pages that keep re-hydrating large component trees on interaction.
For crawlers, the gap has narrowed — Google can execute JavaScript — but rendering delays, partial content on first paint, and inconsistent hydration still cause real indexing problems in practice, especially at scale. If Core Web Vitals and search visibility are priorities (and for most commercial sites they should be), it’s worth reading how we think about building Core Web Vitals performance in from the architecture stage rather than bolting it on afterwards, and our breakdown of how to improve a Core Web Vitals score properly if you’re diagnosing an existing site.
A simple decision framework
When scoping a new page or route, ask three questions in order:
- Does this page need to rank in search or load instantly for a first-time visitor? If yes, rule out pure CSR.
- Is the content identical for every visitor, or close to it? If yes, SSG or ISR is almost always cheaper and faster than SSR.
- Does the content depend on the logged-in user, live data, or request-specific state? If yes, you need SSR, or a static shell with client-side data fetching for the personalised parts.
Applied route by route, this tends to produce a hybrid architecture by default — which is exactly what the frameworks above are built for.
Common mistakes we see
The most common mistake is treating rendering strategy as a one-off decision made at project kick-off, then never revisiting it as the product grows. A marketing site that started as SSG often grows a blog, a pricing calculator, or a logged-in area, and the rendering approach needs to evolve with it — our piece on cutting a site’s load time from four seconds to under one covers a case where exactly this kind of mismatch was quietly costing conversions. The second common mistake is defaulting to SSR for everything “to be safe”, which saddles a largely static site with server infrastructure and operational overhead it doesn’t need. The third is choosing CSR for a marketing-adjacent page because it was fastest to prototype, then discovering months later that it’s invisible to search and slow on mobile.
None of these are catastrophic if caught early, but they’re the kind of architectural decision that gets more expensive to unwind the longer a product runs. If you’re scoping a build and want a second opinion on the right rendering mix for your specific pages, book a free consultation and we’ll talk through it.
FAQ
Is SSR always better for SEO than CSR?
Generally yes for public-facing content, because the HTML is complete on arrival rather than depending on JavaScript execution. Search engines can index client-rendered pages, but rendering delays and incomplete first paint still cause real-world indexing inconsistencies.
What’s the difference between SSR and ISR?
SSR renders on every request; ISR renders once and serves static HTML, but can regenerate that HTML in the background after a set interval or when triggered, without a full site rebuild.
Can I use more than one rendering strategy on the same site?
Yes — this is now the norm rather than the exception. Most production Next.js, Nuxt and Remix sites mix SSG, ISR, SSR and CSR across different routes depending on what each page needs.
Does rendering strategy affect hosting cost significantly?
Yes. Static and incrementally static pages serve from a CDN with minimal compute cost. Server-rendered pages require compute on every request, which scales with traffic and needs proper capacity planning.
