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.

Sidst opdateret:

LCP (Largest Contentful Paint) måler hvornår sidens største synlige indholdselement er indlæst og er en af de tre Core Web Vitals Google bruger som rankingfaktor. Grænsen for “godt” er under 2,5 sekunder — alt over 4 sekunder er “dårligt”. LCP-optimering handler ikke om generel performance, men om at identificere præcis hvilket element der er LCP på den konkrete side og fjerne flaskehalsen specifikt for det element. De hyppigste syndere er TTFB fra en langsom server, et hero-billede der opdages for sent i parsing-processen, og render-blocking ressourcer der forsinker hele rendering-kæden.

Identificer LCP-elementet først

Før du optimerer, skal du vide hvad LCP-elementet faktisk er. Brug PageSpeed Insights eller Lighthouse i Chrome DevTools — begge viser det specifikke element der er LCP med en markering i skærmbilledet.

LCP-elementet er typisk:

  • Et hero-billede øverst på siden
  • Et stort baggrundsbillede via CSS
  • Den primære H1-overskrift (hvis ingen billeder)
  • Et embedded video-thumbnail

Hvert af disse har sin egen optimeringsvej.

Årsag 1 — Billedoptimering

Billeder er den hyppigste årsag til dårlig LCP. Angrebspunkterne i prioriteret rækkefølge:

For det første, konverter til WebP eller AVIF. Disse formater er 30-50% mindre end JPEG ved sammenlignelig kvalitet.

For det andet, sæt korrekte dimensioner. Browseren skal vide billedets størrelse inden download for at kunne planlægge layout. Mangler width og height, venter browseren.

For det tredje, brug fetchpriority="high" på LCP-billedet. Det signalerer til browseren at dette billede har højeste downloadprioritet.

<img
  src="hero.webp"
  alt="Hero beskrivelse"
  width="1200"
  height="600"
  fetchpriority="high"
>

Til sidst, overvej <link rel="preload"> i <head> for LCP-billeder der ikke opdages tidligt i HTML:

<link rel="preload" as="image" href="hero.webp" fetchpriority="high">

Årsag 2 — Render-blocking ressourcer

CSS- og JavaScript-filer i <head> blokerer rendering. Browseren kan ikke male siden — og dermed heller ikke LCP-elementet — mens disse filer downloades og processeres.

Critical CSS inline er den mest effektive løsning: ekstraher den CSS der er nødvendig for above-the-fold visning og indsæt den direkte i <style>-tag i <head>. Resten af CSS indlæses asynkront efterfølgende.

JavaScript der ikke er nødvendigt for LCP-elementet markeres med defer eller flyttes til bunden af <body>.

Årsag 3 — Langsom server (TTFB)

Selv et perfekt optimeret billede indlæses langsomt hvis serveren er langsom til at svare. Time to First Byte (TTFB) er en direkte komponent i LCP — en høj TTFB forsinker hele sideindlæsningen.

Se artiklen om TTFB og hosting for konkrete handlinger.

Årsag 4 — Baggrundsbilleder via CSS

LCP-elementer der defineres som CSS background-image opdages sent — browseren skal parse CSS’en inden den ved at billedet skal downloades. For LCP-baggrundsbilleder hjælper <link rel="preload"> i <head>.

Måling mod field data

PageSpeed Insights viser to datasæt: lab data (Lighthouse) og field data (CrUX). Google bruger field data som rankingfaktor. Et godt Lighthouse-score er ikke tilstrækkeligt — optimer mod den CrUX-baserede LCP for rigtige brugere.

Sidst opdateret: marts 2026. Denne artikel er en del af Stegger.dk’s SEO-ordbog. → 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 Core Web Vitals — LCP, INP og CLS forklaret Core Web Vitals er Googles tre performance-signaler: LCP (hastighed), INP (interaktivitet) og CLS (layout-stabilitet) — alle er rankingfaktorer. Artikel TTFB og hosting — Server response time og SEO TTFB er den tid serveren bruger på at svare — og en direkte komponent i LCP. Hosting, caching og CDN er de tre primære håndtag. Artikel Lazy loading — Udskyd indlæsning af billeder og ressourcer Lazy loading udskyder indlæsning af off-screen billeder — loading=lazy er en browser-native attribut der forbedrer LCP og pageload-tid. Artikel Responsivt design — Mobile-first og SEO Responsivt design sikrer at siden fungerer på alle skærmstørrelser — Googles mobile-first index gør mobilversionen til den primære SEO-version. Emne JavaScript og rendering — Scripts, DOM og CSR vs SSR JavaScript er SEOs største rendering-udfordring — forstå CSR vs SSR, DOM, lazy loading og hvad Googlebot faktisk ser. Emne Server og HTTP-responser — Statuskoder, redirects og caching HTTP-statuskoder, redirects og caching er serverresponser der direkte påvirker Googlebots crawling og brugernes oplevelse.

Ofte stillede spørgsmål

Hvad er det første skridt til at forbedre LCP?
Identificer LCP-elementet. Brug PageSpeed Insights eller Lighthouse til at se præcis hvilket element der er LCP på din side — typisk et hero-billede, et baggrundsbillede eller en stor H1. Når du ved hvad elementet er, kan du målrette optimeringen mod det specifikke element frem for at gætte.
Hjælper lazy loading på LCP-elementet?
Nej — lazy loading på LCP-elementet forværrer LCP. Lazy loading udsætter download til elementet er ved at blive synligt, men LCP-elementet er per definition allerede synligt. Brug loading='eager' (default) og fetchpriority='high' på LCP-billeder. Brug lazy loading kun på billeder under fold.
Hvad er fetchpriority og hvornår skal jeg bruge det?
fetchpriority='high' er en HTML-attribut der signalerer til browseren at en ressource skal prioriteres over andre downloads. Sæt den på dit LCP-billede — særligt vigtigt på sider hvor browseren ellers ikke opdager billedet tidligt nok i parsing-processen. Det er en af de mest effektive enkeltindsatser for LCP.
Hvad er LCP-subparts og hvilken subpart er hyppigst årsag til dårlig LCP?
LCP kan opdeles i fire subparts: Time to First Byte (TTFB), resource load delay (tid fra TTFB til ressource begynder at loade), resource load duration (tid til ressourcen er downloadet) og element render delay (tid til LCP-elementet er renderet). Den hyppigste årsag til dårlig LCP er TTFB — en langsom server forsinker hele kæden. Den næsthyppigste er resource load delay — browseren opdager ikke LCP-billedet tidligt nok og begynder download sent. Preload og fetchpriority adresserer resource load delay direkte.
Er LCP det samme i Lighthouse-lab og i CrUX field data, og hvilken skal jeg optimere til?
Nej, de måler ikke det samme. Lighthouse-LCP er et lab-metric målt på en simuleret forbindelse med en fast profil — nyttigt til debugging og sammenligning over tid. CrUX LCP er field data fra rigtige Chrome-brugere på rigtige enheder og forbindelser — det er den LCP Google bruger til Core Web Vitals-vurderingen. Mange sider har grønt Lighthouse-LCP men rød CrUX-LCP fordi rigtige mobilbrugere på langsomme forbindelser oplever anderledes performance end lab-simuleringen. Prioriter altid CrUX field data som det primære mål.

Placering i ordbogen

Kode — Webkode og teknisk SEO
Web Performance — Core Web Vitals og teknisk hastighed
LCP-optimering — Sådan forbedrer du Largest Contentful Paint