Varförstatisktgenereradesajtervinner:SSG,ISRochCoreWebVitalsipraktiken

Data från HTTP Archive och Chrome User Experience Report visar ett konsekvent mönster: mediansajten byggd med ett statiskt ramverk har en Largest Contentful Paint (LCP) runt 1–1,5 sekunder på mobil. Motsvarande siffra för en typisk WordPress-sajt ligger runt 2,5–3 sekunder. Det är inte en marginell skillnad, det är ungefär dubbelt så lång laddtid, och det påverkar allt från användarupplevelse till sökmotorranking.

Den här artikeln handlar om varför statiskt genererade sajter presterar så bra, vad tekniken faktiskt innebär, var gränserna går, och hur du avgör om det passar ditt projekt.

Vad SSG och ISR innebär

Static Site Generation (SSG)

SSG betyder att alla sidor genereras vid byggtid, innan sajten publiceras. När en besökare öppnar sidan finns det ingen server som kör kod, inga databasanrop, ingen rendering i realtid. Webbläsaren får en färdig HTML-fil direkt från ett CDN.

Processen ser ut ungefär så här:

1. Du skriver innehåll (i markdown, i ett headless CMS, i en databas)
2. Ett byggsteg genererar HTML, CSS och JavaScript för varje sida
3. Filerna laddas upp till ett CDN med noder över hela världen
4. Besökaren hämtar den närmaste kopian

Det betyder att den första besökaren och den hundratusende besökaren får exakt samma svarstid. Det finns ingen server som kan bli överbelastad, ingen databas som kan bli en flaskhals.

Verktyg som Next.js, Astro, Hugo och Gatsby stödjer alla SSG, men på olika sätt. Next.js och Astro ger dig flexibiliteten att blanda SSG med server-renderade sidor i samma projekt. Hugo genererar tusentals sidor på sekunder men är renodlat statiskt. Gatsby populariserade SSG i React-ekosystemet men har tappat mark de senaste åren till förmån för Next.js och Astro, som båda erbjuder mer flexibla renderingsstrategier.

En viktig distinktion: SSG handlar inte om att sajten inte kan ha interaktivitet. JavaScript körs fortfarande i webbläsaren. Du kan ha animationer, formulär, dynamiska filtreringar, allt som körs klient-sidans. Skillnaden är att den initiala HTML-filen inte genereras av en server vid varje request, utan serveras färdigbyggd.

Incremental Static Regeneration (ISR)

ISR lades till i Next.js 9.5 i juli 2020 och löser det mest uppenbara problemet med SSG: att hela sajten måste byggas om när innehåll ändras.

Med ISR kan du ange att en sida ska genereras statiskt, men att den ska uppdateras i bakgrunden efter ett visst tidsintervall. I praktiken fungerar det så här:

1. Sidan genereras vid byggtid, precis som vanlig SSG
2. Du anger en revalidate-tid, till exempel 60 sekunder
3. Under de 60 sekunderna får alla besökare den cachade versionen
4. När tiden gått ut och en ny förfrågan kommer in, serveras den gamla versionen medan en ny genereras i bakgrunden
5. Nästa besökare efter det får den uppdaterade versionen

Det här mönstret kallas stale-while-revalidate och är samma princip som HTTP-cachen har använt i decennier. Ingen besökare behöver vänta på att sidan genereras. De får alltid en cachad version medan uppdateringen sker bakom kulisserna.

Next.js stödjer dessutom on-demand revalidation, där du triggar en regenerering via ett API-anrop. Det gör att du kan koppla ihop ett CMS med ISR: redaktören publicerar nytt innehåll, CMS:et skickar en webhook till din applikation, och den specifika sidan regenereras omedelbart utan att resten av sajten påverkas.

Core Web Vitals: vad datan visar

Google använder tre mätvärden för att bedöma användarupplevelsen:

• LCP (Largest Contentful Paint): Hur snabbt det största synliga innehållet laddas. Bra: under 2,5 sekunder.
• CLS (Cumulative Layout Shift): Hur mycket layouten hoppar runt medan sidan laddar. Bra: under 0,1.
• INP (Interaction to Next Paint): Hur snabbt sidan svarar på klick och interaktioner. Bra: under 200 millisekunder.

