SSR vinner i 2026: Hvorfor server-rendret HTML slår SPA

Bygde du Next.js-app i 2023 og lurer nå på om du tok feil valg? Vi deler tall fra norske Wagtail-prosjekter og forklarer hvorfor «kjedelig» HTML plutselig er den smarteste arkitekturen i 2026.

utvikler som sitter ved pc og jobber

Bygde du på feil hest i 2022?

Husker du da alle skulle ha en Next.js-side? Vi gjør det. Mellom 2022 og 2024 ble det nærmest standardsvaret når en SMB skulle bygge ny nettside: React, hydration, en stor JavaScript-bundle, og et løfte om at alt skulle bli «raskere» og «mer moderne». Mange av disse sidene står fortsatt — og eierne lurer nå på om de tok feil valg.

For noe har skiftet i 2026. Astro, HTMX, Rails 8 og Django med htmx vokser raskt. Store aktører flytter seg tilbake mot server-rendret HTML. Og det er ikke nostalgi som driver det — det er to konkrete krefter: AI-crawlerne som plukker opp innhold til ChatGPT, Perplexity og Google AI Overviews kjører fortsatt ikke JavaScript skikkelig, og Core Web Vitals straffer tunge bundles hardere enn før. Hvis du har en SPA bygget for tre år siden, er det verdt å lese videre.

Hva skjedde med SPA-drømmen?

SPA-en — Single Page Application — var et svar på et reelt problem. Tidlig på 2010-tallet var nettsider trege å navigere mellom, og React og Vue lovet en app-lignende opplevelse i nettleseren. Du laster siden én gang, så håndterer JavaScript resten. Smooth overganger, ingen page reloads, alt føles raskt — i hvert fall etter den første lastingen.

Problemet er at «den første lastingen» ble verre og verre. En typisk Next.js-side i 2023 sendte 300-500 kB JavaScript ned til nettleseren før noe vises. På en gammel Android-telefon på 4G i en bygd på Vestlandet betyr det 4-6 sekunder før innholdet er interaktivt. Google's Core Web Vitals — særlig Largest Contentful Paint (LCP) og Interaction to Next Paint (INP) — måler nettopp dette, og terskelene har blitt strengere. En LCP på under 2,5 sekunder er kravet for «god» rangering. Mange hydrate-tunge SPA-er ligger på 3,5-5 sekunder på mobil.

Så kom AI-søket. ChatGPT, Claude, Perplexity og Google's AI Overviews henter innhold fra nettet via crawlere som — i motsetning til Googlebot — i praksis ikke kjører JavaScript. Hvis innholdet ditt bare finnes etter at React har hydratert, finnes det ikke for dem. Du blir usynlig i den nye søkeoverflaten.

Kjedelig HTML, rask side

Server-rendret HTML er ikke nytt. Det er det weben gjorde fra 1995 til 2014. Du ber om en URL, serveren sender ferdig HTML, nettleseren tegner det. Ingen ventetid på en JavaScript-bundle som må parses og kjøres før innholdet vises.

Det nye er at verktøyene rundt SSR har modnet kraftig. Astro lar deg skrive komponenter som ligner React, men sender null JavaScript til klienten med mindre du eksplisitt ber om det («islands architecture»). HTMX gir deg interaktivitet — skjemaer som oppdaterer seg uten reload, modaler, live-søk — gjennom HTML-attributter, med 14 kB bibliotek totalt. Rails 8 kommer med Hotwire og Turbo ut av boksen. Django + htmx er kombinasjonen vi har sett vokse mest blant norske utviklere i 2025 og 2026.

Felles for alle disse: serveren gjør jobben, nettleseren får ferdig HTML, og JavaScript brukes som krydder — ikke som hovedingrediens. Resultatet er sider som laster på 0,4-1,2 sekunder på mobil, indekseres umiddelbart av både Google og AI-crawlere, og koster mindre å drifte fordi du ikke trenger en Node.js-edge-runtime for hver request.

