Largest Contentful Paint: mål og optimer, hvor hurtigt hovedindholdet indlæses

LCP måler, hvornår hovedindholdet er indlæst. Optimer billeder, skær ned på CSS og JavaScript, og forhåndsindlæs ressourcer. Mål: under 2,5 sekunder.

Kladde

LCP måler tiden, til hovedindholdet er indlæst. Hovedindholdet er det største tekstafsnit eller billede på siden. På de fleste sider er LCP den vigtigste måling, fordi den afgør, hvornår siden bliver nyttig for brugeren.

Brugeren lander på siden. Siden begynder at indlæses. Browseren henter HTML. Browseren henter CSS. Browseren henter JavaScript. HTML bliver vist. CSS sætter stilen. JavaScript kører. Hovedindholdet dukker op. Det er LCP.

En LCP på ét sekund er fremragende. Brugeren ser indholdet hurtigt. En LCP på tre sekunder er langsom. Brugeren venter. En LCP på fem sekunder er meget langsom. Brugeren forlader siden.

Hvad tæller som Largest Contentful Paint

Det største element på siden, før man scroller. Som regel et billede eller en overskrift. Eksempel: en forside med et stort billede øverst. Billedet er det største element. Tidspunktet, hvor billedet vises, er LCP.

Eksempel: en blogartikel med en overskrift. Overskriften er det største element. Tidspunktet, hvor overskriften vises, er LCP.

Eksempel: en produktside med et produktbillede. Produktbilledet er det største element. Tidspunktet, hvor produktbilledet vises, er LCP.

LCP måles fra det øjeblik, brugeren klikker på et link (starten på sideindlæsningen), til det største element vises. Det omfatter tiden til at hente HTML, CSS og JavaScript, hente billedet og vise siden.

Sådan optimerer du LCP

Mål for optimeringen: LCP under 2,5 sekunder.

Strategi ét: Optimer serverens svartid (TTFB). En hurtigere server betyder, at HTML ankommer hurtigere. HTML skal være der, før siden kan vises. Sænk TTFB ved at forbedre serveren, bruge et CDN og skære ned på databaseforespørgsler.

Strategi to: Gør CSS-filen mindre. Mindre CSS hentes hurtigere. CSS skal være hentet, før siden vises. Skær ned på CSS ved at fjerne ubrugte typografier, minificere og udsætte CSS, der ikke er kritisk.

Strategi tre: Gør JavaScript-filen mindre. Meget JavaScript forsinker kørsel og visning. Skær ned på JavaScript ved at fjerne ubrugt kode, dele store filer op og udsætte JavaScript, der ikke er kritisk.

Strategi fire: Optimer billeder. Billeder er ofte de største elementer (LCP). Gør billedfilerne mindre ved at komprimere dem, bruge moderne formater (WebP) og skære ned på billedernes mål.

Strategi fem: Forhåndsindlæs kritiske ressourcer. Bed browseren om at hente det vigtige billede eller den vigtige skrifttype tidligt. Billedet hentes samtidig med HTML og CSS. Det sænker LCP.

Et ægte eksempel: LCP-optimering af en blogartikel

LCP i udgangspunktet: 2,8 sekunder.

Analyse: Artiklens hovedbillede er det største element. Billedet fylder to megabyte. Det tager 1,2 sekunder at hente. Hentningen af billedet er flaskehalsen.

Optimering

Komprimer billedet: fra to megabyte til 0,5 megabyte. Hentetiden er nu 0,3 sekunder.

Konverter til WebP: billedet bliver endnu mindre, 0,3 megabyte. Hentetiden er nu 0,1 sekunder.

Forhåndsindlæs billedet: browseren henter billedet tidligt. Billedet hentes samtidig med HTML. Det sparer 0,2 sekunder.

Flyt den kritiske CSS til toppen af siden: siden kan vises tidligere. Det sparer 0,3 sekunder.

Ny LCP: 1,7 sekunder.

2,8 minus 1,2 (hentning af billedet) plus 0,1 (hentning af det komprimerede billede) er lig med 1,7 sekunder. Under målet på 2,5.

LCP og forskellige sidetyper

Forside

Billedet øverst er som regel LCP. Optimer ved at komprimere billedet, bruge et CDN og forhåndsindlæse.

Blogartikel

Overskriften eller det første billede er LCP. Optimer ved at skære ned på forsinkelsen fra CSS og JavaScript og forhåndsindlæse skrifttyper.

Produktside

