Core Web Vitals er tre mål, Google bruger til at vurdere den oplevelse, en side giver: LCP, INP og CLS. De måler henholdsvis, hvor hurtigt hovedindholdet bliver synligt, hvor hurtigt siden svarer, når man trykker, og hvor meget indholdet flytter sig undervejs.
Grænseværdierne for en god oplevelse er:
| Mål | Hvad det måler | God værdi |
|---|---|---|
| LCP (Largest Contentful Paint) | Hvornår det største indholdselement er tegnet | 2,5 sekunder eller hurtigere |
| INP (Interaction to Next Paint) | Hvor hurtigt siden reagerer på klik og tryk | 200 millisekunder eller hurtigere |
| CLS (Cumulative Layout Shift) | Hvor meget layoutet hopper, mens siden loader | 0,1 eller lavere |
Målene vurderes ved 75. percentil af sidevisninger, og mobil og computer bliver vurderet hver for sig. Det betyder i praksis, at tre ud af fire besøg skal ligge inden for grænsen, og at en god score på din bærbare ikke siger noget om mobilen.
Kilde: Googles egen dokumentation på web.dev.
LCP: hvornår indholdet er der
LCP måler, hvornår det største synlige element er tegnet færdigt. På de fleste sider er det et hovedbillede eller en stor overskrift.
Det er det mål, der ligner den oplevelse, folk faktisk har, mest: ventetiden fra man trykker på et link, til der står noget brugbart på skærmen.
Det, der typisk trækker LCP ned, er store billeder. Et billede, der er fremstillet til en bred skærm og sendt uændret til en telefon, skal hentes over mobilnet og dekodes på en langsommere processor, inden det bliver vist. Derefter skalerer browseren det ned, og al den ekstra opløsning var spildt ventetid.
To ting, der tit gør mest ved LCP: send billeder i flere størrelser, så browseren kan vælge den rigtige, og lad være med at udskyde indlæsningen af netop det billede, der ligger øverst. Automatisk lazy loading på alle billeder er et godt råd, der bliver forkert præcis der.
INP: hvor hurtigt siden svarer
INP måler tiden fra en bruger trykker eller klikker, til skærmen viser resultatet. Målet afløste det tidligere FID og blev et fast Core Web Vital i 2024. Forskellen er væsentlig: FID målte kun forsinkelsen på den første interaktion, mens INP ser på interaktionerne gennem hele besøget.
Dårlig INP handler næsten altid om JavaScript. Når browseren er optaget af at køre kode, kan den ikke nå at reagere på et tryk. Det opleves som en side, der hænger et øjeblik, når man trykker på en knap.
De almindelige syndere er tredjepartsscripts: chatwidgets, anmeldelsesmoduler, sporingspixels og apps, der loader på hver eneste side, uanset om de bliver brugt.
CLS: hvor meget siden hopper
CLS måler, hvor meget indholdet flytter sig, mens siden bliver bygget. Det er den, alle har oplevet: man er ved at trykke på et link, et banner lander ovenover, og man rammer noget andet.
Årsagen er næsten altid, at der ikke er reserveret plads til noget, der kommer senere. Et billede uden angivet højde og bredde. En skrifttype, der skifter, når den rigtige lander. En cookiebanner eller en annonce, der skubber alt nedad.
CLS er som regel det billigste mål at rette, fordi løsningen er mekanisk: fortæl browseren, hvor meget plads tingene skal bruge, før de kommer.
Hvor meget betyder det for placeringen i Google?
Her er det værd at være præcis, fordi der bliver sagt meget løst om det.
Core Web Vitals indgår i Googles vurdering af sider. De er ikke den vigtigste faktor, og en hurtig side med svagt indhold slår ikke en langsom side med det rigtige svar. Relevans kommer først.
Til gengæld er målene relevante uanset placering, fordi de beskriver noget, brugeren mærker. En side, der er langsom at åbne og hopper under fingeren, taber besøgende, før spørgsmålet om rangering overhovedet bliver aktuelt.
Sådan måler du dine egne tal
Der findes to slags data, og de svarer på hver sit spørgsmål.
Feltdata er målinger fra rigtige besøgende. Det er dem, Google bruger i sin vurdering, og du finder dem i Search Console. De er facit, men de er langsomme, fordi de dækker en periode.
Labdata er en simuleret måling, for eksempel Lighthouse eller PageSpeed Insights. De giver svar med det samme og er gode til at finde årsager, men en enkelt kørsel svinger. Kør flere gange under de samme betingelser, og brug tallet som en sammenligning med sig selv frem for som en karakter.
Det sidste er vigtigt. Vi målte vores eget site før og efter en optimering under ens forhold, og LCP på forsiden faldt fra omkring 3.700 millisekunder til omkring 1.660. Det interessante var ikke scoren, men at næsten hele gevinsten lå i billedhåndtering, ikke i JavaScript, som var den oplagte mistænkte.
Kom i gang i den rigtige rækkefølge
- Se feltdata i Search Console for at vide, om der overhovedet er et problem
- Kør en måling på de vigtigste sidetyper, ikke kun forsiden
- Start ved billederne, for det er oftest der, tiden ligger
- Gennemgå tredjepartsscripts, og fjern dem ingen kan huske at have bestilt
- Reserver plads til billeder, skrifttyper og bannere
- Mål igen under samme forhold som første gang
Vil du have det konkret for din platform, har vi skrevet om hastighedsoptimering på mobil, og hvad en mobilvenlig hjemmeside egentlig kræver.
Vi bygger performance ind i fundamentet, når vi laver en hjemmeside i WordPress, og vi holder øje med det løbende for de webshops, vi passer gennem Shopify Support. Er I i tvivl om, hvor jeres site står, så få en gratis webanalyse.