Tall fra virkeligheten

La oss bli konkrete. Vi har målt før-og-etter på flere Wagtail-baserte prosjekter vi har tatt over fra tidligere SPA-stacker. Tallene er hentet fra Chrome User Experience Report (CrUX) og PageSpeed Insights, målt på reelle besøk fra norske mobilbrukere.

En typisk Next.js-side med App Router, hentet fra en SMB i Bergen i 2024: LCP 3,8 sekunder, TTFB 680 ms, total JavaScript 420 kB. Etter migrering til Wagtail med server-rendret HTML og htmx for de få interaktive bitene: LCP 1,1 sekunder, TTFB 180 ms, total JavaScript 22 kB. Samme innhold, samme design — bare en annen leveringsmekanisme.

SEO-effekten kommer i to bølger. Først forbedres Core Web Vitals umiddelbart, noe Google bruker direkte som rangeringssignal. Deretter — og dette er det mange undervurderer — begynner sidene å dukke opp i AI-søkesvar. Vi har sett sider gå fra null siteringer i Perplexity til å bli sitert ukentlig, bare ved å gjøre innholdet leselig uten JavaScript. Det er GEO — Generative Engine Optimization — i praksis.

Slik vurderer du om du bør migrere

Du trenger ikke bygge alt på nytt fra dag én. Her er en pragmatisk sjekk vi gjør med kunder før vi anbefaler noe som helst.

PT3H Tilgang til Google Search Console PageSpeed Insights eller WebPageTest En liste over de 10 viktigste sidene dine (forside, tjenester, kontakt, topp blogginnlegg)
  1. Mål dagens Core Web Vitals

    PT20M

    Kjør PageSpeed Insights på forsiden og 3-5 viktige undersider. Noter LCP, INP og CLS for mobil. Ligger LCP over 2,5 sekunder eller INP over 200 ms på flere sider, har du et reelt rangerings-problem allerede i dag.

  2. Sjekk hva crawlere faktisk ser

    PT15M

    Bruk «View Source» (ikke «Inspect») i nettleseren på en viktig side. Ser du brødteksten og overskriftene som ren HTML? Eller er body nesten tom med en stor script-tag? Det siste betyr at AI-crawlere ikke ser innholdet ditt.

  3. Test i AI-søk

    PT30M

    Spør Perplexity og ChatGPT om noe ditt firma burde være eksperter på. Dukker dere opp som kilde? Hvis konkurrenter med svakere innhold blir sitert mens dere ikke gjør det, er det ofte fordi de har server-rendret HTML og dere ikke har det.

  4. Vurder gradvis migrering

    PT1H

    Du trenger ikke kaste alt. Mange kunder begynner med å flytte de mest trafikkerte sidene — forside, tjenester, blogg — til en SSR-stack, og lar SPA-en stå for innloggede deler. Astro og Wagtail støtter begge dette godt.

  5. Sett opp måling før kutt

    PT45M

    Legg inn GA4 og Search Console-baseline FØR migreringen. Da kan du dokumentere effekten — både Core Web Vitals, organisk trafikk og AI-siteringer — over 3-6 måneder etter lansering.

Når SPA fortsatt er riktig valg

Vi skal ikke late som om server-rendret HTML er løsningen på alt. SPA-er har fortsatt sin plass — bare ikke som default for innholds-tunge nettsider.

Bygger du et CRM-grensesnitt, en designverktøy-app, en spillmotor i nettleseren, eller noe som ligner mer på Figma enn på en blogg? Da gir SPA-arkitekturen mening. Brukerne logger inn, sitter lenge i appen, og SEO er irrelevant fordi innholdet uansett er bak innlogging. Her er React, Vue og Svelte fortsatt utmerkede valg.

