Ruben Bijker
Neem contact op

SSR, SSG, ISR en CSR: een renderstrategie kiezen

Door Ruben Bijker · Gepubliceerd · 6 min lezen

Een renderstrategie bepaalt waar en wanneer HTML wordt gemaakt: tijdens de build, bij elk verzoek, op de achtergrond volgens een schema, of in de browser. Kiezen per pagina in plaats van per project geeft het beste resultaat.

De vier strategieën

| Strategie | HTML ontstaat | Goed voor | Afweging | | --- | --- | --- | --- | | SSG (statische generatie) | Tijdens de build | Marketingpagina's, docs, blogs | Content wijzigt pas na een nieuwe build | | ISR (incrementele regeneratie) | Tijdens de build, op de achtergrond ververst | Catalogi, artikelen die af en toe wijzigen | Kort venster met verouderde content | | SSR (server-side rendering) | Bij elk verzoek | Gepersonaliseerde of continu wijzigende pagina's | Serverwerk per verzoek, trager dan cache | | CSR (client-side rendering) | In de browser | Dashboards, editors, app-achtige schermen | Leeg begin, zwakker voor zoekmachines en trage apparaten |

Zo beslis je per pagina

  1. Is de content voor iedereen gelijk? Dan kan het gecachet worden. Kies SSG of ISR.
  2. Hoe vaak verandert het? Minuten of uren passen bij ISR met een revalidatietijd. Seconden, of per gebruiker, passen bij SSR of client-fetching.
  3. Moet het vindbaar zijn in zoekmachines? Dan hoort de content in de eerste HTML.
  4. Zit het achter een login? Dan telt zoeken niet; interactiviteit en actuele data wel.

Streaming en gedeeltelijke rendering

Moderne frameworks kunnen de statische schil van een pagina direct sturen en de dynamische delen streamen zodra ze klaar zijn. Dat geeft de snelheid van een gecachete pagina met de actualiteit van een dynamische. Samen met React Server Components of SvelteKit load-functies blijft de hoeveelheid JavaScript in de browser klein.

Veelgemaakte fouten

  • Alles op de client renderen omdat dat het makkelijkst begint, en later tegen performance vechten.
  • SSR gebruiken voor pagina's die nooit per gebruiker verschillen: verspilde serverkracht en extra latency.
  • Cache-invalidatie vergeten. Statische snelheid heeft alleen zin als nieuwe content ook verschijnt; gebruik tags of webhooks vanuit je CMS om te revalideren.
  • Meer hydrateren dan nodig. Interactieve eilanden zijn goedkoper dan een volledig interactieve pagina.

Een praktische standaard

Begin statisch, voeg revalidatie toe waar content wijzigt, gebruik server rendering alleen voor gepersonaliseerde responses en bewaar client rendering voor de echt interactieve delen. Meet met echte gebruikersdata voordat je verder optimaliseert.

Zie ook: een stack kiezen en webperformance en Core Web Vitals.

Veelgestelde vragen

Is server-side rendering altijd beter dan client-side rendering?
Nee. Server rendering helpt bij de eerste load en indexering van publieke pagina's. Zeer interactieve, ingelogde schermen werken vaak prima, of beter, aan de clientkant.
Kan ik renderstrategieën mixen in één applicatie?
Ja. Moderne frameworks zoals Next.js en SvelteKit laten je per route kiezen, soms zelfs per component.

Bijbehorende dienst: Freelance webdeveloper in Amsterdam

Een project in gedachten?

Vertel kort wat je nodig hebt. Je krijgt antwoord van mij, niet van een verkoopteam.

Neem contact op

Verder lezen