Tre tal, målt på
rigtige brugere.

Core Web Vitals består af tre målinger. En URL består, når alle tre ligger i det grønne felt for 75 % af de indsamlede sidevisninger — målt separat for mobil og desktop.

Zonerne imellem er værd at kende, fordi de afgør om et fund haster. LCP mellem 2,5 og 4,0 sekunder er »kræver forbedring«, over 4,0 er dårlig. INP mellem 200 og 500 millisekunder kræver forbedring, over 500 er dårlig. CLS mellem 0,1 og 0,25 kræver forbedring, over 0,25 er dårlig.

75. percentil er den detalje flest overser. Det er ikke gennemsnittet der tæller, men den fjerdedel af dine besøgende der har den dårligste oplevelse. Et site kan have et pænt gennemsnit og stadig dumpe, fordi hver fjerde bruger sidder på mobil med et langsomt netværk og en gammel telefon.

Rækkefølgen herunder er sorteret efter hvor ofte den løser problemet — ikke efter hvor svær den er at udføre.

1. 01

   LCP: find elementet, før du optimerer noget

   Largest Contentful Paint måler hvornår det største synlige element er tegnet — typisk et hero-billede, en video-plakat eller en stor overskrift. Halvdelen af alt LCP-arbejde bliver spildt, fordi man optimerer et andet element end det målingen faktisk rammer. Find elementet først, og se derefter hvor tiden går: serverens svartid, ventetid før ressourcen bliver opdaget, selve hentningen, eller tiden fra den er hentet til den bliver tegnet.

2. 02

   LCP: lazy-load aldrig det element der måles

   loading="lazy" på hero-billedet er den mest udbredte selvskade i feltet. Billedet bliver først opdaget efter layoutet er beregnet, og LCP skrider med et halvt sekund eller mere. Giv i stedet elementet fetchpriority="high", og lad lazy-loading gælde alt under folden.

3. 03

   INP: problemet er lange opgaver, ikke antallet af scripts

   Interaction to Next Paint måler forsinkelsen fra brugeren klikker, til skærmen viser svaret. Tallet bliver dårligt, når hovedtråden er optaget af én lang opgave — et tredjepartsscript der initialiserer, en stor React-hydrering, en cookie-dialog der beregner samtykke. Del arbejdet op, udskyd det der ikke skal køre ved første interaktion, og mål på mobil, hvor CPU'en er langsommere.

4. 04

   CLS: reservér pladsen, før indholdet kommer

   Cumulative Layout Shift opstår, når noget bliver indsat efter layoutet er tegnet: et billede uden width og height, en annonce der folder sig ud, en cookiebanner der skubber teksten ned, eller en webfont der erstatter fallback-skriften med anden bredde. Alle fire har den samme løsning — afsæt pladsen på forhånd.

5. 05

   TTFB: den skjulte del af LCP

   Time To First Byte indgår ikke i Core Web Vitals som selvstændig måling, men den ligger inde i LCP. Bruger serveren 1,4 sekunder på at svare, har du 1,1 sekund tilbage af budgettet til alt andet. Cache, hosting og databasekald flytter tallet mere end nogen billedoptimering.

Core Web Vitals er ikke en opgave man afslutter. Tallene forfalder af sig selv: et nyt sporingsscript fra marketing, en tredjepartswidget, et tema-opdatering der fjerner billeddimensionerne. Ingen af delene ser ud som en fejl i udrulningen.

Agenten måler derfor på fast interval og sammenligner mod sidste måling. Falder LCP-medianen på en skabelon, kobles det til den dag ændringen skete, så du leder efter årsagen i den rigtige uge og ikke i alle de foregående. Det samme gælder trafikfald: uden en tidsserie kan man ikke se forskel på en core update og sin egen udrulning fra samme weekend.

Læs også guiden til teknisk SEO — hastighed hjælper ikke på en side der ikke er indekseret.