Artikel

Hydration — SSR og client-side JavaScript kombineret

Hydration er JSs overtagelse af en SSR-renderet side. Det giver interaktivitet uden at ofre SEO — men kan forårsage INP-problemer og TBT ved tung JavaScript-indlæsning.

Sidst opdateret:

Hydration er det tekniske navn for processen hvor client-side JavaScript overtager en server-renderet HTML-side og tilføjer interaktivitet. Det er fundamentet for moderne full-stack frameworks: serveren genererer komplet HTML — godt for SEO og initial load — og JavaScript attacher derefter event listeners og genopbygger Virtual DOM i browseren. Processen løser et grundlæggende problem, men har en reel performance-omkostning: JavaScript-bundlen skal downloades, parses og eksekveres inden siden er fuldt interaktiv, og et tungt bundle kan skabe en mærkbar forsinkelse der rammer INP og Time to Interactive.

Hvad sker der under hydration

Flowet er: server genererer HTML → browser modtager og viser HTML (hurtig FCP) → browser downloader JavaScript-bundle → JavaScript “hydraterer” siden ved at attache event listeners og genopbygge Virtual DOM → siden er nu fuldt interaktiv.

Det kritiske trin er downloading og eksekvering af JavaScript-bundlen. For en tung React- eller Next.js-applikation kan det betyde 200-500KB JavaScript der skal downloades, parseres og eksekveres, inden siden er interaktiv. Perioden fra FCP (siden vises) til TTI (siden er interaktiv) kaldes “hydration gap” — og det er her brugere klikker på ting der ikke reagerer.

Hydration og INP

Hydration er en primary source til INP-problemer. Under hydration-processen er main thread optaget med JavaScript-eksekvering — brugerinput kan ikke behandles. Klikker brugeren på en knap under hydration, er der ingen handler registreret endnu.

Det manifesterer sig som responsivitetsproblemer de første sekunder efter sideindlæsning — præcis den periode CrUX måler INP fra.

Partial hydration og islands

Islands architecture (brugt af Astro og andre frameworks) løser problemet ved at hydratere selektivt: kun interaktive “øer” på siden modtager JavaScript og hydrateres. En blogpost med en enkelt kommentarboks downloader og hydraterer kun kommentarboks-komponenten — ikke hele siden.

Resultatet er markant reduceret JavaScript-mængde og hurtigere TTI. For indholdssite er det den optimale tilgang: statisk indhold leveres som ren HTML, interaktive elementer hydrateres selektivt.

SEO-konsekvenser

Fra Googlebots perspektiv er en SSR+hydration-side ideel: Googlebot ser fuld HTML med det samme (ingen rendering-delay), og brugere får interaktivitet via JavaScript. Det er den bedste af to verdener — sammenlignet med ren CSR der tvinger Googlebot til at vente på JS-rendering. → Denne artikel er en del af JavaScript og rendering — Scripts, DOM og CSR vs SSR.

Del af: JavaScript og rendering — Scripts, DOM og CSR vs SSR →

Andre artikler i samme emne

Relaterede begreber

Emne JavaScript og rendering — Scripts, DOM og CSR vs SSR JavaScript er SEOs største rendering-udfordring — forstå CSR vs SSR, DOM, lazy loading og hvad Googlebot faktisk ser. Artikel Server-side rendering — SSR og fordele for SEO SSR leverer færdig HTML fra serveren — Googlebot ser straks indholdet uden rendering-kø, og FCP forbedres markant. Artikel Client-side rendering — CSR og SEO-udfordringer CSR genererer sidernes HTML i browseren — det er SEOs sværeste rendering-udfordring, da Googlebot skal vente på rendering. Artikel Next.js og SEO — Server-side rendering og SEO Next.js er den primære React-løsning for SEO-venlig rendering — med App Router, Metadata API og hybrid SSR/SSG i samme projekt. Det eliminerer de fleste JavaScript-SEO-problemer. Artikel INP-optimering — Interaction to Next Paint og Core Web Vitals INP måler tiden fra brugerinteraktion til næste visuelle opdatering. Det afløste FID som CWV-metrik i 2024 og kræver JavaScript-optimering for at forbedre. Emne Web Performance — Core Web Vitals og teknisk hastighed Web performance er en direkte SEO-rankingfaktor — Core Web Vitals, hastighed og responsivt design påvirker din placering.

Ofte stillede spørgsmål

Hvad er hydration mismatch?
En hydration mismatch opstår når client-side JavaScript renderer noget der afviger fra den server-renderede HTML. Det kan skyldes tidszoneforskelle, random-værdier, browser-specifikke APIs eller dynamisk indhold der ændrer sig mellem server og client render. Hydration mismatch kan forårsage layout shift og fejl i konsollen.
Hvad er partial hydration?
Partial hydration (eller islands architecture) hydraterer kun de dele af siden der er interaktive — fx en carousel eller en søgeboks. Statisk indhold som tekst og billeder hydrateres ikke og kræver ingen JavaScript. Det reducerer JavaScript-bundle-størrelse markant og forbedrer INP og TTI.
Hvad er lazy hydration og hvad er fordelen?
Lazy hydration udskyder hydration af komponenter til de er nødvendige — typisk til de er ved at blive synlige i viewport eller ved brugerinteraktion. Astro implementerer dette via client:visible og client:idle direktiver. Det reducerer JavaScript-eksekvering på load og forbedrer INP og Time to Interactive. Kritiske interaktive elementer above the fold bør ikke lazy hydrateres.
Påvirker hydration Googlebots indeksering?
Hydration er en client-side proces og påvirker ikke det Googlebot ser i fase 1 af crawling. Da hydration sker i browseren efter HTML-levering, er det det server-renderede HTML der indekseres i fase 1. JavaScript-drevet state-ændring under hydration der modificerer indhold kan dog give mismatch med det renderede DOM i Googlebots fase 2 rendering. Sørg for at kritisk indhold er i det server-renderede HTML, ikke afhænger af hydration.
Hvad er forskellen på hydration i React, Next.js og Astro?
React med ren CSR hydrerer hele applikationen — al JavaScript downloades og kører. Next.js SSR+hydration hydrerer hele sidetrættet men leverer komplet HTML til Googlebot. Astro bruger islands architecture og hydrerer kun interaktive øer via client-direktiver som client:load og client:visible — resten er statisk HTML uden JavaScript. For indholdssite er Astros tilgang optimal: minimalt JavaScript, ingen hydration-overhead for statisk indhold, og Googlebot ser fuld HTML fra første crawl.

Placering i ordbogen

Kode — Webkode og teknisk SEO
JavaScript og rendering — Scripts, DOM og CSR vs SSR
Hydration — SSR og client-side JavaScript kombineret