Core Web Vitals: hva LCP, INP og CLS betyr, hvorfor de er viktige og hvordan du optimaliserer dem

Definisjon

Core Web Vitals er tre måltall fra Google, LCP, INP og CLS, som måler hvor raskt en side laster, hvor raskt den svarer på interaksjon og hvor visuelt stabil den er. De inngår i Page Experience og er et bekreftet rangeringssignal.

De tre Core Web Vitals-målene – LCP, INP og CLS

Core Web Vitals er tre måltall Google bruker for å kvantifisere hvordan en side oppleves av ekte brukere: hvor raskt den laster, hvor raskt den svarer på interaksjon og hvor visuelt stabil den er. Hvert mål vurderes på den 75. persentilen av de besøkendes sidevisninger – altså den opplevelsen minst tre av fire brukere får.

• LCP (Largest Contentful Paint) – lasteytelse: tiden til sidens største synlige element (oftest et hero-bilde eller en stor overskrift) er rendret. Bra: under 2,5 s · Bør forbedres: 2,5–4 s · Dårlig: over 4 s.
• INP (Interaction to Next Paint) – responsivitet: forsinkelsen fra brukeren klikker, trykker eller skriver til neste bilderute tegnes opp. INP tar hensyn til alle interaksjoner i løpet av besøket, ikke bare den første. Bra: under 200 ms · Bør forbedres: 200–500 ms · Dårlig: over 500 ms.
• CLS (Cumulative Layout Shift) – visuell stabilitet: hvor mye innholdet hopper uventet under lasting, for eksempel når et bilde uten reservert høyde dytter teksten nedover. Bra: under 0,1 · Bør forbedres: 0,1–0,25 · Dårlig: over 0,25.

Terskelverdiene bekreftes av Google Search Central: LCP under 2,5 sekunder, INP under 200 millisekunder og CLS under 0,1. For at en side skal regnes som godkjent, må alle tre målene ligge i det grønne spennet samtidig – det holder ikke at to av tre er bra.

INP erstattet First Input Delay (FID) som offisielt mål 12. mars 2024. FID målte bare forsinkelsen på den første interaksjonen, mens INP speiler responsiviteten gjennom hele besøket – et ærligere mål på hvordan en side faktisk føles å bruke. FID er siden faset helt ut av Googles verktøy.

Er Core Web Vitals viktig for SEO?

Ja, men ikke på den måten mange tror. Core Web Vitals er et bekreftet rangeringssignal som inngår i Googles bredere rammeverk for Page Experience. Google selv formulerer det i sin Page Experience-dokumentasjon som at gode verdier «aligns with what our core ranking systems seek to reward». Samtidig er det et relativt svakt signal sammenlignet med relevans, innholdskvalitet og lenker.

Den riktige mentale modellen er å se Core Web Vitals som en tiebreaker, ikke en rakett. Mellom to sider med likeverdig innhold kan bedre verdier avgjøre – men ingen ytelsespoeng i verden løfter en side som ikke svarer på søkeintensjonen. Den vanligste misforståelsen er at en perfekt score i PageSpeed Insights automatisk gir høyere rangering. Slik fungerer det ikke: scoren er et diagnoseverktøy, ikke en rangeringsfaktor i seg selv.

Det sterkeste forretningsargumentet handler derfor sjelden om rangering, men om konvertering. En side som laster sakte, svarer tregt på klikk eller hopper rundt under lasting, øker frafallet og senker konverteringsraten – uansett hvor du rangerer. Teknisk ytelse stables oppå sterkt innhold og et tydelig tilbud; den erstatter dem ikke.

Vil du se hvor ytelse passer inn blant de andre faktorene som avgjør synlighet, har vi gått gjennom de vanligste årsakene i Synlighet på nett: 10 grunner til at nettsiden ikke rangerer.

Slik tester du Core Web Vitals – feltdata vs labdata

