LCP er en måling for oplevet indlæsningshastighed: hvor hurtigt det vigtigste indhold kommer frem.
Hvad er LCP (Largest Contentful Paint)?
LCP står for Largest Contentful Paint og beskriver tidspunktet hvor browseren har renderet det største “meningsfulde” indhold i viewporten. I praksis er det ofte:
- et hero-billede
- en stor overskrift
- en stor blok tekst
Målet er ikke bare at få “noget” på skærmen, men at få det vigtigste på skærmen hurtigt.
Hvilken indflydelse har LCP?
Når LCP er høj, føles siden langsom, selv hvis resten af ressourcerne hentes hurtigt bagefter. Det giver typisk:
- lavere tilfredshed (brugere får en “tom” sideoplevelse)
- højere bounce på langsomme landingssider
- dårligere oplevet kvalitet, især på mobil
LCP hænger ofte også sammen med andre problemer (fx høj TTFB og render-blocking).
Hvornår blev LCP indført?
LCP blev introduceret som en moderne erstatning for ældre, mere upræcise “load”-målinger, fordi den fokuserer på oplevet indlæsning. Senere blev LCP en del af Core Web Vitals, hvor den i praksis blev en af de mest synlige performance-målinger i SEO-verdenen.
Hvad er “god” LCP?
Tommelregler:
- God: under ca. 2,5 sek.
- Skal forbedres: 2,5–4 sek.
- Dårlig: over 4 sek.
Det vigtigste er at måle på rigtige brugere (feltdata) og på dine vigtigste landingssider.
Hvordan måler man LCP?
Du kan måle LCP på flere måder:
- Search Console / CrUX: feltdata over tid (rigtige brugere)
- PageSpeed Insights: lab + felt (hvis tilgængeligt)
- Lighthouse: lab (god til debugging)
- WebPageTest: lab med waterfall, som er stærk til at finde årsagen
- Chrome DevTools Performance: find LCP-element og hvad der blokerer
Når du debugger, er det værdifuldt at finde:
- hvilket element der er LCP
- hvornår det startede download/rendering
- om TTFB eller render-blocking blokerer før det
Typiske årsager til høj LCP
- Lang TTFB (server/langsom backend)
- Store billeder eller font-filer
- Render-blocking CSS/JS
Hvad kan man gøre for at optimere LCP?
Tænk LCP som en kæde. Det er sjældent én ting – det er summen af serverrespons, prioritering og rendering.
1) Reducér TTFB (serveren skal svare hurtigt)
Typiske tiltag:
- aktiver page cache (server/LiteSpeed/omvendt proxy)
- edge caching via CDN hvis du har mange besøgende geografisk spredt
- optimer backend og databasen, hvis dynamic rendering er tung
2) Prioritér LCP-ressourcen (ofte hero-billedet)
Hvis dit LCP-element er et billede:
- servér AVIF/WebP og brug responsive størrelser
- sørg for korrekte dimensioner (undgå at sende 2000px hvis du viser 800px)
- undgå at lazy-loade hero-billedet
- overvej
preloadaf hero-billedet (men preload ikke for meget)
Hvis LCP-elementet er tekst:
- sørg for at fonts ikke blokerer rendering unødigt
- begræns font-weights og varianter
- brug
font-display: swapog fornuftige fallbacks
3) Fjern render-blocking
Typiske tiltag:
- critical CSS (inline det der er nødvendigt for første viewport)
- udskyd ikke-kritisk JavaScript (
defer) og fjern unødvendige scripts - reducer unused CSS og store frameworks der skaber CPU-arbejde før første paint
4) Reducér CPU-arbejde før første render
Hvis browseren er travl med at parse/execute JS, kan LCP blive dårligere selv hvis netværket er fint.
Typiske tiltag:
- code splitting
- fjern tredjeparts scripts fra critical path
- minimer hydration på mobil
Praktisk tjekliste (hurtig)
- Find LCP-elementet (PSI/Lighthouse)
- Er TTFB høj? (så: caching/edge)
- Er hero-billedet for stort? (så: responsive + moderne format)
- Er hero-billedet lazy-loadet? (så: fjern lazy)
- Er der render-blocking CSS/JS? (så: critical CSS + defer)
- Er der meget JS tidligt? (så: reducer/split/udskyd tredjepart)
FAQ
Skal man altid preload’e LCP-billedet?
Nej. Preload er et værktøj til et bestemt problem: når browseren opdager LCP-ressourcen for sent (discovery-problem).
Hvis dit LCP-billede allerede starter tidligt, kan preload være spild – og i værste fald stjæle båndbredde fra CSS/HTML.
Start med at se i waterfall hvornår billedet starter. Hvis det starter sent, så overvej preload *af præcis den ressource* (og vær ekstra opmærksom ved `srcset`/`sizes`).
Kan et CDN alene fixe LCP?
CDN kan hjælpe via lavere TTFB og hurtigere asset-levering, men det løser ikke alt.
Hvis problemet er render-blocking CSS/JS, tungt main-thread arbejde, eller at LCP-elementet opdages sent i DOM, skal du stadig optimere template, CSS/JS og prioritering.
Hvorfor flytter LCP sig ikke selvom jeg komprimerer billedet?
Fordi LCP ofte er en kæde – og billedets filstørrelse er kun ét led.
Typiske årsager til at komprimering “ikke slår igennem”: - billedet opdages sent (starter download sent) - TTFB er høj (alt starter sent) - render-blocking gør at browseren ikke kan male, selvom billedet er hentet - billedet har stadig for store dimensioner til layoutet (mobil downloader desktop-størrelse)
Eksterne kilder
Officielle kilder til definition, måling og optimering af LCP - ikke en generisk liste til alle ordbogssider.
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.
Sådan fejlsøger du LCP fra start til slut
Følg en praktisk arbejdsgang til at finde årsagen til høj LCP, fra serverrespons og render blocking til billeder, prioritering og netværksrækkefølge.
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.
Fetchpriority, preload og preconnect: hvornår de hjælper og hvornår de gør skade
Læ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
Se de mest almindelige årsager til en langsom hjemmeside, hvordan du spotter dem, og hvilke ændringer der typisk giver mest effekt først.