Dessa mätvärden är sedan 2021 en rankingfaktor i Google Search. De mäts på riktiga användares enheter via Chrome User Experience Report (CrUX), inte i labbmiljö.

LCP: den största skillnaden

HTTP Archive-data visar konsekvent att SSG-sajter har lägre LCP än server-renderade CMS-sajter. Medianvärdet för SSG-sajter på mobil ligger runt 1,2 sekunder, medan WordPress-sajter ligger runt 2,8 sekunder. Drupal hamnar ofta i samma spann som WordPress, ibland något bättre.

Skillnaden beror inte bara på att koden är bättre skriven. Det handlar om arkitektur: en SSG-sajt serverar en färdig HTML-fil från ett CDN-edge. En WordPress-sajt kör PHP, gör databasanrop, monterar ihop sidan med tio-tjugo plugins, och skickar resultatet till besökaren. Caching-plugins kan förbättra det avsevärt, men de lägger till komplexitet och konfigurationen går lätt sönder vid uppdateringar.

CLS: layoutstabilitet

SSG-sajter presterar generellt bättre på CLS också, men skillnaden är mindre dramatisk. Den stora boven för CLS är annonser, bilder utan definierade dimensioner och tredjepartsskript som injicerar element i DOM:en. Det kan hända på vilken sajt som helst, men WordPress-sajter drabbas oftare på grund av plugin-ekosystemet. Varje plugin som lägger till en banner, ett formulär eller en notifiering riskerar att orsaka layoutskift.

INP: interaktionssvarstid

INP ersatte FID (First Input Delay) som Core Web Vital i mars 2024. Det mäter svarstiden för alla interaktioner, inte bara den första. Här syns skillnaden främst i mängden JavaScript: en typisk SSG-sajt levererar ofta 50-150 kB JavaScript (komprimerat), medan en WordPress-sajt med WooCommerce, kontaktformulär och analytics-plugins kan ligga på 400-800 kB. Mer JavaScript betyder längre parsningstid, längre exekveringstid och sämre INP, särskilt på billiga Android-telefoner med långsamma processorer.

En viktig nyansering

Siffrorna ovan är medianvärden. En väloptimerad WordPress-sajt med rätt caching, optimerade bilder och minimal plugin-användning kan absolut ha bättre Core Web Vitals än en dåligt konfigurerad SSG-sajt med tunga JavaScript-bundles. Arkitekturen ger SSG en fördel som utgångspunkt, men det är inte en garanti.

Det är också värt att påpeka att WordPress-ekosystemet aktivt jobbar med prestanda. Projekt som WordPress Performance Team har infört lazy loading av bilder som standard (WordPress 5.5), fetchpriority-attribut (WordPress 6.3) och speculative loading för snabbare navigering (WordPress 6.8). Gapet minskar, men det arkitekturella övertaget kvarstår: en statisk fil från ett CDN kräver noll bearbetning per request.

Hosting och kostnad

En av de mest konkreta fördelarna med statiska sajter är hosting-kostnaden.

Gratis för de flesta

Eftersom en statisk sajt bara är filer som serveras från ett CDN, erbjuder flera plattformar generösa gratistjänster:

• Vercel: 100 GB bandbredd per månad, automatiska deploys från Git, inbyggd CI/CD, edge-nätverket levererar filer från närmaste nod
• Netlify: 100 GB bandbredd per månad, formulärhantering, serverless functions, branch deploys
• Cloudflare Pages: Obegränsad bandbredd på gratisplanen, integration med Cloudflare Workers och R2-lagring

För en företagssajt med 5 000-50 000 besökare per månad räcker gratisplanerna med god marginal. SSL-certifikat ingår, CDN ingår, CI/CD ingår. Du pushar till Git, sajten byggs och publiceras automatiskt.

Jämfört med WordPress-hosting

Managed WordPress-hosting kostar typiskt 20-50 dollar per månad för en enstaka sajt med acceptabel prestanda. Det inkluderar servern, databasen, SSL, dagliga backuper och ofta ett caching-lager. Billigare delade hosting för 5-10 dollar per månad finns, men prestandan lider märkbart. Just de miljöerna är ofta anledningen till att WordPress-sajter mäter dåligt i Core Web Vitals.

Om du räknar över tre år, med ett par domäner, ser skillnaden ut ungefär så här:

