SSR vs CSR vs static: the trade-offs you actually feel in production

Over the last three years I shipped three separate projects in three rendering models: SSR, CSR, and a static site generator. Similar scale, different approaches. The theoretical comparisons get muddled the more you read, so here are the real outcomes.

Project A: blog portal, static site (Astro)

Content-heavy, 50 to 60 posts a month. Editors write Markdown, commit to git, CI builds, CDN serves.

Results:
– LCP: 1.1s (p75)
– TTFB: 80ms (CDN edge)
– Hosting cost: $12/month (Cloudflare Pages, effectively zero)
– Build time: 40 seconds
– Editor experience: hard for non-technical editors. Markdown + git is a learning curve.

Upsides:
– Speed is unbeatable. Served from the CDN, no server-side work.
– Security is very high. No runtime, nothing for attackers to exploit.
– Scale is a non-issue. 1k or 100k visitors, same performance.

Downsides:
– Anything dynamic (comments, forms) needs a third party (Disqus, Formspree).
– Every content change is a build + deploy. This is not a “update in five minutes” kind of site.
– Personalisation is hard. You can’t serve different content per user.

Project B: dashboard SPA (React + API, CSR)

Authenticated, per-user, constantly changing data. A chart-heavy dashboard.

Results:
– LCP: 2.8s (p75, cold load)
– TTFB: 120ms (API)
– Hosting cost: $80/month (Vercel + backend VPS)
– Bundle size: 380 KB gzipped
– Editor experience: in-app admin panel, usable by a non-developer admin.

Upsides:
– After the first load, page transitions are instant. Client-side routing.
– Interactive and reactive. Immediate response to user input.
– The backend API can serve any client (web and mobile).

Downsides:
– First load is slow. The screen stays blank until the JS bundle downloads.
– SEO is painful. Even if search engines render JS, it adds latency.
– State management balloons. You end up reaching for Redux or Zustand.

Project C: e-commerce (Next.js SSR)

SEO matters a lot, personalisation is needed, thousands of product pages.

Results:
– LCP: 1.6s (p75)
– TTFB: 230ms (edge + ISR)
– Hosting cost: $250/month (Vercel + PostgreSQL)
– Build time: 12 minutes (incremental after the first deploy, thanks to ISR)
– Editor experience: headless WordPress backend, editors work in the tool they already know.

Upsides:
– SEO is excellent. Full content in the first HTML response.
– Personalisation works. Render changes with login state.
– After hydration, as interactive as an SPA.
– ISR (Incremental Static Regeneration) gives you static speed with dynamic content.

Downsides:
– Hosting costs more. Every request does server-side work.
– The build pipeline is busy. Next.js runtime, edge functions, ISR cache invalidation, all things to reason about.
– Cold starts. On serverless, the first request waits 500ms+.
– Debugging is layered. Code runs on the client, on the server, and at the edge.

Decision matrix

The table I keep coming back to:

Hybrid architectures

In reality most projects mix and match. Astro static pages plus React islands. Next.js static export with dynamic routes. The hybrid is where it gets interesting.

My favourite combo: content-heavy pages static (blog, landing, docs), dynamic pages SSR (user dashboard, e-commerce), interactive bits CSR (islands architecture).

How to pick

Ask yourself:

How often does the content change? Minutes, SSR. Hours, ISR. Days, static with incremental builds.
Does SEO matter? Yes, static or SSR. No, CSR is fine.
Is there personalisation? Yes, SSR or CSR. No, static.
What’s the hosting budget? Tight, prefer static.
Is there a non-technical editor? Yes, a CMS + SSR is usually the best fit.
Is there a mobile app too? If you need to share a backend, lean CSR.

Takeaway

Picking a model is a project decision, not a fashion one. There’s no single “Next.js / Astro / Gatsby / Remix is the best” answer. Each has its scenario. Go back to the matrix and pick what fits.