Is server-side rendering always better than client-side rendering?

No. Server rendering helps first load and search indexing for public pages. Highly interactive, logged-in screens often work fine, or better, rendered on the client.

Can I mix rendering strategies in one application?

Yes. Modern frameworks such as Next.js and SvelteKit let you choose per route, and sometimes per component.

SSR, SSG, ISR and CSR: choosing a rendering strategy

By Ruben Bijker · Published 27 October 2026 · 6 min read

A rendering strategy decides where and when HTML is produced: at build time, on each request, in the background on a schedule, or in the browser. Picking per page, not per project, gives the best result.

The four strategies

| Strategy | HTML is created | Good for | Trade-off | | --- | --- | --- | --- | | SSG (static generation) | At build time | Marketing pages, docs, blogs | Content only updates on rebuild | | ISR (incremental regeneration) | At build time, refreshed in the background | Catalogues, articles that change now and then | Brief window of stale content | | SSR (server-side rendering) | On every request | Personalised or constantly changing pages | Server work per request, slower than cache | | CSR (client-side rendering) | In the browser | Dashboards, editors, app-like screens | Blank start, weaker for search and slow devices |

How to decide per page

Is the content the same for everyone? Then it can be cached. Prefer SSG or ISR.
How often does it change? Minutes or hours suit ISR with a revalidation time. Seconds, or per user, suit SSR or client fetching.
Does it need to be found in search? Then the content should be in the initial HTML.
Is it behind a login? Search does not matter; interactivity and data freshness do.

Streaming and partial rendering

Modern frameworks can send the static shell of a page immediately and stream the dynamic parts in as they become ready. This gives the speed of a cached page with the freshness of a dynamic one. Combined with React Server Components or SvelteKit load functions, it keeps JavaScript sent to the browser small.

Common mistakes

Rendering everything on the client because it is simplest to start with, then fighting performance later.
Using SSR for pages that never change per user, wasting server time and adding latency.
Forgetting cache invalidation. Static speed is only useful if updated content actually appears; use tags or webhooks from your CMS to revalidate.
Hydrating more than needed. Interactive islands are cheaper than a fully interactive page.

A practical default

Start static, add revalidation where content changes, use server rendering only for personalised responses, and keep client rendering for the genuinely interactive parts. Measure with real user data before optimising further.

Frequently asked questions

Is server-side rendering always better than client-side rendering?: No. Server rendering helps first load and search indexing for public pages. Highly interactive, logged-in screens often work fine, or better, rendered on the client.
Can I mix rendering strategies in one application?: Yes. Modern frameworks such as Next.js and SvelteKit let you choose per route, and sometimes per component.

Related service: Freelance web developer in Amsterdam

Have a project in mind?

Tell me briefly what you need. You get an answer from me, not from a sales team.

Get in touch

Choosing a web stack: Next.js, Laravel or Svelte?
A technical comparison of Next.js, Laravel, SvelteKit and Webflow: where each is strong, where it hurts, and which questions actually decide the choice.
Web performance and Core Web Vitals: what to optimise first
A practical guide to LCP, INP and CLS, and the techniques that move them: images, fonts, JavaScript, caching and measurement.