Sådan forbedrer I LCP: det største element skal være klar hurtigere

LCP, Largest Contentful Paint, er tiden, fra siden begynder at loade, til det største synlige element er tegnet færdigt. På de fleste sider er det hero-billedet eller overskriften øverst. Google regner et LCP på højst 2,5 sekunder for godt. Over 4 sekunder er dårligt.

Det er det af de tre Core Web Vitals, flest sider fejler på. I HTTP Archives Web Almanac 2025 havde 62 % af websites et godt LCP på mobil, mod 77 % for INP og 81 % for CLS. Samtidig er det det mål, der oftest kan rettes uden at bygge siden om. Her er, hvordan I finder jeres tal, hvad der typisk trækker det op på en WordPress-side, og hvad I gør ved det.

Hvad LCP dækker, og hvad det ikke dækker

Browseren holder øje med de største elementer, der bliver synlige i det første skærmbillede, mens siden loader. Når den er færdig, er det største af dem LCP-elementet, og tidspunktet, hvor det stod færdigt, er jeres LCP. Det kan være et billede, en video med et plakatbillede, en blok med et baggrundsbillede eller en tekstblok som overskriften. Et billede, der fylder hele skærmen, eller et næsten tomt billede uden detaljer, tæller ikke med. Browseren holder op med at lede efter nye kandidater, så snart den besøgende trykker, scroller eller taster.

Tallet, Google bruger, kommer fra rigtige besøg. Det er den 75. percentil over 28 dage, opgjort for mobil og desktop hver for sig. Tre ud af fire besøgende skal altså have et LCP under 2,5 sekunder, før siden består. Én hurtig test på jeres eget kontor-wifi siger derfor ikke meget. Grænserne står hos web.dev.

LCP siger ikke, hvornår hele siden er loadet, og ikke, hvornår man kan klikke på noget. Det første er sjældent vigtigt for den besøgende. Det andet er INP.

Find jeres tal

Start i Search Console under Core Web Vitals. Rapporten samler jeres sider i grupper med samme skabelon og viser, hvilke grupper der fejler på mobil og desktop. Det er feltdata, så den viser det, besøgende faktisk oplever. Har siden for få besøg, er der ingen data, og det er ikke det samme som et dårligt tal.

Åbn derefter én side fra en gruppe, der fejler, i PageSpeed Insights. I kan gøre det gennem vores hastighedstest. Øverst står feltdata for siden, hvis der er nok. Under laboratorietesten finder I indsigten “LCP breakdown”. Den peger på det konkrete element, siden venter på, og deler ventetiden op. Indsigten “LCP request discovery” viser, om billedet bliver fundet sent eller er lazy-loadet. De to afløste de gamle diagnoser, da Lighthouse 13 kom i oktober 2025. Det er det element, resten af arbejdet handler om. Ret ikke noget, før I ved, hvilket element det er.

Test mobil først. Det er næsten altid dér, tallet er dårligst, og det er dér, de fleste besøg kommer fra.

De fire dele af ventetiden

Et LCP på 4 sekunder er ikke ét problem. Det er summen af fire ventetider, og web.dev anbefaler at se på dem hver for sig, før I retter noget:

1. Serverens svartid (TTFB): tiden, til den første bid HTML kommer. Den bør være under 800 millisekunder.
2. Forsinkelse, før hentningen starter: tiden, fra HTML’en er der, til browseren begynder at hente billedet. Den bør være tæt på nul.
3. Selve hentningen: tiden, det tager at hente billedfilen. Den afhænger af filens størrelse og af forbindelsen.
4. Forsinkelse, før det tegnes: tiden, fra billedet er hentet, til det står på skærmen. Også den bør være tæt på nul.

Som pejlemærke angiver web.dev, at del 1 og 3 hver kan fylde omkring 40 % af tiden, mens del 2 og 4 hver bør være under 10 %. Er det omvendt, venter browseren på noget, den ikke behøvede vente på. Det er ofte det nemmeste at rette.

Det, der typisk er galt på en WordPress-side

Billedet er for stort

Det mest almindelige. Et hero-billede på 3.000 pixel og 1,5 MB bliver vist i 400 pixel på en telefon. Browseren henter hele filen alligevel. Lav billedet i den størrelse, det vises i, og lad WordPress generere de mindre udgaver, så srcset kan vælge den rigtige. Gem det som WebP eller AVIF. Et hero-billede bør sjældent fylde over 150–200 KB. Format, filnavn og alt-tekst står i image SEO.

Billedet er lazy-loadet

Lazy loading er godt til billeder under folden og skidt til det billede, der er LCP. Med loading="lazy" venter browseren med at hente det, og det er præcis det, I ikke vil. WordPress undlader selv lazy loading på de første billeder, den regner med er synlige, men mange temaer, page builders og slider-plugins sætter det på alligevel. Kontrollér hero-billedets HTML. Det skal hverken have loading="lazy" eller være skjult, til et script viser det. Fejlen er udbredt: Ifølge Web Almanac 2025 lazy-loader cirka 17 % af mobilsiderne deres LCP-billede.

