Core Web Vitals er tre konkrete mål Google bruker for å vurdere hvordan en nettside oppleves av ekte brukere: hvor raskt innholdet laster, hvor raskt siden svarer når du klikker eller taster, og hvor stabilt innholdet ligger mens siden lastes. Målingene er en offisiell rangeringsfaktor i Google-søk, og samtidig en god temperaturmåler på selve brukeropplevelsen. I denne guiden går vi gjennom hva de tre målene betyr, hvilke terskelverdier som gjelder, hvordan du måler dem – og konkrete grep for å forbedre hver enkelt.
Hva er Core Web Vitals?
Core Web Vitals (ofte forkortet CWV) er et sett med tre standardiserte mål for brukeropplevelse som Google introduserte i 2020 og gjorde til en del av rangeringen i 2021. De inngår i Googles bredere «page experience»-signaler og utgjør en sentral del av teknisk SEO.
I stedet for å måle abstrakte serverdetaljer prøver Core Web Vitals å fange opp hvordan siden faktisk føles for den som besøker den. De tre målene dekker hver sin dimensjon:
- Lastehastighet – hvor raskt hovedinnholdet kommer på skjermen (LCP).
- Responsivitet – hvor raskt siden svarer når du samhandler med den (INP).
- Visuell stabilitet – hvor mye innholdet hopper eller flytter seg uventet (CLS).
Viktige punkter
- Tre mål: LCP (lastehastighet), INP (responsivitet) og CLS (visuell stabilitet).
- Offisiell rangeringsfaktor i Google-søk, og en del av «page experience»-signalene.
- Bygger på feltdata fra ekte Chrome-brukere (CrUX), ikke bare laboratorietester.
- Vurderes på 75-prosentilen av besøk, separat for mobil og datamaskin.
- INP erstattet FID 12. mars 2024 og er en strengere måling av responsivitet.
- Alle tre må bestå samtidig for at siden skal få grønt lys.
De tre målene forklart
Alle som jobber med nettsider bør kjenne de tre forkortelsene. Her er hva de betyr i praksis, forklart uten unødvendig fagsjargong.
Largest Contentful Paint (LCP)
LCP måler hvor lang tid det tar før det største synlige innholdselementet i det første skjermbildet er ferdig tegnet – typisk et stort bilde, en video-forhåndsvisning eller en stor overskrift. Kort sagt: hvor raskt opplever brukeren at hovedinnholdet er på plass. En lav LCP betyr at siden kjennes rask, mens en høy LCP ofte skyldes tunge bilder, treg server eller blokkerende skript.
Interaction to Next Paint (INP)
INP måler hvor raskt siden svarer visuelt når brukeren gjør noe – klikker, trykker på skjermen eller taster. Måleren erstattet den eldre First Input Delay (FID) den 12. mars 2024. Mens FID kun målte forsinkelsen på den aller første interaksjonen, ser INP på alle interaksjoner gjennom besøket og rapporterer i praksis den tregeste. Det gjør INP til et strengere og mer realistisk mål på responsivitet, og forklarer hvorfor mange nettsider som bestod FID-kravet nå sliter med INP.
Cumulative Layout Shift (CLS)
CLS måler visuell stabilitet – altså hvor mye innholdet hopper eller flytter seg uventet mens siden lastes. Et klassisk eksempel: du skal trykke på en knapp, men et bilde eller en annonse laster inn over og dytter knappen nedover, slik at du treffer feil. CLS er en enhetsløs poengsum der 0 betyr helt stabilt og høyere tall betyr mer forflytning.
Terskelverdier: hva er bra, middels og dårlig?
Google deler hver måling inn i tre nivåer: «bra», «trenger forbedring» og «dårlig». Vurderingen gjøres på 75-prosentilen av sidevisningene, målt separat for mobil og datamaskin. Det betyr at minst 75 % av besøkene må ligge innenfor «bra»-grensen før siden får grønt lys. Tabellen under viser de gjeldende grenseverdiene.
Terskelverdier
| Måling | Måler | Bra | Trenger forbedring | Dårlig |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | Lastehastighet | ≤ 2,5 sek | 2,5–4,0 sek | > 4,0 sek |
| INP (Interaction to Next Paint) | Responsivitet | ≤ 200 ms | 200–500 ms | > 500 ms |
| CLS (Cumulative Layout Shift) | Visuell stabilitet | ≤ 0,1 | 0,1–0,25 | > 0,25 |
Alle verdier måles på 75-prosentilen av sidevisningene, separat for mobil og datamaskin.
Merk at en side må prestere godt på alle tre målene samtidig for å bli regnet som bestått. Det hjelper lite å ha lynrask LCP hvis layouten hopper slik at CLS blir dårlig.
Feltdata og laboratoriedata – hva er forskjellen?
Når du måler Core Web Vitals møter du to typer data, og det er viktig å ikke blande dem sammen.
- Feltdata (også kalt Real User Monitoring) kommer fra ekte Chrome-brukere som besøker siden i virkeligheten, og samles i Chrome User Experience Report (CrUX). Det er disse dataene Google faktisk bruker i vurderingen av Core Web Vitals.
- Laboratoriedata kommer fra en kontrollert test i et fast miljø, for eksempel via verktøyet Lighthouse. Testen kan gjentas og er derfor god til feilsøking, men den gjenspeiler ikke variasjonen blant ekte brukere, enheter og nettforbindelser.
Begge har sin plass: feltdata forteller deg om du har et problem, mens laboratoriedata hjelper deg å finne årsaken. En vanlig fallgruve er å jage en perfekt Lighthouse-score i laboratoriet mens de ekte brukerne fortsatt opplever treghet.
Slik måler du Core Web Vitals
Du trenger ikke dyre løsninger for å komme i gang – flere av de beste verktøyene er gratis og kommer fra Google selv. En oversikt over både gratis og betalte alternativer finner du i vår guide til SEO-verktøy.
| Verktøy | Type data | Best til | Pris |
|---|---|---|---|
| PageSpeed Insights | Felt + laboratorium | Rask sjekk av én enkelt URL | Gratis |
| Core Web Vitals-rapporten i Search Console | Feltdata (CrUX) | Oversikt over hele nettstedet | Gratis |
| Lighthouse (i Chrome DevTools) | Laboratoriedata | Dypere feilsøking under utvikling | Gratis |
| Chrome User Experience Report (CrUX) | Feltdata | Rådata og sammenligning over tid | Gratis |
| web-vitals (JavaScript-bibliotek) | Feltdata | Egen måling i sanntid på egen side | Gratis |
For å overvåke hvordan hele nettstedet presterer over tid er Google Search Console det naturlige utgangspunktet. Core Web Vitals-rapporten der grupperer URL-ene dine etter status, slik at du ser hvilke sidetyper som drar ned snittet.
Slik forbedrer du hver måling
De tre målene har ulike årsaker og krever ulike tiltak. Her er de mest effektive grepene for hvert av dem.
Forbedre LCP (lastehastighet)
- Komprimer og skaler bilder riktig, og bruk moderne formater som WebP eller AVIF.
- Last inn det viktigste bildet tidlig, og unngå «lazy loading» på elementet som utgjør LCP.
- Reduser serverens responstid, gjerne med hurtigbuffer (caching) og et innholdsleveringsnettverk (CDN).
- Fjern eller utsett skript og stilark som blokkerer visningen av innholdet.
Forbedre INP (responsivitet)
- Del opp lange JavaScript-oppgaver i mindre biter, slik at nettleseren rekker å svare på klikk.
- Utsett arbeid som ikke er kritisk til etter at siden er vist.
- Fjern unødvendige tredjepartsskript, som tunge sporings- og annonseskript.
- Hold event-håndterere lette, og unngå tung beregning rett i det brukeren klikker.
Forbedre CLS (visuell stabilitet)
- Angi faste mål (bredde og høyde) på bilder, videoer og innebygde elementer, slik at plassen reserveres på forhånd.
- Sett av plass til annonser og innebygd innhold før de lastes.
- Unngå å skyte inn nytt innhold over innhold som allerede vises.
- Forhåndslast skrifttyper for å unngå at teksten bytter font og hopper.
Core Web Vitals og Google-rangering
Core Web Vitals er en bekreftet rangeringsfaktor, men det er viktig å ha et realistisk bilde av hvor mye de betyr. De er én av mange signaler, og relevant, godt innhold som svarer på søkeintensjonen veier normalt tyngre. Som vi forklarer i artikkelen hva er SEO, handler synlighet om summen av mange faktorer, ikke én enkelt knapp.
Google har også vært tydelig på at gode resultater i rapportene ikke er noen garanti for topplassering. Samtidig fungerer Core Web Vitals ofte som en «tiebreaker»: når to sider ellers er like relevante, kan den raskeste og mest stabile vinne. Og uavhengig av rangering skader en treg, ustabil side både brukeropplevelsen og konverteringen – besøkende forlater sider som kjennes trege.
Vanlige feil å unngå
- Å stole blindt på laboratoriescore. En flott Lighthouse-score betyr lite hvis feltdataene fra ekte brukere forteller en annen historie.
- Å bare teste forsiden. Problemene ligger ofte på artikkel- eller produktsider. Test flere sidetyper.
- Å glemme mobil. Google vurderer mobil og datamaskin hver for seg, og mobil er som regel den svakeste.
- Å behandle det som en engangsjobb. Nye bilder, skript og tredjepartsverktøy kan forringe verdiene over tid, så måling bør være en løpende rutine.
- Å optimere kun for målet, ikke for brukeren. Poenget er en bedre opplevelse – tallene er bare en indikator.
Kildehenvisninger
Vanlige spørsmål (FAQ)
Hva er en god Core Web Vitals-score?
En side regnes som god når LCP er 2,5 sekunder eller raskere, INP er 200 millisekunder eller lavere, og CLS er 0,1 eller lavere – målt på 75-prosentilen av ekte besøk. Alle tre må være innenfor grensen samtidig for at siden skal bestå.
Hva skjedde med First Input Delay (FID)?
FID ble erstattet av Interaction to Next Paint (INP) som Core Web Vital den 12. mars 2024. INP er strengere fordi den ser på alle interaksjoner gjennom besøket, ikke bare den første, og gir derfor et mer realistisk bilde av responsiviteten.
Påvirker Core Web Vitals Google-rangeringen?
Ja, Core Web Vitals er en bekreftet rangeringsfaktor i Google-søk. De er likevel bare ett av mange signaler, og relevant innhold som svarer på søket veier tyngre. Gode verdier garanterer ikke topplassering, men kan være avgjørende mellom to ellers likeverdige sider.
Hvordan måler jeg Core Web Vitals gratis?
Du kan bruke Googles egne gratisverktøy: PageSpeed Insights for en enkelt URL, Core Web Vitals-rapporten i Search Console for hele nettstedet, og Lighthouse i Chrome for feilsøking. Alle gir deg innsikt i både felt- og laboratoriedata.
Hvor ofte bør jeg sjekke Core Web Vitals?
Core Web Vitals bør overvåkes løpende, ikke bare én gang. Nytt innhold, bilder, oppdateringer og tredjepartsskript kan endre verdiene. En månedlig gjennomgang i Search Console, pluss en ny test etter større endringer på nettstedet, er en fornuftig rutine.

