Trin-for-trin
Vælg en konkret URL og kør PageSpeed eller Lighthouse for at bekræfte LCP-element og groft tidspunkt.
Tjek TTFB og HTML: langsom respons udskyder alt, inklusive discovery af LCP-ressourcen.
Find LCP-elementet (billede, tekst eller andet) og notér om problemet er discovery, størrelse eller blokering.
Gennemgå render-blocking CSS/JS og forkert lazy load der rammer LCP-elementet.
Optimér selve ressourcen (format, dimensioner, caching, CDN) og prioritering (fetchpriority, preload kun hvis begrundet).
Mål igen på samme enhed og sammenlign waterfall før og efter.
Høj LCP er sjældent ét enkelt problem. Det er en kæde: server sender HTML, browser parser og opdager ressourcer, netværk henter filer, og rendering viser indhold. Målet med denne guide er at du finder flaskehalsen i stedet for at optimere tilfældige elementer eller blindt preloader et billede.
Hvad du får: En samlet arbejdsgang du kan følge på en vigtig side, med links til dybere guides undervejs. Du kan bruge den sammen med prioritering af hastighedsoptimering så du ikke spilder tid på små fixes i forkert rækkefølge.
Hvornår denne guide er relevant
Høj LCP i feltdata eller labdata
Når Search Console, CrUX eller PageSpeed viser LCP over mål på skabeloner der betyder noget for jer.
Langsom første visning på vigtige sider
Når brugere eller kolleger oplever at «ingenting sker» i toppen af skærmen, selvom resten af siden føles ok.
Det skal du have klar før du starter
En konkret side eller template
Én URL ad gangen - fx forsiden eller en produktoplysning.
Adgang til værktøjer og målinger
PageSpeed Insights, Lighthouse, DevTools Network og helst waterfall-forståelse.
En plan for før og efter
Notér dato, enhed, netværksprofil og gerne screenshot af waterfall.
Trin 1: Find det reelle LCP-element
Billede
Ofte hero, produkt eller stort banner. Bekræft i Lighthouse/PSI hvilket element der tæller som LCP.
Tekstblok
Store overskrifter kan være LCP hvis billeder ikke dominerer.
Andet indhold
Video-poster, store SVG eller andet - det er elementet der tæller, ikke din antagelse.
Trin 2: Tjek TTFB først
Hvorfor langsom HTML forsinker alt
LCP starter ikke før der er indhold at male. Høj TTFB betyder at hele kæden starter sent.
Hvordan du ser om backend er problemet
Se på første byte i waterfall og sammenlign med en simpel test-side på samme host. Følg TTFB og cache hvis det er her det gør ondt.
Trin 3: Tjek om elementet opdages for sent
HTML-struktur
Ligger LCP-elementet sent i DOM eller indsprøjtes af JS? Så er discovery problemet.
CSS og JavaScript blocking
Render-blocking ressourcer kan udskyde første paint. Se fjern render-blocking.
Lazy loading der rammer forkert
loading="lazy" på LCP-billedet er en klassisk fejl - læs LCP med billeder.
Trin 4: Tjek selve LCP-ressourcen
Filstørrelse og format
Er filen alt for stor til viewport? Er I på WebP/AVIF hvor det giver mening?
Responsive størrelser
srcset og sizes der ikke matcher layout sender ofte for store filer til mobil.
Caching og leveringsvej
CDN, cache-headers og geografisk afstand påvirker stadig, selv med et «optimeret» billede.
Trin 5: Tjek prioritering og netværksrækkefølge
Preload
Kun når en kritisk ressource ellers opdages for sent - se fetchpriority og preload.
Fetchpriority
fetchpriority="high" på LCP-<img> kan hjælpe når andre assets konkurrerer - men mål effekten.
Konkurrence fra andre ressourcer
Tunge scripts eller mange tidlige requests kan stjæle båndbredde fra LCP-ressourcen.
Trin 6: Test igen og dokumentér
Før og efter
Samme URL, samme enhed, samme netværksprofil - ellers sammenligner du æbler og pærer.
Hvad du bør holde øje med
LCP-tid, men også om du har skabt CLS eller gjort INP værre med nye scripts.
Hvornår næste skridt giver mening
Når LCP er under kontrol på den skabelon, gentager du processen på næste vigtige side - eller går til INP hvis det er næste flaskehals.
Typiske fejl
Man antager at billedet er problemet
Uden at tjekke TTFB og discovery kan du bruge timer på forkert sted.
Man preloader uden at have fundet årsagen
Preload er et plaster, ikke en diagnose.
Man glemmer TTFB og HTML
En perfekt komprimeret PNG hjælper ikke, hvis HTML ankommer sent.
Checkliste
- LCP-element identificeret i værktøj
- TTFB vurderet før dyb billedoptimering
- Discovery, blocking og lazy load tjekket
- Ressource og prioritering justeret med måling
- Resultat dokumenteret før næste skridt
Afslutning
Arbejdsgangen er: element - TTFB/HTML - discovery - ressource - prioritering - gentest.
Gå dybere med:
- Forbedr LCP med billeder
- Fjern render-blocking CSS og JavaScript
- Forbedr TTFB og cache
- Sådan prioriterer du hastighedsoptimering når du skal vælge rækkefølge på tværs af metrics.
Relaterede guides
Brug fetchpriority og preload rigtigt på de vigtigste ressourcer
2026-03-23Få en praktisk guide til hvordan du bruger fetchpriority og preload på billeder, fonts og CSS uden at overstyre browseren forkert.
Forbedr LCP med billeder: hero, formater, preload og responsive størrelser
2026-03-18Lær hvordan du forbedrer LCP ved at optimere hero-billedet med rigtige dimensioner, AVIF eller WebP, preload og korrekt responsive opsætning.
Lazy-load billeder korrekt uden at skade LCP og brugeroplevelse
2026-01-15Se hvordan du bruger lazy loading rigtigt, undgår at skade LCP og vælger de billeder der skal prioriteres tidligt i stedet.
Brug Transfer-Encoding (chunked) til progressiv rendering: hurtigere første visning
2026-04-02Læ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
2026-04-01Hvis 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.
Undgå CLS fra fonts: font-display, preload og stabile fallbacks
2026-03-30Lær at undgå layout-hop (CLS) fra webfonts med font-display, fallback-strategi og korrekt preload. Guiden er til dig der vil have pæn typografi uden at ødelægge stabilitet.
FAQ
Er LCP altid et billede?
Nej. Det kan være et tekstafsnit, video-poster eller andet stort element i viewport. Lighthouse viser typisk hvilket element der er LCP - start med den kendsgerning, ikke med antagelser.
Hjælper preload altid?
Nej. Preload er relevant når en kritisk ressource opdages for sent. Hvis HTML eller TTFB er problemet, skal du rette dér først. Forkert preload kan stjæle båndbredde fra vigtigere ting.
Skal jeg starte med TTFB eller billedet?
Hvis TTFB er høj, starter alt sent - så ja, ofte TTFB først. Hvis TTFB er ok men LCP-billedet er tungt eller sent i waterfall, går du direkte til billedet og prioritering.
Næste skridt efter guiden
Brug emnesider, ordbog og blog til at validere og uddybe næste ændring.