Produktbilledet er LCP. Optimer ved at komprimere billedet og bruge responsive billeder til forskellige enheder.

Betalingsside

Formularen eller knappen er LCP. Optimer ved at skære ned på CSS og JavaScript og forhåndsindlæse kritiske ressourcer.

Forskellige sidetyper kræver forskellige strategier. Find ud af, hvilket element der er din LCP. Optimer det element.

LCP på mobil og computer

LCP er som regel langsommere på mobil end på computer. Mobilnetværk er langsommere. Mobile enheder har mindre regnekraft.

LCP på computer i udgangspunktet: 1,5 sekunder. LCP på mobil i udgangspunktet: tre sekunder.

Mobil er dobbelt så langsom. Mobilbrugere mærker langsomheden tydeligere.

Optimer til mobil først. Gør billederne mindre (båndbredden på mobil er begrænset). Brug mindre JavaScript (mobile enheder er langsommere til at læse det). Brug formater, der passer til mobil.

Sådan måler du forbedringen af LCP

LCP i udgangspunktet

Mål, før du optimerer.

Gennemfør optimeringen

Ny LCP

Mål, efter du har optimeret.

Forbedring

LCP i udgangspunktet minus ny LCP.

Eksempel

Udgangspunkt 2,8 sekunder. Efter optimering 1,7 sekunder. Forbedringen er 1,1 sekunder.

Regn effekten ud

En forbedring på 1,1 sekunder kan hæve konverteringsraten med én procent (afhængigt af udgangspunktet og branchen). Med 50.000 besøgende om måneden er det 500 ekstra konverteringer med en ordreværdi på 100 dollar. Det er 50.000 dollar om måneden. 600.000 dollar om året.

Sammenlign med prisen for optimeringen. Koster den 50.000 dollar, er den tjent ind på én måned. Fremragende ROI.

Ofte stillede spørgsmål

Hvordan finder vi ud af, hvilket element der er vores LCP?

Brug Google Chrome DevTools. Højreklik på siden. Vælg Inspicer. Åbn fanen Performance. Optag sideindlæsningen. DevTools viser LCP-elementet. Eller tjek PageSpeed Insights. Lighthouse peger på LCP-elementer. Tjek også rapporten om Core Web Vitals i Search Console. Den viser LCP-elementer på siderne. Med WEMASY's hjemmesidebygger kan du sætte det op direkte på din hjemmeside.

Skal vi optimere LCP på alle sider eller kun på forsiden?

Optimer alle sider. Men prioriter efter trafik. Forsiden er vigtig, men det er produktsiderne også (i en webshop) eller artikelsiderne (hos udgivere). Mål LCP på alle vigtige sider. Prioriter optimeringen efter trafikmængde.

Hjælper forhåndsindlæsning altid på LCP?

Ikke altid. Forhåndsindlæsning bruger båndbredde. Forhåndsindlæser du en uvigtig ressource, bruger du båndbredde, som kunne have hentet en vigtig ressource. Forhåndsindlæs kun kritiske ressourcer (billedet øverst, en kritisk skrifttype). Forhåndsindlæs ikke ressourcer, der ikke er kritiske.

Hvordan optimerer vi LCP, når hovedindholdet er dynamisk (hentet fra en API)?

Ventetiden på API-kaldet lægges oven i LCP. Sænk API'ets svartid ved at optimere databasen, gemme svar i cache og bruge et CDN. Vis også en pladsholder, mens API'et indlæser. Pladsholderen vises med det samme. Brugeren oplever siden som indlæst. Det rigtige indhold fylder ind bagefter. Den oplevede LCP er hurtigere end den rigtige LCP.

Skal vi bruge lazy loading på LCP-elementet?

Nej. Lazy loading udsætter et billede, til det er ved at komme ind i synsfeltet. Ligger billedet øverst på siden (LCP-elementet), forsinker lazy loading det uden grund. Brug kun lazy loading på billeder længere nede. Indlæs LCP-elementet med det samme.

Hvordan adskiller LCP sig fra FCP (First Contentful Paint)?

FCP er det øjeblik, hvor noget indhold vises (det kan være en lille tekst). LCP er det øjeblik, hvor hovedindholdet vises (som regel et større billede eller en overskrift). FCP er hurtigere end LCP. LCP er vigtigere for brugeroplevelsen. Forbedr LCP først.

Brug det med det samme
på din egen hjemmeside.

Start gratis med WEMASY, og byg din side på få minutter.