← Back to blog

Core Web Vitals: hva du må måle og forbedre først

August 24, 2026
Core Web Vitals: hva du må måle og forbedre først

Core Web Vitals er tre feltbaserte målemetoder Google bruker for å vurdere brukeropplevelsen på nettsiden din: LCP (lastetid), INP (responstid) og CLS (visuell stabilitet). Målene du skal treffe følger Googles offisielle terskler for god brukeropplevelse.

Disse tre metrikkene klassifiseres på 75. persentil av faktiske besøk, ikke gjennomsnitt. Det betyr at et enkelt raskt besøk ikke redder deg. Tre av fire besøkende må oppleve siden innenfor disse grensene før Google regner den som «god».

Prioriter måling på disse sidene først:

  • Landingssider fra søk og annonser
  • Produktsider eller tjenestesider med høy trafikk
  • Skjemaer og kjøpsflows der brukere faller av

Neste steg er enkelt: mål med riktig verktøy, se hvilken metrikk som svikter, og fiks de tekniske årsakene i prioritert rekkefølge. Resten av artikkelen viser deg nøyaktig hvordan.

Viktige funn

Core Web Vitals krever at 75 % av dine besøkende opplever LCP under 2,5 sekunder, INP under 200 millisekunder og CLS under 0,1 for å bli klassifisert som god.

PunktDetaljer
Tre målbare tersklerLCP ≤2 500 ms, INP ≤200 ms og CLS ≤0,1 er grensene for «god» ytelse på 75. persentil.
Feltdata avgjør rangeringCrUX-baserte feltdata i Search Console teller for søk, ikke labtester i Lighthouse.
Lav innsats gir størst effekt førstBildekomprimering, CDN og ressursprioritering løser ofte mer enn finpuss på animasjoner.
INP krever hovedtråd-fokusBryt opp lange JavaScript-oppgaver og lazy-load ikke-kritiske skript.
Skapeflyt bygger ytelse inn fra startNettsider fra Skapeflyt leveres med Core Web Vitals-optimalisering i grunndesignet, normalt innen én uke.

Innholdsfortegnelse

Hva betyr LCP, INP og CLS i praksis?

LCP (Largest Contentful Paint) måler tiden fra siden begynner å laste til det største synlige elementet, ofte et heltebilde eller en overskrift, er ferdig rendret. Brukeren opplever dette som «når siden faktisk dukker opp». Et nettsted som bruker fem sekunder på dette føles tregt, selv om resten av siden lastes lynraskt i bakgrunnen.

INP (Interaction to Next Paint) erstattet den eldre metrikken FID i 2024 og måler responstiden på klikk, tastetrykk og trykk gjennom hele besøket, ikke bare det første klikket. Dette fanger opp et frustrerende problem: knapper som ser klikkbare ut, men som ikke reagerer før JavaScript-motoren er ferdig med noe annet.

CLS (Cumulative Layout Shift) teller hvor mye innhold flytter seg uventet mens siden laster. Du kjenner følelsen: du er i ferd med å trykke på en knapp, og plutselig hopper en annonse inn og du klikker feil.

De offisielle terskelverdiene er:

  • LCP: ≤2 500 ms er godt, 2 500–4 000 ms krever forbedring, over 4 000 ms er dårlig
  • INP: ≤200 ms er godt, 200–500 ms krever forbedring, over 500 ms er dårlig
  • CLS: ≤0,1 er godt, 0,1–0,25 krever forbedring, over 0,25 er dårlig

Disse grensene og klassifiseringsmetoden kommer direkte fra Google og oppdateres av og til når nettet endrer seg. INP er selve beviset på dette: den byttet ut FID fordi FID bare fanget første interaksjon, ikke hele brukssesjonen.

De vanligste årsakene til dårlig score går igjen på tvers av bransjer: uoptimaliserte bilder som mangler komprimering, tunge tredjepartsskript fra annonser og analyseverktøy, og medieelementer uten fastsatt bredde og høyde som gjør at layouten hopper rundt. Ingen av disse er eksotiske problemer. De er vanlige nok til at de fleste nettsteder har minst ett av dem akkurat nå.

Hvordan måler du Core Web Vitals riktig?

Du må skille mellom to datatyper, ellers jakter du på feil tall. Feltdata kommer fra faktiske besøkende og samles inn via Chrome User Experience Report (CrUX), som driver rapportene i Search Console og feltdelen av PageSpeed Insights. Labdata kommer fra simulerte tester i verktøy som Lighthouse eller Chrome DevTools, kjørt under kontrollerte forhold.

Labdata er nyttig for feilsøking fordi du kan reprodusere problemet på kommando. Feltdata er det som faktisk bestemmer søkerangeringen din, fordi det reflekterer virkelige mobilnettverk, gamle telefoner og trege wifi-forbindelser.

Slik går du frem i praksis:

  1. Start i Google Search Console under rapporten for Core Web Vitals. Der ser du hvilke URL-grupper som er «god», «må forbedres» eller «dårlig», delt på mobil og desktop.
  2. Bruk PageSpeed Insights for å se konkret hva som bremser en enkelt side, med feltdata og labdata side ved side.
  3. Grav dypere med Chrome DevTools sitt ytelsespanel når du trenger å se nøyaktig hvilket skript som blokkerer hovedtråden.
  4. Installer web-vitals JavaScript-biblioteket hvis du vil sende egne målinger til Google Analytics eller et annet dashboard, slik at du fanger opp data i samme øyeblikk som Google gjør.