• SSG (Vercel/Netlify): Domänkostnad, eventuellt en betalplan om trafiken växer. Kanske 0-200 kr/månad.
• WordPress (managed): Hosting 200-500 kr/månad, plus eventuella premium-plugins. Säkerhetsplugins, backup-plugins och caching-plugins kostar ofta extra.

Det här är inte en rättvis jämförelse i alla fall. WordPress ger dig ett adminpanel ur lådan, medan en SSG-sajt med headless CMS kan kräva mer initial setup-tid. Men den löpande driftkostnaden är märkbart lägre.

CI/CD ingår

Med en SSG-sajt på Vercel, Netlify eller Cloudflare Pages får du ett komplett deployment-flöde utan extra konfiguration. Varje pull request genererar en preview-URL. Varje merge till main-branchen triggar ett bygge och en deploy. Rollbacks är ett klick bort, eftersom varje deploy är en komplett snapshot av sajten.

I WordPress-världen kräver motsvarande setup antingen ett specialiserat verktyg som SpinupWP eller WP Engine DevKit, eller en manuellt konfigurerad pipeline. Det fungerar, men det är ytterligare ett lager att underhålla.

Det finns också en subtil fördel med hur SSG-deploys fungerar: eftersom varje deploy är en komplett, immutabel snapshot av sajten kan du alltid gå tillbaka till exakt det tillstånd sajten var i igår, förra veckan eller förra månaden. Med en databasdriven sajt som WordPress är det svårare. Du behöver koordinera databas-backuper med filsystem-backuper och hoppas att de matchar.

Säkerhet

Det här är kanske den mest underskattade fördelen med statiska sajter.

Ingen server, ingen attackyta

En SSG-sajt har ingen körande server i traditionell mening. Det finns ingen databas att göra SQL-injektioner mot. Inget PHP att exploatera. Inga inloggningssidor att brute-forcea. Filerna ligger på ett CDN och serveras som de är.

Det eliminerar inte alla säkerhetsrisker (du har fortfarande klient-sidans JavaScript, tredjepartsberoenden och eventuella API:er), men det tar bort hela kategorier av attacker som drabbar traditionella CMS.

WordPress och säkerhetshål

WordPress driver ungefär 43% av alla webbplatser på internet (2024-data från W3Techs). Den dominansen gör det till det överlägset vanligaste målet för automatiserade attacker. Enligt WPScans databas rapporteras tusentals nya säkerhetshål i WordPress-plugins varje år. En stor andel av dessa finns i populära plugins med miljontals installationer.

WordPress-kärnan i sig har blivit betydligt säkrare under åren. De flesta intrång sker via tredjepartsplugins och teman som inte uppdaterats i tid. Men det är just det som är problemet: en typisk WordPress-sajt använder 20-30 plugins, och varje plugin är en potentiell ingångspunkt. Du måste hålla alla uppdaterade, testa att uppdateringarna inte krockar med varandra, och hantera det faktum att vissa plugin-utvecklare slutar underhålla sina produkter.

Med en statisk sajt existerar inte det problemet i produktionsmiljön. Dina beroenden finns i build-steget, inte på den serverade sajten.

Angreppsvinkeln förskjuts

Det ska sägas att en SSG-sajt inte är immun. Om du använder ett headless CMS har det en inloggning som kan attackeras. Om du har serverless functions exponerar de ett API. Supply chain-attacker via npm-paket är ett reellt hot, men de påverkar bygget, inte den live-serverade sajten (med undantag för klient-sidans JavaScript-beroenden). Attackytan är dramatiskt mindre och mer kontrollerad. Du väljer medvetet vad som exponeras, istället för att ha en komplett LAMP-stack öppen mot internet.

En annan praktisk fördel: DDoS-skydd är i princip inbyggt. CDN-leverantörer som Cloudflare, Vercel och Netlify har DDoS-mitigation som standard. Att överbelasta ett CDN som serverar statiska filer är svårt och dyrt för angriparen. Att överbelasta en enstaka WordPress-server med en ström av requests som triggar databas-frågor och PHP-exekvering är avsevärt enklare.

ISR för dynamiskt innehåll

Det traditionella argumentet mot statiska sajter har alltid varit: "men mitt innehåll ändras ofta". ISR adresserar det direkt.

