Forbedr LCP med billeder

På mange sites er LCP-elementet et stort billede i toppen af siden. Det kan være et hero-billede, et cover-billede til en artikel, eller et stort produktbillede. Når det billede kommer sent frem, føles siden langsom – også selvom alt andet loader “okay”.

I denne guide går vi systematisk igennem, hvordan du forbedrer LCP ved at optimere billeder uden at skabe nye problemer (fx CLS, dårlig kvalitet eller overaggressiv preload).

Guiden er relevant for marketing sites, webshops og content-sider hvor et foto eller banner i toppen dominerer første skærm. Den forudsætter at du kan ændre billedfiler, CDN-indstillinger eller markup (<img>, picture, srcset). Hvis dit LCP-element ikke er et billede, skal du i stedet kigge på render-blocking eller TTFB.

Målet

• At LCP-billedet starter download tidligt og er let nok til at blive vist hurtigt.
• At layoutet er stabilt (ingen hop/CLS), mens billedet loader.
• At billedet ser godt ud på både mobil og desktop.

Før du går i gang

• Tag backup eller deploy til staging - især hvis du ændrer globale billed-templates.
• Saml før-målinger (PSI/Lighthouse + helst én waterfall) så du kan sammenligne.
• Tjek om jeres CMS auto-tilføjer loading="lazy" på alle billeder; det skal fra for LCP-billedet (lazy-load guiden forklarer hvorfor).

Før du ændrer noget: find LCP-elementet

1. Kør PageSpeed Insights eller Lighthouse på siden.
2. Find hvilket element der er LCP (ofte et billede).
3. Tjek i waterfall hvornår billedet starter download.

Det afgør om du har et discovery-problem (billedet opdages sent) eller et download-problem (billedet er tungt).

De 4 klassiske årsager til dårlig LCP fra billeder

1) Billedet er for stort (filstørrelse)

Hvis billedet er flere MB, hjælper format alene sjældent nok.

2) Billedet har for store dimensioner

Det mest almindelige er at servere en alt for stor fil, som browseren skalerer ned.

3) Billedet opdages for sent

Hvis hero-billedet ligger dybt i DOM, eller kommer via CSS/JS, kan browseren starte download for sent.

4) Billedet er “forkert prioriteret”

Tredjepart, scripts eller andre assets kan stjæle tidlig båndbredde. Her kan fetchpriority="high" på LCP-<img> (hvor understøttet) kombineres med at reducere konkurrerende tunge requests - men mål før du gætter.

5) Dårlig caching eller langsom CDN

Et optimalt komprimeret billede kan stadig give dårlig LCP hvis det hentes langt fra brugeren eller uden effektiv cache. TTFB og edge caching på assets hører med i den samlede diagnose.

Trin-for-trin: sådan forbedrer du LCP med billeder

Trin 1: Brug moderne formater (AVIF/WebP) med fallback

Start med at servere AVIF/WebP, men uden at ødelægge kompatibilitet.

Praktisk:

• AVIF som førstevalg, WebP som fallback, JPEG/PNG som sidste fallback.

Trin 2: Servér responsive størrelser (srcset + sizes)

Dette er ofte den største forbedring:

• lav flere varianter (fx 320/640/960/1280)
• brug sizes der matcher dit layout

Trin 3: Brug korrekte dimensioner og reservér plads (undgå CLS)

• angiv width/height eller brug aspect-ratio
• undgå at billedet først får størrelse efter load

Trin 4: Fjern lazy loading på LCP-billedet

Lazy loading under folden er fint. Men hero/LCP bør normalt ikke lazy-loades.

Trin 5: Overvej preload (målrettet)

Preload kan hjælpe hvis billedet opdages sent. Men preload kun:

• én hero-ressource (ikke 6 billeder)
• og kun hvis du kan se at den starter for sent

Trin 6: Caching og CDN

Hvis billedet er statisk, bør det caches længe. Et CDN kan hjælpe, især hvis mange brugere er langt fra origin. Sørg for fornuftige Cache-Control-headers på billed-URL’er og undgå at buste cache unødigt ved hver pageview.

Når LCP-elementet ikke er et billede

Nogle skabeloner har LCP som stor tekst eller video - så giver billedguiden ikke mening alene. Tjek LCP-elementet i Lighthouse: hvis det ikke er et <img>, er næste skridt typisk fjern render-blocking, font-stabilitet eller TTFB/cache. Mål igen efter hvert spor så du ikke optimerer «hero-billede» der ikke er LCP.

Sådan kontrollerer du resultatet

1. Lab: LCP-tid i Lighthouse (samme enhed og lokation før/efter).
2. Waterfall: Bekræft at LCP-billedets request starter tidligere eller færdiggøres hurtigere - ikke kun at total KB er faldet.
3. Felt: Efter deploy: følg Search Console over de næste uger; feltdata halter bagud.
4. CLS: Tjek at nye dimensioner/preload ikke har introduceret layout-hop (CLS-guide).

Tjekliste (hurtig)

• LCP-element identificeret
• Ingen lazy loading på hero/LCP-billedet
• Moderne format (AVIF/WebP) + fallback
• Responsive størrelser + korrekt sizes
• Plads reserveret (ingen CLS)
• Preload kun hvis discovery er problemet
• Caching/CDN på plads

Relateret

• Ordbog: AVIF, WebP, picture
• Guide: Lazy-load korrekt

Relaterede guides

Sådan fejlsøger du LCP fra start til slut

2026-03-27

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.

Brug fetchpriority og preload rigtigt på de vigtigste ressourcer

2026-03-23

Få en praktisk guide til hvordan du bruger fetchpriority og preload på billeder, fonts og CSS uden at overstyre browseren forkert.

Lazy-load billeder korrekt uden at skade LCP og brugeroplevelse

2026-01-15

Se 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-02

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

2026-04-01

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.

Undgå CLS fra fonts: font-display, preload og stabile fallbacks

2026-03-30

Læ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

Skal hero-billedet altid preloades?

Nej. Preload hjælper primært hvis billedet opdages sent, eller hvis download starter for sent i waterfall. Hvis hero-billedet allerede starter tidligt, kan preload være unødvendigt og i værste fald stjæle båndbredde fra CSS/HTML.

Må jeg lazy-loade hero-billedet?

Som udgangspunkt nej. Hvis hero-billedet er LCP-elementet, kan lazy loading gøre LCP dårligere, fordi browseren venter med at hente billedet. Lazy loading giver typisk bedst mening under folden.

Er format eller dimensioner vigtigst?

Ofte er dimensioner og responsive størrelser vigtigst. Et WebP/AVIF-billede kan stadig være for stort, hvis du sender 2000px til en container på 400–800px. Format hjælper, men størrelser og prioritering flytter ofte mest.

Næste skridt efter guiden

Brug emnesider, ordbog og blog til at validere og uddybe næste ændring.

Se relaterede emnerLæs forklarende blogindlægTjek begreber i ordbogSe hele ordbogen (A–Å)