SSR, CSR, SSG en ISR: het echte verschil
SSG maakt HTML vóór de request, meestal tijdens de build. SSR maakt HTML op de server per request. CSR bouwt een groot deel van de interface nadat JavaScript in de browser is uitgevoerd. ISR bewaart een statisch resultaat maar kan geselecteerde pagina's na deployment opnieuw genereren. [6][9][16]
De nuttige vragen zijn dus wanneer HTML ontstaat, hoe lang het wordt gecachet en hoeveel werk voor de browser overblijft.
SEO: Google rendert JavaScript, maar CSR is niet hetzelfde als prerendering
Google beschrijft JavaScript-verwerking in drie stappen: crawling, rendering en indexing. Als de initiële HTML niet de echte content bevat, moet de Web Rendering Service JavaScript uitvoeren en komt de pagina in een renderqueue. [1]
Google raadt server-side rendering of prerendering nog steeds aan omdat dit sneller is voor gebruikers en crawlers, en niet alle bots JavaScript kunnen uitvoeren. [1]
CSR kan dus werken, maar betekenisvol HTML in de eerste response is robuuster voor belangrijke publieke content.
SSG: sterk voor content die niet bij elke request vers hoeft te zijn
Bij SSG wordt HTML tijdens de build gemaakt en daarna als statisch bestand via CDN geleverd. Next.js raadt Static Generation aan wanneer een pagina vooraf kan worden opgebouwd. [9][12]
Landingpages, documentatie, artikelen, help, portfolios en sommige productlijsten zijn typische toepassingen. [10][16]
De beperking ontstaat bij zeer frequente updates of extreem lange builds.
SSR: wanneer content vers of requestafhankelijk moet zijn
SSR genereert HTML voor een specifieke request en kan actuele data, headers, cookies, lokalisatie en queryparameters gebruiken. [6][10][11]
Voor SEO staat content direct in HTML. Daartegenover staat serverwerk per request en mogelijk hogere TTFB bij traag renderen. [6]
Stabiele delen kunnen nog steeds worden gecachet.
ISR: statisch HTML met gecontroleerde versheid
ISR combineert statische levering met regeneratie na deployment. Next.js documenteert updates van statische pagina's na de build, terwijl Nuxt 4 vergelijkbare patronen biedt via `isr` en `swr`. [9][13][16]
Dit past bij catalogi, artikelen, documentatie en categorieën die periodiek veranderen maar geen realtime nauwkeurigheid vereisen.
Bij stale-while-revalidate kan de eerste bezoeker na verlopen cache nog de oude versie zien terwijl de nieuwe op de achtergrond wordt gegenereerd. [13][16]
CSR: geschikt voor toepassingen zonder indexeringsbehoefte
Bij CSR moet de browser JavaScript downloaden, parsen en uitvoeren voordat veel DOM ontstaat. web.dev waarschuwt dat grotere JavaScript-bundles INP kunnen verslechteren, vooral op mobiele apparaten. [6][7]
Nuxt noemt SaaS, backoffice, games en andere sterk interactieve interfaces zonder SEO-behoefte als passende gevallen. [13]
Voor publieke content verhoogt CSR de afhankelijkheid van JavaScript-rendering door crawlers. [1][2]
SEO- en performancevergelijking
| Modus | Wanneer HTML wordt gemaakt | Content in initiële HTML | Versheid | Kosten per request | SEO |
|---|---|---|---|---|---|
| SSG | Build | Ja | Tot volgende build | Zeer laag | Zeer goed |
| ISR | Build of revalidatie | Ja | Afhankelijk van revalidatie | Laag | Zeer goed |
| SSR | Elke request | Ja | Zeer hoog | Hoger | Zeer goed |
| CSR | In browser | Vaak beperkt | Hoog na fetch | Server laag, client hoger | Mogelijk, minder optimaal |
Er is geen universele rangorde. SSG en ISR hebben vaak cache- en kostenvoordelen, SSR heeft een versheidsvoordeel en CSR geeft de browser meer verantwoordelijkheid. [6][9][13]
Voor SEO kunnen SSG, ISR en SSR betekenisvol HTML direct teruggeven. CSR kan door Google worden geïndexeerd, maar heeft een extra renderingstap nodig. [1][9]
Core Web Vitals: rendering is maar één factor
| Metric | Goed | Slecht | Meet |
|---|---|---|---|
| LCP | ≤ 2.5 s | > 4.0 s | Laden van hoofdcontent |
| INP | ≤ 200 ms | > 500 ms | Reactiesnelheid bij interacties |
| CLS | ≤ 0.1 | > 0.25 | Visuele stabiliteit |
Google gebruikt Core Web Vitals in ranking-systemen, maar goede scores garanderen geen hoge positie. De huidige metrics zijn LCP, INP en CLS. [4][5]
Aanbevolen goede drempels zijn LCP ≤ 2,5 s, INP ≤ 200 ms en CLS ≤ 0,1 op het 75e percentiel. [4][8]
SSG kan snel HTML leveren en toch slechte INP hebben door te veel JavaScript. SSR kan eerste rendering verbeteren, maar een trage backend kan TTFB verslechteren. [6][7]
Hydration: SSR eindigt niet bij het afleveren van HTML
Veel frameworks hydrateren SSR- of SSG-output door later state en event handlers te koppelen. web.dev waarschuwt dat volledige rehydration TBT en INP kan verslechteren. [6]
Een pagina kan dus klaar lijken terwijl interacties nog kort geblokkeerd zijn.
Minder client-JavaScript, code splitting, lazy loading en gedeeltelijke of uitgestelde hydration helpen. Nuxt 4 documenteert bijna-statische pagina's met zeer weinig JavaScript. [7][14]
Cache en dataversheid: het belangrijkste onderscheid
SSG hergebruikt output tot de volgende build. ISR voegt revalidatie toe. SSR kan elke request opnieuw renderen, maar kan ook server- of CDN-cache gebruiken. [6][13][16]
De keuze moet beginnen bij de maximale toegestane leeftijd van data. Enkele minuten kan voor productcontent acceptabel zijn, voor een accountsaldo meestal niet.
Cache-invalidation hoort indien mogelijk gekoppeld te zijn aan echte contentwijzigingen.
SEO stopt niet bij rendering
HTML vervangt geen correcte HTTP-statuscodes, crawlbare links, canonicals, sitemaps, titels en metadata. Google adviseert eigen URL's en crawlbare links voor belangrijke content. [1][2]
Ook slecht SSR kan foutieve 200-responses, duplicaten of verkeerde metadata opleveren. Rendering is slechts één onderdeel van technische SEO.
Google raadt Dynamic Rendering niet meer aan als langetermijnoplossing en noemt SSR, static rendering of hydration als betere opties. [3]
Welke strategie voor welk paginatype
Landingpages, blogs en documentatie passen meestal bij SSG. Grote catalogi of periodieke nieuwscontent vaak bij ISR. Publieke requestafhankelijke pagina's kunnen SSR nodig hebben. Private dashboards kunnen CSR blijven. [9][13]
E-commerce kan verschillende modellen combineren: statische categorie, ISR voor productpagina's, SSR voor sessiedata en CSR voor interactieve filters.
Kies per route.
Realiteit in 2026: hybride modellen worden fijner
Next.js 16.3.4 documenteert Cache Components, `use cache`, data- en UI-revalidatie, een statische shell en streaming van request-time data. De huidige cachingdocumentatie is bijgewerkt op 25 augustus 2026. [11]
Nuxt 4 ondersteunt `prerender`, `ssr`, `swr` en `isr` per route via Route Rules. [13][14]
De vier termen blijven nuttig, maar beschrijven niet meer iedere moderne component precies.
CSR stapsgewijs SEO-vriendelijker maken
Bepaal eerst welke publieke routes werkelijk organisch verkeer moeten aantrekken. Een privé-dashboard hoeft niet naar SSR voor architecturale uniformiteit.
Breng vervolgens kritieke content, titels, metadata en links naar HTML dat vóór client-JavaScript wordt gegenereerd. Google adviseert SSR of prerendering boven Dynamic Rendering. [1][3]
Controleer daarna Search Console, gerenderd HTML en velddata voor Core Web Vitals.
Praktische beslisregel
Kan een pagina vooraf worden gegenereerd en is de content voor iedereen gelijk, begin met SSG. Verandert de content periodiek, overweeg ISR. Moet de uitkomst requestafhankelijk en in HTML aanwezig zijn, gebruik SSR. Is het een private app zonder SEO-doel, dan is CSR vaak genoeg. [9][13]
Valideer vervolgens TTFB, LCP, INP, CLS, serverkosten, updatefrequentie, aantal pagina's en personalisatie.
- Moet hoofdcontent geïndexeerd worden?
- Kan HTML vóór de request worden gemaakt?
- Hoe vers moeten de gegevens zijn?
- Hangt het resultaat af van cookies, sessie of request?
- Hoeveel routes moeten worden gegenereerd?
- Kan de pagina veilig worden gecachet?
- Hoeveel JavaScript moet de browser uitvoeren?
- Wat zijn echte LCP, INP, CLS en TTFB in productie?
