Renderingsstrategi handlar om var och när din HTML genereras: i förväg vid bygget, på servern vid varje förfrågan, eller i webbläsaren hos besökaren. Beslutet känns tekniskt men får direkta affärskonsekvenser för hur väl du syns i Google, hur snabbt sidan känns och vad driften kostar varje månad. Här reder vi ut de fyra vanligaste modellerna och de hybrider som dominerar i 2026.

De fyra grundmodellerna

SPA – Single Page Application (CSR)

I en ren SPA skickar servern ett nästan tomt HTML-skal plus ett stort JavaScript-paket. Webbläsaren bygger sedan hela gränssnittet på klienten – så kallad Client-Side Rendering (CSR). Modellen ger en app-lik känsla med snabba övergångar mellan vyer efter den första laddningen, men priset är tungt: besökaren måste ladda ner och köra all JavaScript innan något meningsfullt syns, vilket pressar både laddningstid och responsivitet.

SPA passar bäst bakom inloggning – dashboards, admin-verktyg och interna appar där SEO inte spelar roll och där användaren stannar länge i samma session.

SSG – Static Site Generation

Med SSG genereras färdig HTML vid bygget och läggs ut på ett CDN. När en besökare kommer levereras statiska filer från en server nära användaren – det går inte att bli snabbare än så. Time to First Byte blir minimal, säkerhetsytan liten och kostnaden låg eftersom ingen server behöver räkna något per förfrågan.

Nackdelen är att innehållet är fryst tills nästa bygge. Har du tusentals sidor som ändras ofta blir build-tiderna långa och varje uppdatering kräver en ny deploy.

SSR – Server-Side Rendering

Vid SSR genereras HTML på servern för varje förfrågan. Besökaren – och sökmotorn – får färdig, aktuell HTML direkt, samtidigt som sidan kan vara helt personaliserad och alltid spegla färsk data. Det är idealiskt för innehåll som ändras per användare eller per sekund: priser, lagersaldo, sökresultat, inloggade vyer.

Kostnaden är att servern arbetar vid varje besök. Det innebär högre drift, beroende av servertillgänglighet och en TTFB som varierar med datakällornas svarstid.

ISR – Incremental Static Regeneration

ISR är hybriden som löser SSG:s största svaghet. Sidor serveras statiskt från CDN men regenereras i bakgrunden enligt ett intervall (revalidering) eller på begäran när innehåll ändras. Du får statikens hastighet och låga kostnad, men kan ändå uppdatera enskilda sidor utan att bygga om hela sajten.

I praktiken passar ISR perfekt för innehåll som ändras förutsägbart men inte per sekund: bloggar, dokumentation, produktkataloger och kampanjsidor. I Next.js sker on-demand-uppdateringar via revalidatePath() som invaliderar den cachade versionen och triggar en ny generering vid nästa förfrågan.

Så påverkar valet SEO

Sökmotorernas crawlers föredrar färdig HTML. SSR, SSG och ISR levererar alla fullständig markup direkt, vilket ger snabb och pålitlig indexering. En ren SPA är mer riskabel: innehållet existerar först efter att JavaScript körts, och även om Google kan rendera JavaScript så sker det i ett senare, resurskrävande steg som kan fördröja eller missa indexering – särskilt på stora sajter.

Lika viktigt är Core Web Vitals, som är en bekräftad rankingsignal. Den svåraste metriken just nu är Interaction to Next Paint (INP), som mäter responsivitet och bör ligga under 200 millisekunder. INP är ett stabilt Core Web Vital och den vanligaste metriken som sajter underkänns på. Tungt klientskript – signaturen hos SPA – är ofta den direkta orsaken till dålig INP, eftersom huvudtråden blockeras när all logik körs i webbläsaren. Förrenderade strategier som skickar minimalt med JavaScript har här ett strukturellt försprång.

Så påverkar valet prestanda

Rangordningen för upplevd hastighet är ganska tydlig: SSG är snabbast (färdig HTML från CDN), ISR ligger i praktiken lika högt, SSR är medel (serverberäkning per förfrågan) och ren CSR är långsammast eftersom allt renderas på klienten efter nedladdning.

