Spring til indhold
TBH
Tilbage til blog
9. januar 20264 min læsetid

SSG vs SSR vs ISR vs CSR: Hvad skal du vælge?

Du bygger en ny hjemmeside. Frameworket spørger: SSG, SSR, ISR eller CSR?

Hvis du har valgt forkert, finder du ud af det, når Google ikke indekserer dine sider, eller når dine brugere klager over load times.

Her er den enkle guide.

De fire rendering-strategier

SSG - Static Site Generation

Sider renderes ved build time og serveres som statiske HTML-filer.

Sådan virker det:

  1. Ved npm run build genereres alle sider som HTML
  2. HTML serveres direkte fra CDN
  3. JavaScript hydrerer for interaktivitet

Fordele:

  • Lynhurtig load (HTML er klar)
  • Perfekt SEO (Googlebot ser alt)
  • Billig hosting (CDN)
  • Høj sikkerhed (ingen server-logik)

Ulemper:

  • Ændringer kræver nyt build
  • Skalerer dårligt til tusindvis af sider
  • Data kan blive stale

Brug det til: Marketing sites, blogs, dokumentation.


SSR - Server-Side Rendering

Sider renderes på serveren ved hver request.

Sådan virker det:

  1. Bruger anmoder om side
  2. Server renderer HTML med frisk data
  3. HTML sendes til browser
  4. JavaScript hydrerer

Fordele:

  • Altid frisk data
  • God SEO (HTML er klar ved request)
  • Personalisering mulig (cookies, auth)

Ulemper:

  • Kræver server (dyrere hosting)
  • Langsommere TTFB (Time To First Byte)
  • Server-load ved høj trafik

Brug det til: E-commerce, nyhedssider, personaliseret indhold.


ISR - Incremental Static Regeneration

Det bedste fra SSG og SSR. Sider er statiske, men opdateres i baggrunden.

Sådan virker det:

  1. Første request serverer cached HTML
  2. I baggrunden regenereres siden med frisk data
  3. Næste request får den opdaterede version

Fordele:

  • Hurtig som SSG
  • Frisk data som SSR
  • Skalerer godt

Ulemper:

  • Kun visse frameworks (Next.js, Nuxt)
  • Kompleksitet i cache-invalidation
  • Første bruger ser potentielt stale data

Brug det til: Produktsider, blogs med hyppige opdateringer, store sites.


CSR - Client-Side Rendering

Browseren downloader en tom HTML-fil og JavaScript bygger hele siden.

Sådan virker det:

  1. Server sender <div id="root"></div>
  2. Browser downloader JavaScript bundle
  3. JavaScript kører og renderer UI

Fordele:

  • Hurtig navigation mellem sider (SPA-feeling)
  • Simpel hosting (bare statiske filer)
  • God til apps bag login

Ulemper:

  • Tom side indtil JS loader (dårlig First Contentful Paint)
  • SEO er svært: Googlebot skal køre JS
  • Store bundles = langsom initial load

Brug det til: Dashboards, admin-paneler, apps bag login.


SEO-implikationer

StrategiGoogle-indexeringFirst Contentful PaintData-freshness
CSRRisikabelLangsomReal-time
SSGPerfektHurtigstStale
SSRPerfektMediumReal-time
ISRPerfektHurtigNear real-time

Google og JavaScript: Google kan crawle JavaScript, men det er langsommere og mindre pålideligt. Hvis SEO er vigtigt, vælg SSG, SSR eller ISR.


Praktiske eksempler

Type hjemmesideAnbefalet strategi
Marketing landing pageSSG
BlogSSG eller ISR
E-commerce produktsiderISR
E-commerce kurv/checkoutSSR eller CSR
Dashboard bag loginCSR
NyhedssiteISR eller SSR
DokumentationSSG
Social media feedCSR med SSR for SEO-sider

Hybrid-tilgangen

De fleste moderne sites bruger flere strategier:

/                  → SSG (landing page)
/blog              → SSG eller ISR
/products/[id]     → ISR (mange sider, ofte opdateret)
/cart              → CSR (personlig, bag session)
/dashboard         → CSR (bag login)

Next.js, Nuxt og SvelteKit understøtter alt dette out of the box.


Vores anbefaling

  1. Start med SSG for alt statisk indhold
  2. Brug ISR for dynamisk indhold der skal være SEO-venligt
  3. Brug SSR kun når du har brug for personalisering eller real-time data
  4. Brug CSR bag login hvor SEO er irrelevant

Hvis du er i tvivl: ISR er den sikreste default for de fleste projekter i 2026.

Se, hvad vi har bygget

Nordvec, nævn.dk, Matematik i Måneby i browseren, Semantika og open source.

Se projekterne