Kort fortalt: En critical request chain er den afhængighedskæde af HTTP-kald, hvor ét skridt blokerer eller forudsiger det næste, indtil det vigtigste indhold kan vises. Klassisk eksempel: HTML skal hentes og parses, før browseren opdager et stylesheet; stylesheetet skal hentes, før fonten i CSS kan hentes; først derefter kan teksten tegnes som forventet. Jo længere seriel kæde og jo tungere led, jo senere bliver LCP - ofte uanset at du har “hurtig server” på papiret.
Hvorfor kæden betyder mere end enkelttider
Mange fokuserer på “hvor stor er filen?” men overser rækkefølgen. To filer på 100 KB kan være billige hvis de hentes parallelt og tidligt. Én fil på 50 KB kan være dyr hvis den først må starte efter tre andre serielle trin. TTFB på HTML er ofte første led: hvis dokumentet kommer sent, starter hele opdagelsen af resten sent.
Sådan læser du kæden i værktøjer
- Lighthouse (Chrome): Under performance findes ofte en sektion om kritiske kæder; den binder requests sammen som “A kræver B kræver C”.
- WebPageTest: Waterfall + “connection view” viser om du åbner for mange nye forbindelser serielt (HTTP/2 og HTTP/3 kan multiplexe, men logiske afhængigheder består).
- DevTools Network: Sortér efter “Waterfall”, zoom ind på de første 2–3 sekunder. Spørg: hvad venter på hvad?
Typiske mønstre der forlænger kæden
- Sent opdaget LCP-billede - billedet ligger ikke i første HTML, men injiceres via JavaScript eller ligger dybt i DOM. Så starter download først når JS er kørt eller DOM er bygget.
- Render-blocking CSS - store stylesheets i
<head>uden strategi for kritisk vs. ikke-kritisk. Se render-blocking og critical CSS. - Font-kæde - CSS refererer til webfont; browseren må hente CSS, derefter font-filer; hvis tekst skal vises med webfont, påvirker det layout og tid til “færdigt” udtryk (også relevant for CLS og FOIT/FOUT).
- Tredjepart tidligt - scripts der blokerer eller bruger båndbredde før dit LCP-element. Se third-party scripts.
Hvad du typisk gør ved en lang kæde
- Forkort HTML-tid - caching, edge, mindre dynamisk arbejde pr. request (TTFB, CDN).
- Gør LCP-ressourcen tidligt synlig - billedet i HTML, korrekt
srcset/sizes(srcset og sizes), undgå at skjule det bag unødvendig JS. - Brug hints med måde - preload eller fetchpriority når du har målt, at discovery er problemet - ikke som blind standard.
- Reducer serielle afhængigheder - færre kritiske trin før “første meningsfulde pixel”.
Relaterede begreber
- Resource hints, Early Hints
- LCP, Speed Index (forskellige mål, fælles afhængighed af kæden)
- preload, prefetch - forskellige formål; forkert brug forlænger andre kæder
Typisk misforståelse
“Vi har HTTP/2, så kæden er ikke et problem.” Multiplexing hjælper på parallelisering inden for samme forbindelse, men du kan stadig have logisk serielle trin (parse HTML → find CSS → hent CSS → find font). Protokollen magiker ikke afhængighederne væk.
FAQ
Er den kritiske kæde det samme som LCP-elementet?
Nej, men de er tæt forbundet. LCP-elementet er det visuelle element der definerer målingen; den kritiske kæde forklarer *hvilke netværks- og parse-afhængigheder* der forsinker, at det element bliver vist.
Hvor ser jeg kæden i praksis?
Lighthouse viser 'critical request chains'. WebPageTest og Chrome DevTools Network giver waterfall, hvor du kan se serielle vs. parallelle requests og længden af 'waiting' på dokumentet.
Næste skridt fra begreb til handling
Guides og blogindlæg der matcher begrebets emne - ud fra fælles tags og sidens fokus.
Brug Transfer-Encoding (chunked) til progressiv rendering: hurtigere første visning
Lær at finde ud af om din server eller reverse proxy buffer HTML-svar, og få streaming (chunked) til at flytte første visning og LCP i den rigtige retning.
Gør hero til LCP: sådan ændrer du struktur, CSS og prioritering
Hvis LCP bliver en tilfældig paragraf i stedet for hero, får du både dårligere tal og en måling der ikke matcher brugerens første indtryk. Her er en konkret metode til at få hero (H1/billede) til at blive LCP – uden at snyde.
Få edge cache-hit på HTML: undgå cookies, forkert Vary og dårlige cache keys
Mange sites har CDN, men får stadig høj TTFB fordi HTML ikke caches. Lær et praktisk workflow til at få cache-hit på offentlige sider uden at servere forkert indhold.
5 grunde til at din hjemmeside er langsom og hvad du gør ved det
Se de mest almindelige årsager til en langsom hjemmeside, hvordan du spotter dem, og hvilke ændringer der typisk giver mest effekt først.
Hvordan du spotter render delay (uden at stirre på score)
Render delay er ofte grunden til at LCP bliver 1–2 sekunder for sent, selv når TTFB ser fin ud. Her er metoden til at finde årsagen hurtigt – og vælge den rigtige type fix.
Reverse proxy og TTFB: sådan finder du cache-, TLS- og routing-fejl i praksis
Reverse proxy-laget kan være årsagen til høj TTFB, mystiske cache misses og 502/504-fejl. Lær hvad du skal kigge efter i headers og waterfall, og få et praktisk debug-flow.