Två tekniker har förskjutit bilden de senaste åren:

  • Streaming SSR skickar HTML i delar allt eftersom den renderas, i stället för att vänta på hela sidan. I kombination med React Server Components får besökaren ett skal direkt, vilket dramatiskt förbättrar den upplevda hastigheten även när total laddningstid är likartad.
  • Öarkitektur (islands), populariserad av Astro, renderar sidan som statisk HTML och hydrerar bara enskilda interaktiva komponenter via client:*-direktiv. JavaScript-paketet krymper till en bråkdel av en motsvarande SPA, vilket sänker Time-to-Interactive och lyfter Core Web Vitals.

Så påverkar valet kostnaden

Renderingsmodellen styr din driftkostnad mer än man tror. SSG och ISR lutar mot statiska filer på CDN, vilket gör drift billig och nästan oändligt skalbar – trafiktoppar tas av cachelagret, inte av en server. SSR innebär att infrastruktur arbetar vid varje förfrågan, vilket skalar med trafiken och därmed kostar mer i drift och kräver mer av övervakning och kapacitetsplanering.

Det finns också en kostnad i utvecklingstid: en ren SPA är ofta snabbast att komma igång med, medan väloptimerad SSR/ISR kräver mer arkitekturarbete kring cachning och datahämtning. Vad just ditt projekt landar på beror på trafikvolym, hur dynamiskt innehållet är, krav på personalisering och vilken plattform du driftar på. Vill du ha en konkret uppskattning utan gissningar kan du använda offertkalkylatorn.

Hybriderna vinner 2026

Den stora förändringen är att du inte längre behöver välja en strategi för hela sajten. Moderna ramverk låter dig blanda per sida eller till och med per komponent.

Tydligast syns det i Next.js 16, som släpptes hösten 2025 och gjorde Partial Prerendering (PPR) stabilt via den nya Cache Components-modellen. PPR låter en och samma sida servera ett statiskt, förrenderat skal direkt från cache medan dynamiska delar streamas in – slutet på den gamla antingen-eller-konflikten mellan SSG och SSR. I samma version blev Turbopack standard och React Compiler-stödet stabilt efter React Compiler 1.0.

Det praktiska 2026-receptet ser ofta ut så här:

  • Server Components som standard för icke-interaktivt innehåll – noll onödig JavaScript till klienten.
  • Client Components endast där interaktivitet faktiskt krävs.
  • SSG/ISR för innehållssidor – marknadsföring, blogg, dokumentation, produktkatalog.
  • SSR enbart för det som verkligen är per-förfrågan-dynamiskt – personaliserade och transaktionella vyer.

Beslutsguide: vad ska du välja?

  • Marknadssajt, blogg, dokumentation: SSG eller ISR. Maximal SEO och hastighet, minimal kostnad.
  • E-handel: ISR för produkt- och kategorisidor, SSR eller klientlogik för varukorg och kassa. PPR där plattformen stödjer det.
  • Innehållstung sajt med ofta uppdaterad men inte realtidsdata: ISR med on-demand-revalidering.
  • Starkt personaliserad eller realtidsstyrd produkt: SSR, gärna med streaming.
  • Internt verktyg eller dashboard bakom inloggning: SPA är fullt rimligt – SEO är irrelevant och rik interaktivitet är poängen.

Sammanfattning

Det finns ingen universellt bästa renderingsstrategi – det finns rätt strategi för rätt sida. SSG och ISR ger oslagbar SEO, hastighet och kostnadseffektivitet för innehåll. SSR vinner när data måste vara färsk och personlig. SPA hör hemma bakom inloggning. Och tack vare hybrider som PPR och öarkitektur kan du i dag kombinera det bästa ur varje värld på samma sajt.

Funderar du på vilken arkitektur som passar just ditt projekt – och hur den påverkar SEO, prestanda och budget? Vi på ZORC bygger snabba, sökoptimerade webbplatser och appar med moderna renderingsstrategier. Hör av dig via kontakt eller ta fram ett underlag direkt i offertkalkylatorn.