Praktiska scenarion

Nyhetssajt med 500 artiklar: Alla artiklar genereras statiskt vid byggtid. När en ny artikel publiceras triggar CMS:et en on-demand revalidation via webhook. Bara den nya artikeln genereras. De andra 499 påverkas inte. Besökare får alltid en cachad version, aldrig en laddtid kopplad till databasanrop.

E-handelssajt med produktpriser: Produktsidor genereras med ISR och en revalidate-tid på 60 sekunder. Prisändringar syns inom en minut. Alternativt triggar produktdatabasen en on-demand revalidation vid prisändring så uppdateringen syns direkt.

Företagssajt med blogg: Blogginlägg genereras statiskt. Informationssidorna genereras statiskt. Kontaktformuläret skickar data via en serverless function eller en extern tjänst som Formspree. Hela sajten är statisk förutom den enda POST-requesten från formuläret.

Hur det fungerar i Next.js

I Next.js App Router anger du caching-beteende per route segment. En sida med export const revalidate = 60 serveras statiskt och regenereras var 60:e sekund. Med revalidatePath('/blogg/min-artikel') eller revalidateTag('products') kan du trigga regenerering programmatiskt.

Det innebär att du kan ha en sajt som beter sig som en dynamisk sajt för redaktörer och besökare, men som under huven serverar förrenderade HTML-filer från ett CDN. Du får prestandan från SSG med flexibiliteten från ett traditionellt CMS.

Begränsningen med ISR

ISR fungerar utmärkt för innehåll som uppdateras i förutsägbara mönster: blogginlägg, produktsidor, nyhetssidor, dokumentation. Men det förutsätter att du kan tolerera att innehållet är sekunderna-till-minuter gammalt. Exakt realtid kräver en annan arkitektur.

När SSG inte passar

SSG och ISR har tydliga begränsningar. Det är viktigt att vara ärlig om dem.

Realtidsdata

Dashboards, live-uppdateringar, chattapplikationer, aktiediagram. Allt som kräver data som uppdateras sekund för sekund passar inte för SSG. Där behöver du server-side rendering (SSR) med streaming, WebSockets eller server-sent events. Du kan kombinera: ha marknadsföringssidor som SSG och dashboard-delen som SSR i samma Next.js-projekt, men dashboarden i sig är inte statisk.

Starkt personaliserat innehåll

Om varje besökare ska se unikt innehåll baserat på deras profil, historik och preferenser kan du inte förrendera det statiskt (du vet inte vid byggtid vad besökare X vill se). Personalisering kräver server-logik eller klient-sidans rendering. En vanlig kompromiss är att servera en statisk shell och fylla i personaliserat innehåll via API-anrop efter laddning, men det ger en flash-of-generic-content som kan vara störande.

Sajter med miljontals sidor och frekvent uppdatering

En sajt med 5 miljoner produktsidor där 100 000 av dem uppdateras dagligen kan bli opraktisk att hantera med ISR. Byggtiderna blir långa och mängden bakgrundsgenerering belastar infrastrukturen. Storskaliga e-handelsplattformar som Zalando eller Amazon använder SSR och edge-rendering av en anledning.

Det ska tilläggas att Next.js hanterar detta bättre än man kan tro tack vare on-demand revalidation: du regenererar bara de sidor som faktiskt ändrats. Men det finns en gräns där komplexiteten överstiger vinsten.

Användargenererat innehåll

Forum, kommentarssystem, sociala plattformar, platser där användare skapar innehåll i hög takt, passar dåligt för SSG. Varje nytt inlägg skulle kräva en regenerering, och med tusentals nya inlägg per timme blir det ohållbart. Server-side rendering eller klient-side rendering med API:er är bättre lösningar här.

Komplexa autentiseringsflöden

Om hela sajten sitter bakom inloggning och varje sida kräver autentisering, ger SSG begränsat värde. Du kan fortfarande servera skalstruktur statiskt och ladda skyddat innehåll klient-sidans, men det är inte den typiska SSG-användningen.

Beslutsstöd: vilken renderingsmetod passar ditt projekt?

Istället för att tänka SSG kontra SSR som ett binärt val, är det mer produktivt att tänka per sida eller per sektion. Moderna ramverk som Next.js och Astro låter dig blanda renderingsmetoder i samma projekt.