Tommelfingerregelen vi bruker: hvis sidene dine skal indekseres, deles på sosiale medier eller siteres av AI — server-render dem. Hvis brukeren er logget inn og jobber i et grensesnitt — SPA er greit. Mange prosjekter trenger begge deler, og da bygger vi en hybrid: SSR for det offentlige, SPA for app-delen, samme designsystem på tvers.

Slik jobber vi med dette

Hos oss er Wagtail + Django default-stacken når en SMB skal ha en nettside som skal rangere godt og holde i mange år. Vi bruker htmx for interaktivitet, og legger til Next.js eller Astro kun der det faktisk gir verdi — typisk for headless-oppsett mot Shopify. På utviklings-prosjekter de siste to årene har vi konsekvent sett LCP under 1,5 sekunder og TTFB under 250 ms fra norske servere, samtidig som driftskostnaden ofte er halvparten av en tilsvarende Node-basert edge-løsning. Det er ikke magi — det er bare å velge riktig verktøy for jobben.

Vanlige spørsmål

Betyr dette at Next.js er død?

Nei. Next.js har faktisk beveget seg sterkt mot server-rendring selv, med App Router og React Server Components. Problemet er ikke Next.js som rammeverk, men hvordan det ble brukt i 2022-2024 — som en tung SPA med client-side rendering som default. Brukt riktig, med Server Components og minimalt med klient-JavaScript, kan Next.js levere gode tall. Men for mange SMB-er er Astro eller Wagtail enklere å vedlikeholde og gir samme resultat.

Hvor lang tid tar en typisk migrering?

For en SMB-side med 20-50 sider tar en full migrering vanligvis 6-10 uker fra kickoff til lansering. Det inkluderer innholdsmigrering, redesign der det trengs, og oppsett av redirects så du ikke mister SEO-verdi. Mindre sider kan gjøres på 3-4 uker. Vi anbefaler å migrere i én operasjon framfor gradvis — det gir renere data og enklere måling av effekt.

Mister jeg SEO-rangeringer under migreringen?

Hvis URL-strukturen endres, må du sette opp 301-redirects fra gamle til nye URL-er. Gjort riktig holder du 95-100 % av rangeringene, og ser ofte forbedring innen 4-8 uker fordi Core Web Vitals blir bedre. Gjort feil — uten redirects eller med duplicate content — kan du miste 30-50 % av organisk trafikk. Dette er den viktigste tekniske detaljen å få riktig.

Hva med AI-søk spesifikt — hvordan optimaliserer jeg for det?

Tre ting i prioritert rekkefølge: server-render innholdet så crawlerne faktisk leser det, struktur innholdet semantisk med tydelige overskrifter og avsnitt, og legg inn schema.org-markup (FAQPage, Article, HowTo) der det passer. AI-modellene plukker opp innhold som er konkret, kildebelagt og lett å sitere — så skriv som om noen skal sitere deg i et svar, ikke som markedsføringstekst.

Kan jeg beholde React-komponentene mine?

Delvis. Astro lar deg bruke eksisterende React-, Vue- eller Svelte-komponenter som «islands» — de kjører på serveren som standard og hydreres bare hvis du eksplisitt trenger interaktivitet. Hopper du til Wagtail eller Django, må komponentene skrives om til templates, men logikken og designsystemet kan gjenbrukes. I praksis ender de fleste prosjekter opp med å forenkle koden betydelig under migrering.

Hvor mye sparer jeg i driftskostnad?

Varierer med trafikk, men typisk 40-70 % for SMB-sider. En Next.js-side på Vercel med moderat trafikk koster ofte 800-2500 kr/måned. Tilsvarende Wagtail-side på en vanlig VPS hos Hetzner eller DigitalOcean ligger på 200-600 kr/måned, ofte med bedre svartider fra norske brukere fordi du kan velge en europeisk datasenter-lokasjon.

Vurderer du å migrere fra SPA til SSR?

Vi tar en uforpliktende gjennomgang av sidens Core Web Vitals og hva en migrering faktisk vil koste — i tid og penger.