Browseren opdager billedet for sent

Ligger billedet som CSS-baggrund, eller indsættes det af JavaScript, står det ikke i HTML’en, og browseren finder det først, når CSS’en eller scriptet er hentet og kørt. Det er den anden ventetid fra listen. Brug et almindeligt <img>, hvor det kan lade sig gøre. Kan det ikke, så fortæl browseren om billedet på forhånd med <link rel="preload" as="image"> i <head>.

Giv samtidig billedet fetchpriority="high". Det siger til browseren, at netop dette billede er vigtigere end de andre ressourcer, den er i gang med. Siden version 6.3 sætter WordPress det selv på det billede, den gætter er LCP. Gættet gælder kun billeder, WordPress selv skriver ud, og rammer ikke altid, især ikke når hero-billedet kommer fra en page builder. Giv kun et eller to billeder høj prioritet. Får alle det, hjælper det ikke.

Serveren er langsom

Er TTFB over 800 millisekunder, kan billedet være nok så lille. En WordPress-side bygges forfra ved hvert besøg, medmindre der er sidecache. Det er det første at slå til. Derefter: et hostingprodukt med nok kræfter, PHP i en nyere version, og en CDN, hvis I har mange besøgende langt fra serveren. Et plugin, der kører tunge databaseforespørgsler på hver side, kan alene koste et sekund. web.dev om TTFB kalder 0,8 sekunder en grov rettesnor og gennemgår, hvordan tiden kan bringes ned.

CSS og scripts står i vejen

Browseren tegner ikke noget, før den har hentet den CSS, siden linker til i <head>. Et tema og en håndfuld plugins kan nemt lægge 20 stylesheets og lige så mange scripts dér. Fjern de plugins, siden ikke bruger. Lad scripts, der ikke er nødvendige for det første skærmbillede, vente med defer. Et caching-plugin kan ofte samle og udskyde filerne, men test resultatet. Det er den fjerde ventetid, I rammer her.

Skriften er LCP

Er det største element en overskrift, er det ofte webfonten, der venter. Browseren kan skjule teksten, til fonten er hentet. Brug font-display: swap, så teksten vises med en systemfont, til jeres egen er klar, host fonten selv, og preload den fil, overskriften bruger. Fonten skifter så én gang. Det er bedre end en tom plads, og det er samme princip som ved CLS: reservér pladsen, og lad ikke noget vente, der ikke behøver det.

Hvad I kan forvente

De fleste WordPress-sider, vi ser med et LCP på 4–6 sekunder på mobil, kan komme under 2,5 med de rettelser, der står her, uden nyt design og uden at skifte tema. Det store billede og sidecachen giver typisk det meste af gevinsten. Resten er mindre skridt, der hver koster lidt.

Feltdata ændrer sig ikke dagen efter. Perioden er rullende over 28 dage, så Search Console viser først hele effekten efter cirka en måned. Brug laboratorietesten til at se, om rettelsen virker med det samme, og feltdata til at bekræfte, at den virker for de besøgende.

Tjekliste

1. Find de sidegrupper, der fejler på LCP, i Search Console. Tag mobil først.
2. Kør én side fra hver gruppe gennem PageSpeed Insights, og notér, hvilket element der er LCP.
3. Se, hvor ventetiden ligger: server, forsinket start, hentning eller tegning.
4. Skær billedet til den størrelse, det vises i, og gem det som WebP eller AVIF.
5. Fjern lazy loading fra LCP-billedet, og giv det fetchpriority="high".
6. Slå sidecache til, og test TTFB igen.
7. Fjern plugins og scripts, det første skærmbillede ikke bruger, og udskyd resten.
8. Test igen i laboratoriet, og følg feltdata i Search Console den næste måned.

LCP er ét af tre mål, og et godt LCP flytter ikke en side, der er det forkerte svar på søgningen. Men det er den del af hastigheden, besøgende mærker først, og den, der oftest kan rettes på en eftermiddag. Hvor det hører til i den samlede gennemgang, står under teknisk SEO. Vil I vide, hvor jeres sider står, så start med hastighedstesten. Vil I have det gjort for jer, er det præcis det, vi laver under hastighedsoptimering.

Kilder

• web.dev, Largest Contentful Paint (LCP), web.dev.
• web.dev, Optimize Largest Contentful Paint, web.dev.
• web.dev, Time to First Byte (TTFB), web.dev.
• Chrome for Developers, What’s new in Lighthouse 13, developer.chrome.com.
• WordPress, Image performance enhancements in WordPress 6.3, Make WordPress Core.
• HTTP Archive, Performance, Web Almanac 2025, almanac.httparchive.org.