Det viktigste i korte trekk
- Tre terskelverdier: En side regnes som god av Google når LCP ≤ 2,5 s, INP ≤ 200 ms og CLS ≤ 0,1 (web.dev: LCP(2024).
- INP erstatter FID: Siden 12. mars 2024 erstatter Interaction to Next Paint den gamle FID-verdien som offisiell Core Web Vital-metrikk (web.dev: Lansering av INP(2024).
- Bare 43 prosent av mobile sider består: Ifølge HTTP Archive Web Almanac 2024 oppfyller kun 43 prosent av mobile origins alle tre vitals med INP-metrikken; på desktop er det 54 prosent (HTTP Archive: Almanakk 2024 – Ytelse(2024).
- Mobile-first lønner seg: Mobile origins gjør det betydelig dårligere enn desktop. Den som måler eget oppsett ærlig på 75. persentil av mobile feltdata, ser optimaliseringsrommet direkte i Search Console-rapporter for Core Web Vitals.
Core Web Vitals-optimalisering handler ikke om å file på mikrosekunder. Det handler om å treffe tre klare terskelverdier: LCP under 2,5 sekunder, INP under 200 millisekunder, CLS under 0,1. Ifølge HTTP Archive Web Almanac 2024 oppfyller kun 43 prosent av origins dette på mobile enheter, og 54 prosent på desktop. Den som måler verdiene ryddig og prioriterer riktig, henter ut en målbar fordel for både rangering og konvertering.
Hva er Core Web Vitals i 2026 egentlig?
Core Web Vitals er tre brukersentrerte ytelsesmetrikker som Google bruker til å måle den reelle opplevelsen på en side. Per 2026 er det LCP, INP og CLS. INP har siden 12. mars 2024 offisielt erstattet den eldre FID-verdien. Dataene stammer fra Chrome User Experience Report, altså fra reelle nettlesersesjoner, ikke fra laboratorieverdier.
Viktig: Google vurderer 75. persentil. Det betyr at tre av fire av dine besøkende må oppleve terskelverdiene, ikke bare gjennomsnittet. Denne definisjonen står slik i de offisielle web.dev-artiklene om LCP. Det forklarer hvorfor gode laboratorieverdier likevel kan gi en rød PageSpeed-rapport.
Vitals er dessuten en del av Googles mer omfattende Page Experience-signal. De virker altså ikke isolert. Sikker HTTPS, mobilvennlighet og påtrengende interstitials teller med.
Hvilke tre nøkkeltall du må kjenne
Tre verdier, tre spørsmål.
LCP, kort for Largest Contentful Paint, svarer på: Når ser brukeren hovedinnholdet? Som regel er det et hero-bilde, en overskrift eller et banner. Målverdi: 2,5 sekunder eller raskere.
INP, Interaction to Next Paint, måler reaksjonstiden gjennom hele økten. Klikk, tapp, tastaturinntasting. Maksmål: 200 millisekunder.
CLS, Cumulative Layout Shift, sjekker visuell stabilitet. Hopper knappen bort under lasting? Forskyves teksten av annonser som lastes etter? Verdier ≤ 0,1 aksepteres, dokumentert på web.dev: CLS.
Hvordan måler jeg Core Web Vitals riktig?
Den mest pålitelige kilden er feltdata fra Chrome User Experience Report (CrUX). De speiler hva ekte brukere har opplevd de siste 28 dagene, vurdert på 75. persentil. Laboratorieverktøy som Lighthouse simulerer derimot én enkelt enhet under standardvilkår. Begge hører sammen, men avgjørende for Google er CrUX-feltdataene inklusive den dokumenterte 28-dagers metodikken.
I mine performance-revisjoner hos Evelan ser jeg ofte den samme feilen: Team optimaliserer til Lighthouse lyser grønt, og undrer seg over at Google Search Console fortsatt melder "forbedring nødvendig". Grunnen er 75. persentil over reelle enheter, ikke én enkelt test på en rask bærbar.
Hvilke verktøy bruker jeg konkret?
Et pragmatisk verktøyutvalg for SMB:
- PageSpeed Insights for rask diagnose. Leverer feltdata og laboratoriedata i samme visning.
- Google Search Console, seksjonen "Core Web Vitals". Her ser du aggregerte URL-grupper med status "dårlig", "forbedring nødvendig" eller "god".
- Lighthouse eller DevTools Performance-panelet i Chrome for dybdeanalyse av en enkelt side.
- CrUX Dashboard eller CrUX-API for trendforløp over flere måneder.
Det viktige er at du ikke veksler stadig mellom verktøy. Velg én kilde som "single source of truth", som regel Google Search Console, og bruk Lighthouse kun til å teste konkrete hypoteser. Vil du gå dypere inn i hvordan hastighet påvirker konvertering, finner du i artikkelen Lynrask nettside gjør besøkende til kunder flere tall fra vår praksis.
Hvilke verdier er virkelig gode i 2026?
Den offisielle terskeltabellen har ikke endret seg siden INP-lanseringen i mars 2024. Google skiller mellom tre vurderingsnivåer per metrikk og sjekker 75. persentil separat for mobil og desktop. Kilde: web.dev/articles/lcp, web.dev/articles/inp, web.dev/articles/cls.
| Metrikk | God | Forbedring nødvendig | Dårlig |
|---|---|---|---|
| LCP | ≤ 2,5 s | ≤ 4,0 s | > 4,0 s |
| INP | ≤ 200 ms | ≤ 500 ms | > 500 ms |
| CLS | ≤ 0,1 | ≤ 0,25 | > 0,25 |
| Metrikk | God | Forbedring nødvendig | Dårlig |
|---|---|---|---|
| LCP | ≤ 2,5 s | ≤ 4,0 s | > 4,0 s |
| INP | ≤ 200 ms | ≤ 500 ms | > 500 ms |
| CLS | ≤ 0,1 | ≤ 0,25 | > 0,25 |
En side må ligge på "god" i alle tre verdier for at Google skal markere URL-gruppen som "god" totalt. Det gjør disiplinen krevende. Ifølge HTTP Archive Web Almanac 2024 oppfyller bare 43 prosent av mobile origins alle tre verdier med INP-metrikken, mens det på desktop er 54 prosent.
Det mange overser: Verdien "forbedring nødvendig" er ikke et nøytralt mellomsjikt. Google behandler den som en advarsel i Search Console-rapportene. Den som havner varig i denne sonen, taper terreng i konkurranseutsatte søkeord mot raskere optimaliserte konkurrenter. I praksis betyr det: Sikt konsekvent mot det grønne feltet, ikke det gule.
Hvorfor belønner Google raske sider i det hele tatt?
Google vil få brukeren raskt til resultatet. En side som bruker tre sekunder, mister merkbart klikk og konverteringer. De offisielle PageSpeed Insights-dokumentene viser hvor tett lastetid, fluktrate og synlighet henger sammen. En treg side mister besøkende ikke først etter sekunder, men allerede i de første brøkdelene. Det endrer søkeinntektene direkte.
Av dette følger en dobbel effekt. For det første går Core Web Vitals inn i Page Experience-signalet, som er et dokumentert rangeringshint. For det andre påvirker raske sider tid på side, fluktrate og konvertering. Begge effektene forsterker hverandre, men er målbare uavhengig av hverandre.
Hva betyr det for SMB-nettsteder?
Fra over 60 SMB-prosjekter vet jeg: Den som kutter LCP med ett sekund, ser som regel umiddelbart en bedre klikkrate fra Google Discover og Mobile Search. Effektene er ikke spektakulære hver for seg, men summerer seg over kvartaler. Særlig B2B-sider med lang salgssyklus tjener på det, fordi gjenbesøkende oppfatter den raskere siden som "mer verdifull".
I tillegg kommer et aspekt mange undervurderer. Ytelse er en stedfortrederstørrelse for grundighet. En side som laster med hero-bilde, ryddig typografi og uten layout-hopp, formidler kompetanse før det første ordet er lest. Det slår særlig sterkt ut i B2B, fordi avgjørelsen sjelden faller ved første besøk.
Hva er de vanligste årsakene til dårlige Core Web Vitals?
Tre årsaker dukker stadig opp øverst i mine revisjoner: uoptimaliserte bilder, JavaScript-overhead og en treg server. Den som tar tak i disse tre punktene, dekker i typiske tilfeller de største flaskehalsene før man begir seg ut på detaljtuning. De offisielle optimaliseringsguidene Optimaliser LCP og Optimaliser INP på web.dev nevner de samme hovedtemaene: Time to First Byte, render-blokkerende skript, store bilder og lange main-thread-oppgaver.
Hvordan slår bilder og medier ut?
Uoptimaliserte hero-bilder er den vanligste LCP-drapsmannen. En 3 MB JPEG-fil rett fra speilreflekskameraet blokkerer renderingen målbart. Løsning: moderne formater som AVIF eller WebP, korrekte srcset-anvisninger, lazy-loading for bilder under folden og fetchpriority-attributtet satt til "high" for LCP-elementet.
Også video-embeds gjør utslag. En innebygd YouTube-spiller laster flere hundre kilobyte JavaScript før noe synlig skjer. En lite-embed-variant med klikk-for-å-laste er som regel det bedre valget.
Hvor mye skade gjør skript og plugins?
JavaScript er den største faktoren for INP. Hvert ubrukt tracking-skript, hver chat-widget-loader, hver A/B-test-snutt blokkerer main-thread. Følge: Klikk reagerer tregt, INP sklir over 200 millisekunder.
Konkrete grep: Reduser tredjepartsskript til et minimum, bygg samtykkelaget slik at ikke-essensielle skript først lastes etter samtykke, og last tunge komponenter etter via code-splitting. Vi måler effekten nesten alltid samme dag i Search Console-rapporten. Vil du gå teknisk dypere, finner du i sammenligningen Headless CMS vs. klassisk CMS en oversikt over hvorfor moderne arkitekturer gjør INP-kontrollen enklere.
Hvilken rolle spiller hosting?
En treg serverrespons slår direkte ut på LCP, fordi nettleseren ikke kan rendre noe før HTML-en kommer inn. En TTFB (Time to First Byte) over 800 millisekunder er et varselsignal. Vanlige årsaker: billig shared hosting, manglende CDN, ingen HTTP/2 eller HTTP/3, ingen serverside-cache. Her hjelper det ofte allerede å bytte til edge-hosting som Vercel, Netlify eller en dedikert skyserver med Cloudflare foran.
Hvorfor skiller Google mellom mobil og desktop?
Google vurderer begge enhetsklasser separat i Search Console-rapporten. Det er ingen detalj. Andelen mobile origins som består alle tre vitals er ifølge HTTP Archive Web Almanac 2024 betydelig lavere enn på desktop. Mobil maskinvare er tregere, mobilnett varierer, og berøringsinteraksjoner skal vurderes annerledes enn museklikk.
I praksis betyr det: En side kan lyse grønt på desktop og stryke på mobil. I min revisjonspraksis er det regelen, ikke unntaket. Den som tar CWV alvorlig, optimaliserer grunnleggende mobile-first og bruker desktop-verdiene kun som plausibilitetssjekk.
Hvilke enheter dekker CrUX-datasettet?
Chrome User Experience Report aggregerer anonymiserte feltdata fra Chrome-brukere som har samtykket til telemetri. Det deles opp etter form-factor (telefon, nettbrett, desktop) og tilkoblingshastighet. Selv om tilbudet ditt er primært B2B-orientert, bør du ikke ignorere mobil-verdiene. Research og førstekontakt skjer i økende grad på smarttelefonen, selv om den endelige konverteringen skjer på desktop.
Hvordan optimaliserer jeg Core Web Vitals trinn for trinn?
Det finnes en bevist rekkefølge jeg anbefaler enhver SMB: mål, prioriter, største spak først, deretter kontroller. Uten en baseline-måling optimaliserer du blindt. Uten prioritering forskyver du fokus. Uten kontroll vet du ikke om tiltaket faktisk virket. Som diagnoseverktøy bruker jeg standardmessig PageSpeed Insights som første anløp, fordi verktøyet samler feltdata og laboratoriedata i én visning.
Trinn 1: Ta opp baseline ærlig
Noter per sidetype (forside, produktside, kategori, blogg) gjeldende LCP-, INP- og CLS-verdi i 75. persentil. Kilde: Google Search Console eller CrUX Dashboard, ikke Lighthouse. Denne baselinen er ditt referansepunkt for hver endring.
Trinn 2: Fiks bilder og LCP-element
LCP-spaken er som regel størst og raskest å implementere. Komprimer hero-bildet, konverter til AVIF eller WebP, lever korrekte dimensjoner, sett fetchpriority-attributtet til "high", lever webfonter med font-display-strategien "swap". En uke arbeid, ofte ett sekunds gevinst på LCP.
Trinn 3: Reduser JavaScript-lasten
Inventarisér alle tredjepartsskript. Stryk alt som ikke er aktivt i bruk. Flytt tracking bak samtykkelaget. Lazy-last tunge komponenter som chat-widgets, kart eller faner. Forventet effekt: INP faller ofte med 100 til 300 millisekunder.
Trinn 4: Tett CLS-kildene
Reserver plass for bilder via width- og height-attributter, for annonser via CSS aspect-ratio og for innebygd innhold via en fast container. De fleste CLS-problemene forsvinner med tre til fem målrettede CSS-endringer.
Trinn 5: Etabler monitoring
Optimalisering uten monitoring fører pålitelig til tilbakefall. Plugins legges til, tracking ettermonteres, et nytt bilde sklir inn i hero. Allerede etter tre måneder er de gamle verdiene tilbake. Mitt forslag: Ukentlig titt i Core Web Vitals-rapporten i Google Search Console og månedlig sammenligning av CrUX-verdiene per sidetype.
For større nettsteder lønner det seg med automatisert Real User Monitoring (RUM), som fanger opp feltdata direkte fra din egen tag. Da har du en tidlig varslingsfunksjon som ikke først slår ut med 28 dagers forsinkelse. Vil du kombinere med solide SEO-grunnlag, finner du i artikkelen SEO-grunnlag: slik blir nettstedet ditt synlig den strategiske innrammingen.
Hvilke tiltak gir lite eller ingenting?
Nettopp fordi performance-rådgivning er et eget marked, sirkulerer det anbefalinger som i SMB-segmentet skaper mer arbeid enn effekt. Tre eksempler fra revisjoner som dukker opp regelmessig.
For det første: generiske "speed-plugins" for WordPress. De pakker ofte sammen mange funksjoner som hver for seg er fornuftige, men som i sum tilfører ekstra kompleksitet og konfliktpotensial. Uten klar diagnose av hvilken spak som faktisk drar, blir aktivisme en felle.
For det andre: HTTP/3 som eneste løsning. Moderne protokoll-tuning gir i snitt noen få millisekunder TTFB, og er altså ingen erstatning for strukturelle grep på bilder eller skript. Det er prikken over i-en, ikke fundamentet.
For det tredje: forhastede serveroppgraderinger. Den som klemmer på en svak plan, bør riktignok bytte. Men den som vil løse LCP-problemet med "større maskin" uten å røre hero-bilde og JavaScript, kjøper seg ofte bare noen få prosent forbedring for mye penger. Rekkefølgen forblir: sjekk innhold, optimaliser kode, deretter skaler infrastruktur.
Fra Evelan i praksis
Et nordtysk feriested ved Østersjøen kom til oss med klassiske symptomer: tunge galleribilder rett fra speilrefleksen, en WordPress-builder med åtte aktive plugins, et bookings-widget som lastet via iframe allerede i headeren. LCP-verdien i Google Search Console lå stabilt over 4 sekunder på mobil, CLS på 0,28. Følgen: sterkt svingende konverteringsrate til tross for voksende organisk rekkevidde.
Vi flyttet stacken til et headless-oppsett, konverterte bildene til AVIF og leverte dem med korrekte srcset-attributter, la bookings-widgeten bak en klikk-trigger og fjernet ikke-essensielle plugins. Etter tre uker lå LCP i 75. persentil på 1,9 sekunder, CLS på 0,04. Ingen ny relansering nødvendig, bare en målrettet performance-sprint på eksisterende innhold.
Ofte stilte spørsmål
Google vurderer en side på 75. persentil. Som "god" gjelder LCP under 2,5 sekunder, INP under 200 millisekunder og CLS under 0,1. Verdiene er dokumentert i de offisielle web.dev-artiklene og har ikke endret seg siden INP-lanseringen i mars 2024. En side må treffe alle tre terskler for å regnes som "god" totalt sett.
Relaterte Evelan-artikler
- Lynrask nettside gjør besøkende til kunder
- SEO-grunnlag: slik blir nettstedet ditt synlig
- Slik gjenkjenner du SEO-feil og optimaliserer nettstedet effektivt
- Headless CMS vs. klassisk CMS
Kilder
- Google web.dev: Largest Contentful Paint (LCP) (2024)
- Google web.dev: Interaksjon til neste maling (INP) (2024)
- Google web.dev: Kumulativ layoutforskyvning (CLS) (2024)
- Google web.dev: INP er nå en Core Web Vital (2024, blogg)
- Google Search Central: Brukeropplevelse på siden (2024)
- HTTP Archive: Web Almanac 2024, Performance-kapittel (2024)
- Chrome for Developers: CrUX Methodology (2024, dokumentasjon)
- Google: PageSpeed Insights (2024, verktøy)
