Du kan bruge timer på at jagte “score”, og stadig stå tilbage med samme problem: LCP er langsom fordi elementet ikke bliver tegnet, ikke fordi netværket er langsomt.
Det er dér render delay lever.
Kort version: Hvis du i PageSpeed Insights/Lighthouse ser at Element render delay fylder, så skal du stoppe med at tænke “download” og begynde at tænke rendering: CSS, layout, paint, main thread og prioritering.
Render delay: hvad du faktisk prøver at finde
LCP er en kæde. Render delay er den del, hvor:
- HTML’en er allerede modtaget
- ressourcen kan endda være hentet
- men browseren når først at male pixels senere
Hvis du vil have en definition og de typiske årsager i kompakt form, så start her: Render delay.
I dette indlæg handler det om metoden: hvordan du finder hvilken type render delay du har – og hvad du gør ved den.
Den hurtige diagnose: 4 spørgsmål der sparer dig for 80% spildtid
1) Hvad er LCP-elementet – og giver det mening?
Først: Find LCP-elementet. Det er ofte enten:
- et hero-billede
- en stor H1
- eller (klassisk) en stor tekstblok længere nede
Hvis LCP-elementet er en tilfældig paragraf, er første opgave ofte at gøre hero-området til den reelle LCP-kandidat. Det er ikke “snyd” – det er at få målingen til at afspejle det brugeren ser som hovedindhold.
Se guiden i dag: Gør hero til LCP.
2) Starter de kritiske requests tidligt?
Åbn waterfall’en (Network).
Spørg:
- Starter CSS tidligt, eller opdages den sent?
- Starter LCP-billedet tidligt, eller bliver det først opdaget efter scripts?
Hvis opdagelsen er sen, kan du bruge værktøjer som Preload og fetchpriority – men kun hvis du kan forklare hvorfor.
3) Er main thread optaget før første paint?
I Performance trace: kig efter lange blokke i starten:
- JS parsing/evaluering
- store “Scripting” blocks
- tredjepart
Hvis det er der tiden går, er din render delay i praksis et “main thread”-problem. Start med:
- Long Task
- Event loop
- og især: Third-party scripts
4) Er det CSS/paint, ikke JS?
Hvis Scripting ikke dominerer, men du ser store “Rendering”/“Painting” blokke, så er det ofte:
- dyre gradients
- blur/backdrop-filter
- store fixed overlays
- mask-image
- store shadows
Det er “pænt CSS” der bliver dyrt i kritisk viewport – især på mobil.
Den praktiske metode: sådan gør du i DevTools (trin for trin)
Det her er den rutine jeg bruger, når nogen siger “TTFB er lav, men LCP er stadig dårlig”.
Trin 1: Kør én test med realistiske forudsætninger
Hvis du ikke tester under nogenlunde realistiske forhold, kan du få et falsk billede.
Du behøver ikke perfektion, men du skal undgå åbenlyst støj. Se evt. Chrome DevTools Performance for værktøjsdelen.
Trin 2: Identificér LCP-element og tidspunkt
I trace:
- Find LCP event
- Notér tidspunktet
- Notér elementtype (billede vs tekst)
Trin 3: Gå baglæns: hvad skete lige før LCP?
Det er her du finder årsagen.
Spørg:
- Var browseren i gang med layout?
- Var den i gang med paint?
- Var den i gang med en script-blok?
Hvis du kan pege på en konkret blok “det her tog 600ms”, kan du begynde at fixe rationelt.
Trin 4: Vælg fix-type efter årsag (ikke efter “best practice”)
Der er tre typiske “familier” af fixes:
- Opdagelse/prioritet: LCP-billede opdages sent → preload/fetchpriority/HTML discovery.
- Render-blocking: CSS/JS blokerer første paint → Critical CSS, defer/async, reducer bundler.
- Paint/layout cost: dyr rendering → simplificér hero, reducer effekter, isolér layout (fx med
contain).
Det værste du kan gøre er at vælge et fix som hører til en anden familie. Det føles som arbejde – men flytter ikke.
Hvorfor “score” snyder dig her
En score er én komprimeret indikator. Render delay er ofte et samspil af mange små ting:
- lidt for meget CSS
- et par scripts for tidligt
- et hero der er flot, men dyrt at male
- en LCP-kandidat der ikke er hero, men en stor tekstblok
Når du skærer 10% på hver af de rigtige ting, falder render delay ofte markant – uden at du “optimerer” til score.
Opsamling: den korte tjekliste
- Find LCP-elementet: giver det mening?
- Tjek opdagelse/prioritet i waterfall
- Tjek main thread i Performance
- Tjek paint/layout cost (CSS-effekter)
- Vælg fix-type efter årsag
Videre på sitet
- Render delay – definition og typiske årsager
- Fjern render blocking CSS og JavaScript – når CSS/JS blokerer
- Sådan fejlsøger du LCP fra start til slut – fuld LCP-kæde
- Gør hero til LCP – hvis LCP peger på “forkert” element
Relaterede blogindlæg
Fetchpriority, preload og preconnect: hvornår de hjælper og hvornår de gør skade
2026-03-23Lær hvornår fetchpriority, preload og preconnect faktisk forbedrer load, og hvornår de bare skaber mere støj og dårlig prioritering i browseren.
5 grunde til at din hjemmeside er langsom og hvad du gør ved det
2025-11-14Se de mest almindelige årsager til en langsom hjemmeside, hvordan du spotter dem, og hvilke ændringer der typisk giver mest effekt først.
Range request i praksis: når 206 Partial Content ikke sker (og hvad det koster)
2026-04-02En feltguide til at spotte når browseren forsøger at bruge Range request, men ender med at få hele filer retur (200 i stedet for 206). Lær at se det i DevTools og ret fejl i proxy/CDN/origin.
Reverse proxy og TTFB: sådan finder du cache-, TLS- og routing-fejl i praksis
2026-03-30Reverse 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.
Vary-header og caching: undgå forkert indhold og lav cache-hit-rate
2026-03-30Vary bestemmer hvornår caches skal gemme flere varianter af samme URL (fx gzip vs brotli eller dansk vs engelsk). Lær de typiske fejl, og hvordan du tester med headers og curl.
Sådan prioriterer du hastighedsoptimering uden at spilde tid
2026-03-27Lær hvordan du prioriterer hastighedsoptimering rigtigt, så du starter med de ændringer der giver mest effekt på LCP, INP, CLS og TTFB.
Eksterne kilder
Kilder til LCP og rendering-trinnene; resten er metode og praksis.
Næste skridt i samme emne
Fortsæt fra forklaring til handling med guides, emner og ordbog.
