Core Web Vitals er tre målinger Google bruker for å beskrive hvordan en nettside oppleves av dem som besøker den. De måler hvor raskt hovedinnholdet vises, hvor kjapt siden svarer når du trykker på noe, og om innholdet står stille mens siden laster.
Du trenger ikke å kunne kode for å forstå dem, og du trenger heller ikke å fikse alt selv. Men du bør kunne lese tallene, vite hvilket av dem som er verdt å bruke penger på, og kunne stille utvikleren din et presist spørsmål.
De tre målingene
LCP: hvor raskt hovedinnholdet vises
Largest Contentful Paint måler tiden det tar før det største synlige elementet på siden er på plass. På en artikkel er det som regel toppbildet eller overskriften. Grensen for «god» er 2,5 sekunder.
Typiske årsaker til dårlig LCP er store, ukomprimerte bilder, treg webhotell-respons og skrifter eller stilark som blokkerer visningen.
INP: hvor raskt siden svarer
Interaction to Next Paint måler hvor lang tid det tar fra du trykker på noe til du ser at noe skjer. Grensen for «god» er 200 millisekunder. INP erstattet den eldre målingen First Input Delay i 2024, så guider som fortsatt nevner FID er utdaterte.
Dette er den målingen flest nettsteder stryker på. Årsaken er nesten alltid for mye JavaScript, ofte fra plugins, sporingskoder, chat-widgeter og samtykkebannere som alle laster samtidig.
CLS: om innholdet hopper
Cumulative Layout Shift måler om elementer flytter på seg mens siden laster. Du kjenner det igjen som at du begynner å lese, og så dytter et bilde eller en annonse teksten nedover. Grensen for «god» er 0,1.
Den vanligste årsaken er bilder uten oppgitt bredde og høyde. Nettleseren vet da ikke hvor mye plass den skal reservere, og må flytte alt når bildet endelig kommer. Skrifter som byttes ut underveis og bannere som settes inn på toppen gir samme effekt.
Tallene er hentet fra ekte brukere
Dette er det viktigste å forstå, og det som forvirrer flest. Google vurderer deg på feltdata, altså målinger fra reelle besøkende i Chrome, samlet i det som heter CrUX-datasettet.
To konsekvenser følger av det:
- Du må bestå for 75 prosent av besøkene. Det holder ikke at siden er rask for deg på kontornettet. Den må være rask nok for tre av fire, også de på middels mobil og dårlig dekning.
- Dataene ruller over 28 dager. Gjør du en forbedring i dag, tar det uker før den slår ut i tallene. Bli ikke skuffet etter tre dager.
Nettsteder med lite trafikk får kanskje ikke nok data i det hele tatt. Da faller Google tilbake på tall for hele domenet, eller viser ingenting. Det gjør ikke arbeidet mindre verdt, det gjør bare at du må måle på andre måter.
Hvor du sjekker tallene
Tre verktøy dekker behovet for de fleste:
- Google Search Console har en egen rapport for Core Web Vitals. Denne er best til å se hvilke grupper av sider som har problemer, siden Google grupperer like sider sammen.
- PageSpeed Insights viser både feltdata øverst og en laboratoriemåling under. Feltdataene er det Google bedømmer deg på.
- Lighthouse i nettleseren gir deg en simulert måling. Nyttig for å teste effekten av en endring raskt, men den er ikke fasit.
Blander du sammen laboratoriemåling og feltdata, ender du fort med å jobbe med feil problem. En perfekt Lighthouse-score betyr ingenting hvis brukerne dine sitter på en femårig Android og fire strekers dekning. Det motsatte forekommer også: en middelmådig score i laboratoriet kan skjule at ekte brukere har det helt greit.
Bruk Lighthouse til det den er god på, nemlig å peke ut hva som forsinker siden og hvor mye hvert enkelt problem koster. Bruk feltdataene til å avgjøre om du har et problem i det hele tatt.
Slik prioriterer du
Du skal ikke fikse alt. Rekkefølgen jeg bruker:
- Se etter det som er rødt, ikke gult. En måling i «poor»-sonen er der du har mest å hente. En som allerede er grønn er ferdig.
- Ta CLS først hvis den er dårlig. Den er som regel billigst å fikse, ofte bare et spørsmål om å oppgi bildestørrelser.
- Deretter LCP. Komprimerte bilder i moderne format, bedre hosting og færre blokkerende ressurser løser mye.
- INP til slutt. Den er vanskeligst og krever som regel at noen går gjennom hvilke skript som lastes og hvorfor.
Og et forbehold verdt å ha med: Core Web Vitals er en rangeringsfaktor, men en beskjeden en. Den avgjør sjelden hvem som vinner et søk. Den fungerer mer som en tiebreaker mellom sider som ellers er like gode, og som en direkte påvirkning på hvor mange som blir værende. Hastighet påvirker konvertering uansett hva Google måtte mene om det.
Hva du kan gjøre selv
Uten å skrive en linje kode kan du komme langt:
- komprimere bilder og bruke moderne format som WebP, se bilder i WordPress
- oppgi bredde og høyde på alle bilder
- rydde bort plugins du ikke bruker
- vurdere om chat, sporing og bannere er verdt vekten sin
- sjekke om webhotellet er flaskehalsen
Er du på WordPress, ligger de fleste av disse grepene beskrevet i hastighetsoptimalisering i WordPress, og temaet ditt spiller en større rolle enn mange tror, se Core Web Vitals og WordPress-tema.
Spørsmålet du bør stille utvikleren
I stedet for «kan du gjøre siden raskere», som er umulig å svare presist på, still dette: hvilken av de tre målingene stryker vi på i feltdataene, på hvilke sidetyper, og hva er den enkeltårsaken som bidrar mest?
Det flytter samtalen fra en generell følelse av treghet til et konkret problem med en konkret pris. Det er også den beste måten å unngå å betale for optimalisering av noe som allerede var grønt.