Profftips: Overvåk ikke bare forsiden. De sidene som konverterer mest, blogginnlegg som rangerer høyt eller produktsider med mye trafikk, er akkurat der en dårlig INP-score kostet deg mest i tapt omsetning.

Hvilke tiltak gir størst effekt for hver metrikk?

Ikke alle tiltak er like verdt tiden din. Størst gevinst kommer typisk fra lav innsats med høy effekt: bilder, ressursprioritering og CDN, ikke finpuss på små CSS-animasjoner. Start der.

For LCP:

  • Sørg for at det største elementet lastes tidlig i HTML-koden, ikke via JavaScript som kjører sent
  • Bruk fetchpriority="high" på hovedbildet slik at nettleseren prioriterer det
  • Sett opp et CDN for å redusere TTFB (tiden til første byte), spesielt hvis besøkende er spredt geografisk
  • Komprimer og skaler bilder riktig. Et bilde på 3 MB som vises i 400 piksler bredde er bortkastet båndbredde

For INP:

  • Bryt opp lange JavaScript-oppgaver i mindre biter med setTimeout eller requestIdleCallback, slik at hovedtråden får puste mellom hver oppgave
  • Flytt tunge beregninger til web workers når det er mulig
  • Utsett og lazy-load skript som ikke er kritiske for første interaksjon, som chatwidgeter og sosiale medier-integrasjoner
  • Minimer tredjepartssporing. Rask servertid løser ikke INP-problemer hvis flaskehalsen ligger i hvor mye JavaScript nettleseren må kjøre

For CLS:

  • Angi eksplisitt width og height eller aspect-ratio på alle bilder og videoer
  • Reserver plass for annonser og iframer før de lastes, slik at innholdet ikke hopper når de dukker opp
  • Bruk CSS transform og opacity for animasjoner i stedet for egenskaper som top eller margin, som tvinger nettleseren til å beregne layouten på nytt

Profftips: Test endringene i et testmiljø før produksjon. En optimalisering som ser bra ut i Lighthouse kan likevel skade feltdata hvis du ikke måler på ekte trafikk etter lansering.

Mål feltdata igjen én til to uker etter en endring. Feltdata trenger tid til å samle nok besøk før Google oppdaterer klassifiseringen din.

Hvordan bygger du en løpende arbeidsflyt for overvåking?

Core Web Vitals er ikke noe du fikser én gang og glemmer. Sider endrer seg, plugins oppdateres, og nye tredjepartsskript sniker seg inn.

  1. Sett opp Search Console til å sende varsler når en URL-gruppe forverres, og eksporter CrUX-data regelmessig for å følge trender over tid.
  2. Bruk PageSpeed Insights til ad-hoc feilsøking når en enkelt side svikter, og la CrUX-trendene fortelle deg om problemet er isolert eller strukturelt.
  3. Utpek én ansvarlig, ofte en utvikler eller markedsfører, og sett en fast frekvens, månedlig eller kvartalsvis, for gjennomgang.
  4. Lag en enkel sjekkliste: nye bilder komprimert før opplasting, plugins oppdatert, ingen nye tredjepartsskript lagt til uten vurdering.

Denne rytmen fanger opp regresjoner før de blir et rangeringsproblem, ikke etter.

Skapeflyts erfaring og når du bør hente inn ekstern hjelp

Skapeflyt bygger nettsider for bedrifter i Bergen med teknisk ytelse innebygd fra start, en prosess som normalt tar under en uke. Se referanser fra tidligere prosjekter for konkrete eksempler.

Du bør hente inn ekstern hjelp når:

  • INP-problemer skyldes kode du ikke selv har skrevet eller kontrollerer
  • Flere tiltak er prøvd uten at feltdata forbedres
  • Du mangler tid til å følge opp målingene løpende

Forfatterens perspektiv: hvorfor Core Web Vitals fortsatt er viktig for forretning

Mange behandler Core Web Vitals som et teknisk sjekkpunkt for utviklere. Det er en feilvurdering. En treg side er det første tillitsbruddet en besøkende opplever, før de har lest et eneste ord av innholdet ditt.

For små og mellomstore nettsteder er rådet enkelt: fiks LCP og CLS først, de er billigst å løse og har størst synlig effekt. INP krever ofte mer teknisk innsikt, så vent til de to første er i god stand.

— Skape

Vil du ha en teknisk gjennomgang av nettsiden din?

Skapeflyt er alternativet til et tradisjonelt reklamebyrå for bedrifter i Bergen som vil ha en nettside som faktisk laster raskt, ikke bare ser bra ut i et forslag. Der mange byråer leverer en ferdig mal og lar deg selv jakte på ytelsesproblemer etterpå, bygger Skapeflyt siden med Core Web Vitals som del av leveransen fra dag én.

Skapeflyt

Vi går gjennom LCP, INP og CLS på din eksisterende side eller bygger den nye siden din med disse målene innebygd i designet. Hele prosessen fra første samtale til lansert side tar normalt under en uke. Se priser fra 7 500 kr eller besøk siden om webdesign i Bergen for å se hvordan vi jobber. Ta kontakt med Skapeflyt for en uforpliktende gjennomgang av nettsiden din.

Kilder

Anbefaling

Created with BabyLoveGrowth for content creation