Det finnes to typer Core Web Vitals-data, og forskjellen er avgjørende. Feltdata (Real User Monitoring) kommer fra Chrome User Experience Report (CrUX) og speiler det de faktiske besøkende opplever på sine enheter og nett. Labdata kommer fra en simulert test i et kontrollert miljø. Googles rangering bygger utelukkende på feltdata – labdata er til for feilsøking.

• Google PageSpeed Insights (pagespeed.web.dev) – viser både feltdata fra CrUX og en labtest via Lighthouse, med konkrete forslag til tiltak. Startpunktet for de fleste.
• Search Console – Core Web Vitals-rapporten – grupperer alle sidene på nettstedet etter status og flagger dem med dårlige verdier. Best for å finne problemer i stor skala på et helt nettsted.
• Chrome DevTools – Lighthouse – lokal labanalyse med dyptgående tekniske forslag til tiltak. Best for å feilsøke én enkelt side.
• CrUX og RUM-verktøy – for den som vil følge feltdata over tid og segmentere på enhet, land og sidetype.

Den vanligste fellen er å jage 100 av 100 i Lighthouse på sin egen raske maskin med fiber. Labscoren kan være grønn mens feltdataene er røde, fordi de reelle besøkende sitter på mobil og dårligere nett. Stol på feltdataene når de finnes – labdataene viser bare hvor problemet kan ligge.

Hvor ofte oppdateres Core Web Vitals-verdiene?

Feltdataene Google bruker, bygger på et rullerende 28-dagersvindu i CrUX. Det betyr at en forbedring du gjør i dag, ikke vises i feltdataene med en gang – det kan ta opptil fire uker før den nye opplevelsen har fått fullt gjennomslag, fordi eldre og dårligere datapunkter gradvis faller ut av vinduet. Labverktøy som Lighthouse viser derimot effekten umiddelbart. Regn altså med etterslep når du følger opp en optimalisering i feltdataene, og bekreft i lab at endringen faktisk har hatt effekt.

Core Web Vitals er ikke lenger bare Chrome

Historisk har Core Web Vitals i praksis vært et Chrome-fenomen: feltdataene kom fra Chrome, og de underliggende API-ene fantes bare der. Det endret seg mot slutten av 2025. Ifølge web.dev ble LCP og INP «Baseline Newly available» 12. desember 2025, etter at Safari 26.2 og Firefox implementerte de underliggende API-ene (LargestContentfulPaint API og Event Timing API) som en del av initiativet Interop 2025.

I praksis betyr det at to av de tre målene nå kan måles i alle større nettlesere, ikke bare Chrome. CLS måles fortsatt primært via Chrome og CrUX-data, og Googles egen rangering bygger fortsatt på Chromes feltdata. Men for deg som bygger nettsteder, er milepælen et tegn på at ytelsesmåling standardiseres – Core Web Vitals har gått fra et Google-spesifikt signal til en bransjestandard for ytelse på nett.

Core Web Vitals-optimalisering: slik forbedrer du hvert mål

Optimalisering av Core Web Vitals handler nesten alltid om de samme grunnprinsippene: send færre og mindre ressurser, prioriter det som vises først, og reserver plass til det som laster sent. Her er tiltakene som gir mest effekt per mål.

Optimaliser LCP (lasting)

• Komprimer hero-bildet, og server det i et moderne format (WebP eller AVIF) og i riktig størrelse for visningsflaten.
• Gi det viktigste elementet høy lasteprioritet (fetchpriority), og forhåndslast kritiske ressurser (preload).
• Server innholdet via et CDN, og kort ned serverens svartid (TTFB).
• Sørg for at LCP-elementet ikke blokkeres av renderblokkerende CSS eller JavaScript.
• Last webfonter med font-display swap, slik at teksten vises med en gang.

Optimaliser INP (responsivitet)

• Del opp lange JavaScript-oppgaver (long tasks) i mindre biter, slik at nettleserens main thread ikke blokkeres.
• Utsett eller fjern tunge tredjepartsskript – analyse, chatwidgeter og A/B-testverktøy er vanlige syndere.
• Reduser mengden JavaScript som kjøres ved interaksjon, og unngå unødvendige omtegninger.
• Legg arbeid som ikke må skje umiddelbart, på requestIdleCallback eller en web worker.

