som en
Artikel

Kritisk renderingsti — Hvad browseren gør før du ser noget

Den kritiske renderingsti er trin-for-trin-processen browseren følger fra HTML-download til første synlige pixel. Render-blocking ressourcer forlænger stien og forsinker LCP.

Sidst opdateret:

Inden en bruger ser en eneste pixel, gennemgår browseren en sekvens af trin: download HTML, parser HTML og byg DOM, download CSS, byg CSSOM, kombiner DOM og CSSOM til render tree, beregn layout, paint piksler. Den kritiske renderingsti er alle de trin der skal gennemføres, inden browseren kan vise noget.

Enhver ressource der forlænger denne sti, forsinker LCP.

HTML-parsing og DOM

Browseren parser HTML fra top til bund og bygger DOM (Document Object Model). Støder den på et eksternt stylesheet eller script, stoppes parsingen — browseren venter på at ressourcen downloades og processeres. Det er render-blocking.

CSS blokerer altid rendering

Al CSS er render-blocking per design. Browseren kan ikke rendere noget, inden den ved, hvad der skal styles. Det er korrekt opførsel — en side vist uden CSS ville være ubrugelig. Konsekvensen er at alle stylesheets i <head> skal downloades og parseres, inden render begynder.

Optimeringer: Inlinet critical CSS (fold-above styling direkte i <head>) og defer af ikke-kritisk CSS med media attributten:

<link rel="stylesheet" href="/print.css" media="print">
<link rel="stylesheet" href="/below-fold.css" media="(min-width: 9999px)">

Den anden linje indlæser stylesheetet asynkront (browser ignorerer media-queries der ikke matcher).

JavaScript og render-blocking

Et <script>-tag uden attributter er fuldt render-blocking: browseren stopper HTML-parsing, henter scriptet, eksekverer det, og fortsætter. Løsningen:

<!-- Render-blocking: -->
<script src="/app.js"></script>

<!-- Ikke render-blocking: -->
<script src="/app.js" defer></script>
<script src="/analytics.js" async></script>

Flyt alle scripts til bunden af <body> eller brug defer/async.

Hvad Lighthouse måler

Lighthouse’s “Eliminate render-blocking resources” er en direkte måling af den kritiske renderingsti. Den estimerer tidsbesparelsen ved at fjerne eller defer-re render-blocking ressourcer. Det er et udgangspunkt for analyse — men den faktiske gevinst afhænger af netværkskonditioner og cache-status.

For LCP-optimering er prioriteringen klar: minimer ressourcer på den kritiske sti, preload LCP-ressourcen, og sørg for at LCP-elementet ikke afhænger af JavaScript-eksekvering. → Denne artikel er en del af Web Performance — Core Web Vitals og teknisk hastighed.

Del af: Web Performance — Core Web Vitals og teknisk hastighed →

Andre artikler i samme emne

Relaterede begreber

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. Artikel LCP-optimering — Sådan forbedrer du Largest Contentful Paint LCP-optimering handler om at identificere LCP-elementet og fjerne det der forsinker dets indlæsning — billeder, TTFB og render-blocking ressourcer er de hyppigste syndere. Artikel Resource hints — Preload, prefetch og preconnect til SEO Preload, prefetch og preconnect er HTML-hints der fortæller browseren hvad den skal hente tidligt. Korrekt brug forbedrer LCP og sideindlæsning markant. Artikel Scripts og SEO — render-blocking, async og defer Render-blocking scripts forsinker sidens indlæsning og påvirker både Core Web Vitals og Googlebots evne til at crawle siden effektivt. Artikel Font-optimering — Webfonts, FOUT og SEO Webfonts kan forsinke render og forårsage layout shift. WOFF2, font-display: swap og preload af kritiske fonte er de primære optimeringer. Artikel Tredjepartsscripts — Analytics, ads og performance-konsekvenser Tredjepartsscripts fra analytics, ads og chattools konkurrerer med dit indhold om main thread. De er hyppige årsager til dårlig INP og forhøjet TTFB.

Ofte stillede spørgsmål

Hvad er render-blocking?
En render-blocking ressource er CSS eller JavaScript der forhindrer browseren i at rendere siden, mens ressourcen hentes og parseres. Browseren stopper al rendering indtil render-blocking ressourcer er processeret. Klassiske eksempler: `<link rel='stylesheet'>` i head og `<script src='...'></script>` uden async/defer.
Hvad er forskellen på async og defer til scripts?
Begge henter scriptet asynkront og blokerer ikke parsing. Forskellen er eksekveringstidspunkt: async eksekverer scriptet så snart det er hentet (kan afbryde parsing). Defer eksekverer scriptet efter HTML er fuldt parseret men før DOMContentLoaded. Brug defer til de fleste scripts, async til uafhængige scripts som analytics.
Hvad er critical CSS og hvornår er det relevant?
Critical CSS er den CSS der er nødvendig for at rendere above-the-fold-indholdet på siden. Ved at inline dette CSS direkte i <head> som en <style>-blok undgår browseren at vente på at et eksternt stylesheet downloades, inden first render kan ske. Det forbedrer FCP og LCP markant på sider med store CSS-filer. Resten af CSS loades asynkront. Kritisk CSS er særligt relevant for sider med mange besøgende på langsomme forbindelser, og kan automatiseres med tools som critical-css eller critters.
Hvordan bruger jeg preload til at forbedre den kritiske renderingsti?
Preload-hints fortæller browseren at fetche en ressource med høj prioritet tidligt i request-sekvensen. Placer <link rel=preload as=font> til webfonts, <link rel=preload as=image fetchpriority=high> til LCP-billedet og <link rel=preload as=style> til kritisk CSS direkte i <head>. Browseren begynder at fetche disse ressourcer parallelt med HTML-parsing, frem for at vente til de opdages i DOM. Forkert brug af preload (for mange preloads, eller preload af ikke-kritiske ressourcer) kan forsinke andre ressourcer.
Hvad er Time to First Byte (TTFB) og påvirker det den kritiske renderingsti?
TTFB er tiden fra browseren sender en request til den modtager den første byte af svaret fra serveren. Det er starten af hele render-processen og lægges til alle efterfølgende trin. En høj TTFB (over 800ms) forlænger den kritiske renderingsti systematisk uanset øvrig optimering. TTFB forbedres med hurtigere server-responstid, CDN-caching, HTTP/2 og reduceret server-processeringstid. Google anbefaler TTFB under 800ms som mål for god LCP.

Placering i ordbogen

Kode — Webkode og teknisk SEO
Web Performance — Core Web Vitals og teknisk hastighed
Kritisk renderingsti — Hvad browseren gør før du ser noget