SSG passar om

• Innehållet uppdateras sällan till måttligt ofta (dagligen eller mer sällan)
• Alla besökare ser samma innehåll
• Prestanda och laddtid är viktiga (vilket det alltid borde vara, men särskilt för marknadsföringssajter, landningssidor och SEO-drivet innehåll)
• Du vill minimera driftkostnad
• Sajten har upp till tiotusentals sidor

Typiska projekt: företagssajter, portfolios, bloggar, dokumentationssajter, landningssidor, enklare e-handel med relativt statiskt sortiment.

ISR passar om

• Innehållet uppdateras regelbundet men inte i realtid
• Du har ett headless CMS eller en databas som källa
• Sajten har hundratals till tiotusentals sidor
• Du vill ha SSG-prestanda men med färskt innehåll utan manuella deploys

Typiska projekt: nyhetssajter, bloggar med hög publiceringshastighet, e-handel med prisändringar, eventlistor.

SSR passar om

• Innehållet är personaliserat per besökare
• Du behöver realtidsdata
• Sajten sitter bakom autentisering
• Varje request kan ge olika resultat beroende på cookies, geolokation eller andra faktorer

Typiska projekt: dashboards, inloggade portaler, konfigurationsverktyg, personaliserade e-handelsupplevelser.

Hybrid (det vanligaste i praktiken)

De flesta moderna projekt landar i en hybrid. Startsidan är SSG. Bloggen använder ISR. Användarens kontosidor är SSR. Sökresultat renderas klient-sidans. Ramverken stödjer det här utan problem, och du behöver inte välja ett enda läge för hela sajten.

Praktiska steg om du vill gå mot SSG

Om du har en befintlig sajt (WordPress eller annat) och överväger att migrera till SSG, finns det några saker att tänka igenom:

Inventera ditt innehåll. Hur många sidor har du? Hur ofta uppdateras de? Vilka sidor kräver dynamisk funktionalitet? En sajt med 50 sidor och ett kontaktformulär är ett annat projekt än en sajt med 10 000 produktsidor och varukorg.

Välj innehållskälla. Du kan använda markdown-filer, ett headless CMS (Sanity, Contentful, Storyblok, Payload) eller till och med WordPress som headless CMS via REST API eller WPGraphQL. Redaktörer behöver inte ändra arbetsflöde. De jobbar i CMS:et, sajten bygger om automatiskt.

Välj ramverk utifrån behov. Astro är utmärkt för innehållssajter med minimal interaktivitet och skickar noll JavaScript som default. Next.js ger dig mer flexibilitet om du behöver server-logik, ISR och API-routes. Hugo är extremt snabbt för rent statiskt innehåll.

Mät före och efter. Kör PageSpeed Insights och CrUX-data på din nuvarande sajt innan migrering. Gör samma sak efteråt. Konkreta siffror gör det enklare att motivera insatsen internt.

Planera redirects. Om URL-strukturen ändras vid migrering, se till att alla gamla URLs redirectar korrekt (301). Missade redirects kostar sökmotorranking och ger besökare 404-sidor.

Var realistisk med tidsplanen. En enkel företagssajt kan migreras på en till två veckor. En komplex sajt med e-handel, flerspråkighet och tusentals sidor kan ta månader. Fördelen är att du gör arbetet en gång och sedan drar nytta av lägre driftkostnad, bättre prestanda och mindre underhåll löpande.

SSG i praktiken: vad siffrorna säger

SSG och ISR erbjuder mätbara fördelar i laddtid, kostnad och säkerhet jämfört med traditionella server-renderade CMS. HTTP Archive-data bekräftar att skillnaden i Core Web Vitals är märkbar, och gratis CDN-hosting gör att driftkostnaden kan bli i princip noll för de flesta sajter.

Men det är inte rätt lösning för allt. Realtidsdata, starkt personaliserat innehåll och sajter i extrem skala kräver andra arkitekturer. Det vanligaste i praktiken är att kombinera: statiskt där det går, server-renderat där det behövs.

Den viktigaste frågan att ställa sig är inte "vilken teknik är bäst?" utan "vilken renderingsmetod passar varje del av min sajt?". Med moderna ramverk behöver du inte längre välja en enda strategi. Du kan använda rätt verktyg för rätt del av problemet.