Optimaliser CLS (stabilitet)

• Angi alltid bredde og høyde (eller aspect-ratio) på bilder, video og innebygd innhold.
• Reserver plass til annonser, bannere og dynamisk innhold før det lastes inn.
• Velg en fallback-font med lignende dimensjoner som webfonten, for å unngå layouthopp når fonten byttes.
• Legg nytt innhold under, ikke over, det brukeren allerede ser på.

For dypere tekniske guider per mål er web.dev førstehåndskilden: Optimize LCP, Optimize INP og Optimize CLS.

Total Blocking Time (TBT) og koblingen til INP

Total Blocking Time (TBT) er et labbasert mål som måler den samlede tiden sidens main thread er blokkert mellom First Contentful Paint og Time to Interactive. TBT regnes som summen av blokkeringstiden for alle long tasks (oppgaver lengre enn 50 ms) i perioden. Fordi faktisk interaksjon er vanskelig å simulere i et labmiljø, bruker Lighthouse TBT som proxy for INP.

Høy TBT korrelerer sterkt med dårlig INP: forbedrer du TBT – for eksempel ved å dele opp tunge JavaScript-oppgaver eller utsette tredjepartsskript – forbedres som regel også INP i praksis. Ved siden av Core Web Vitals dukker det ofte opp tre støttemål i verktøyene som er verdt å forstå: TTFB (Time to First Byte), som måler serverens svartid og påvirker LCP; FCP (First Contentful Paint), som måler når det første innholdet tegnes opp; og TBT. De er ikke Core Web Vitals i seg selv, men de peker ut hvor et problem begynner.

Core Web Vitals i Webflow

Webflow gir et sterkt teknisk grunnlag fra start: globalt CDN, automatisk bildekomprimering med responsive bildestørrelser, ren semantisk markup og minifisert kode. Et godt bygget Webflow-nettsted klarer derfor ofte LCP og CLS bra uten ekstra arbeid. Men plattformen løser ikke alt automatisk – de fleste problemene oppstår i hvordan nettstedet bygges, ikke i Webflow selv.

• LCP – store, ukomprimerte hero-bilder og tunge bakgrunnsvideoer er den vanligste årsaken. Last opp bilder i riktig størrelse, og la Webflow servere dem responsivt.
• INP – dette er Webflows mest sårbare punkt. Mange animasjoner via Webflow Interactions eller GSAP, kombinert med tredjepartsinnhold (chat, booking, analyse), kan blokkere main thread og forverre INP. Vær sparsom med samtidige animasjoner, og last tunge skript sent.
• CLS – oppstår oftest av webfonter som byttes ut, innebygd innhold uten reservert høyde eller innhold som lastes inn sent. Sett eksplisitte dimensjoner på innebygd innhold.

Tommelfingerregelen: et Webflow-nettsted uten tunge tredjepartsintegrasjoner klarer Core Web Vitals uten aktiv optimalisering, mens et komplekst nettsted med mange animasjoner, chatwidgeter og markedsføringsskript krever det samme gjennomtenkte ytelsesarbeidet som en hvilken som helst annen plattform.

Core Web Vitals med et headless CMS

Et kodet nettsted med et headless CMS – for eksempel en frontend i Next.js eller Astro mot Sanity, Contentful eller Storyblok – gir maksimal kontroll over ytelsen. Du bestemmer selv nøyaktig hva som sendes til nettleseren. Baksiden er at ansvaret også flyttes til utvikleren: ingenting optimaliseres automatisk.

• Sterkt for LCP – statisk generering (SSG) og rendering på server eller edge gjør at HTML kan leveres lynraskt, ofte fra et CDN nær brukeren. Innebygd bildeoptimalisering håndterer format og størrelse automatisk.
• Risiko for INP – den store ytelsestrusselen i moderne rammeverk er for mye JavaScript. Tung hydrering og store klientbundler kan blokkere main thread og gi dårlig INP til tross for rask lasting. Astros islands-arkitektur, som sender null JavaScript som standard, er et av de sterkeste valgene for lav INP.
• Kontroll over CLS – med egen kode er det enkelt å reservere plass til bilder og dynamisk innhold, men det krever at utvikleren faktisk gjør det.

Vi har skrevet mer om hvordan en slik stack bygges i praksis i AI-nettside med Claude Code og Next.js.

Core Web Vitals i WordPress

WordPress kan absolutt nå grønne Core Web Vitals – men det er plattformen som krever mest aktivt arbeid for å komme dit, og mest vedlikehold for å bli der. I motsetning til Webflow optimaliseres nesten ingenting automatisk; resultatet avhenger helt av tema, plugins, hosting og hvordan nettstedet er bygget.

De vanligste årsakene til dårlige verdier i WordPress:

• Page builders – Elementor, Divi og WPBakery legger på lag med ekstra HTML, CSS og JavaScript som tynger både LCP og INP.
• For mange plugins – hver plugin kan laste egne skript og stiler på alle sider. Tjue plugins blir fort hundrevis av kilobyte unødvendig kode.
• jQuery og tredjepartsskript – mange temaer og plugins lener seg på jQuery, som blokkerer main thread og trekker ned INP.
• Billig delt hosting – en svak server gir høy TTFB, som direkte forverrer LCP.

Dette kreves for at et WordPress-nettsted skal yte godt:

• Rask hosting (gjerne en spesialisert WordPress-host) og et CDN.
• En cache- og optimaliseringsplugin som WP Rocket eller LiteSpeed Cache for caching, kritisk CSS og utsatt JavaScript.
• Bildeoptimalisering til WebP eller AVIF via plugin – det skjer ikke automatisk.
• Et lettvektstema (for eksempel GeneratePress eller Kadence) eller et blokktema i stedet for en tung page builder.
• Disiplin med antall plugins, og en plan for å teste om hver oppdatering påvirker ytelsen.

Konklusjonen: WordPress kan bli raskt, men det forutsetter riktige valg fra start og løpende tilsyn. Derfor reserverer vi WordPress for nisjetilfeller der plugin-økosystemet eller en etablert redaksjonell vane veier tyngre enn den tekniske enkelheten – og velger Webflow eller en headless-stack når ytelsen skal sitte uten stadig vedlikehold.

Webflow, headless eller WordPress – hva kreves for gode Core Web Vitals?

Alle tre plattformene kan nå grønne verdier. Forskjellen ligger i hvor mye arbeid det krever å komme dit – og å bli der. Tabellen nedenfor oppsummerer hvor hver plattform står: Core Web Vitals uten optimalisering, arbeidsinnsats, kontroll over ytelsen og vedlikehold.

Når trenger du en Core Web Vitals-konsulent?

De fleste Core Web Vitals-problemer kan løses på egen hånd med verktøyene over og litt tålmodighet. Men noen ganger står man fast – og da koster tiden mer enn hjelpen. En Core Web Vitals-konsulent er verdt pengene når:

• Search Console flagger mange URL-er, og du ikke finner mønsteret bak problemene.
• Nettstedet har røde feltdata til tross for grønne labscorer, og du ikke vet hvorfor.
• INP er dårlig på grunn av skript og animasjoner du ikke tør å røre selv.
• Ytelsen er en del av en større migrering, redesign eller plattformbytte.

Sterk ytelse er sjelden et isolert teknisk problem – den sitter i kombinasjonen av teknologi, design og innhold. Et genuint fundament av teknisk SEO avgjør om optimaliseringen holder over tid eller bare gir en midlertidig grønn hake. Det er den kombinasjonen vi jobber med i SEOS Design, uansett om nettstedet ligger i Webflow eller er bygget headless.

Vil du ha hjelp til å tolke eller forbedre Core Web Vitals? Se tjenestene våre eller ta kontakt for en gjennomgang.