Core Web Vitals: norsk guide til LCP, INP og CLS

Core Web Vitals: norsk guide til LCP, INP og CLS#

Core Web Vitals er tre målinger av hvordan en nettside oppleves for virkelige brukere: hvor raskt hovedinnholdet vises, hvor raskt siden reagerer på interaksjon, og hvor stabil layouten er. Målingene heter Largest Contentful Paint (LCP), Interaction to Next Paint (INP) og Cumulative Layout Shift (CLS).

Målet er ikke å jage en grønn «100/100»-sirkel i en enkelt laboratorietest. Målet er at de fleste virkelige besøkende får en rask, responsiv og stabil opplevelse på de sidene som betyr mest.

Kort forklart: tersklene for gode Core Web Vitals#

Google vurderer normalt felldata ved 75-persentilen, fordelt på mobil og datamaskin. Det betyr at minst 75 prosent av de målte besøkene bør være innenfor den gode terskelen.

|---|---|---:|---:|---:|

| LCP | Når det største synlige innholdselementet vises | ≤ 2,5 s | > 2,5–4,0 s | > 4,0 s |

| INP | Forsinkelsen fra interaksjon til neste visuelle oppdatering | ≤ 200 ms | > 200–500 ms | > 500 ms |

| CLS | Uventede layoutforskyvninger gjennom sidens levetid | ≤ 0,1 | > 0,1–0,25 | > 0,25 |

Én god måling kompenserer ikke for en dårlig. En sidegruppe består Core Web Vitals når alle tre ligger i området «god» i de tilgjengelige feltene.

Felldata og laboratoriedata er ikke det samme#

Dette skillet forklarer mange tilsynelatende motstridende rapporter.

Felldata kommer fra faktiske Chrome-brukere som har samtykket til rapportering og oppfyller kriteriene for Chrome User Experience Report (CrUX). Dataene samles over en rullerende periode på omtrent 28 dager. De inkluderer ulike enheter, nettverk, steder og bruksmønstre.

Laboratoriedata er en kontrollert simulering, for eksempel Lighthouse-delen av PageSpeed Insights. Den er verdifull til debugging fordi testen er repeterbar og viser konkrete diagnostiske funn. Den representerer likevel ikke alle brukerne dine.

Bruk felldata til å avgjøre om et reelt problem finnes og om det er løst over tid. Bruk laboratoriedata og utviklerverktøy til å finne årsaken.

Slik leser du PageSpeed Insights riktig#

Start øverst i rapporten med vurderingen for virkelige brukere. Bytt mellom mobil og datamaskin. Kontroller om rapporten viser data for den konkrete URL-en eller bare for hele opprinnelsen; en ny eller lite besøkt side kan mangle egne data.

Gå deretter til diagnostikken:

Finn hvilken Core Web Vital som er svak.
Identifiser det faktiske elementet eller interaksjonen, ikke bare anbefalingens navn.
Test en representativ side fra hver mal: forside, artikkel, tjenesteside, kategori og applikasjon.
Gjenta laboratorietesten noen ganger fordi nettverk og CPU kan variere.
Kontroller effekten i produksjon og vent på at feltdatavinduet oppdateres.

Search Console grupperer ofte lignende URL-er med samme problem. Rett derfor årsaken i sidemalen før du optimaliserer hundre sider manuelt.

LCP: når hovedinnholdet blir synlig#

Largest Contentful Paint måler tiden frem til nettleseren har malt det største kvalifiserte innholdselementet i den synlige delen av siden. Det er ofte et hero-bilde, et stort tekstfelt, en plakatramme for video eller et bakgrunnsbilde.

En treg LCP består vanligvis av fire deler:

tid til første byte fra serveren
forsinkelse før nettleseren oppdager ressursen
tiden det tar å laste ressursen
forsinkelse før elementet kan rendres

Du bør finne hvilken del som dominerer før du velger tiltak.

Slik forbedrer du LCP#

1. Gjør serverresponsen raskere

bruk fullside- eller datacache der innholdet tillater det
fjern unødvendige databasekall og synkront serverarbeid
aktiver komprimering og effektiv HTTP-cache
bruk CDN for statiske ressurser og geografisk distribusjon ved behov
unngå flere omdirigeringer før den endelige siden

En rask frontend kan ikke skjule at HTML-dokumentet bruker flere sekunder på å komme fra serveren.

2. La nettleseren oppdage LCP-ressursen tidlig

Et viktig hero-bilde bør finnes i HTML-en, ikke først oppdages etter et JavaScript-kall. Ikke bruk lazy loading på bildet som sannsynligvis er LCP. Bruk eventuelt høy hentingsprioritet på det ene kritiske bildet, men ikke på alle bilder.

For SPA-er og JavaScript-tunge nettsteder kan serverrendret eller statisk generert hovedinnhold redusere både oppdagelsesforsinkelse og risikoen for at søkeroboter ser en tom side.

3. Optimaliser bildet

lever riktig bildebredde med responsive kilder
bruk moderne formater som WebP eller AVIF når de faktisk gir lavere filstørrelse
komprimer uten synlig kvalitetstap
angi bredde og høyde
ikke last et stort skrivebordsbilde på en liten mobilskjerm

Format alene er ingen løsning. Et 3000 piksler bredt AVIF-bilde kan fortsatt være unødvendig tungt.

4. Fjern renderingsblokkering

Lever kritiske stiler tidlig, del opp store CSS-filer og utsett skript som ikke trengs for første visning. Vær forsiktig med tredjeparts tagger, fonter og widgets som legger arbeid foran hovedinnholdet.

INP: hvor raskt siden svarer#

Interaction to Next Paint måler ventetiden for brukerinteraksjoner gjennom hele besøket, og rapporterer en verdi nær den tregeste interaksjonen. Klikk, trykk og tastaturbruk kan inngå. Scroll og zoom måles ikke direkte som INP-interaksjoner.

En interaksjon består grovt av:

input-forsinkelse mens nettleseren er opptatt
tiden event-handlerne bruker
presentasjonsforsinkelse før neste bilde vises

Det er derfor ikke nok at en knapp «fungerer». Brukeren må også få rask visuell tilbakemelding.

Slik forbedrer du INP#

Del opp lange oppgaver

Store JavaScript-oppgaver blokkerer hovedtråden. Del arbeid i mindre enheter og gi nettleseren mulighet til å behandle input og tegne mellom dem. Fjern kode som ikke brukes på den aktuelle ruten, og last tunge funksjoner først når de trengs.

Gjør event-handleren liten

Ikke utfør stor filtrering, parsing eller DOM-manipulasjon direkte i et klikk. Oppdater det brukeren må se nå, og utsett sekundært arbeid. For komplekse beregninger kan en Web Worker være riktig løsning.

Begrens DOM-arbeid og layout thrashing

Mange vekslende lesninger og endringer av layout kan tvinge nettleseren til gjentatte beregninger. Samle DOM-lesninger og -skrivinger, reduser antall elementer i svært store grensesnitt og virtualiser lange lister.

Kontroller tredjepartskode

Chat, analyse, annonser, heatmaps og A/B-testing deler hovedtråden med din egen kode. Mål kostnaden per leverandør. Last bare det som gir dokumentert verdi, og last det på riktig tidspunkt.

Gi umiddelbar tilbakemelding

Vis en trykket tilstand, spinner eller optimistisk oppdatering når en handling tar tid. Dette reduserer ikke alltid selve INP-verdien, men gjør grensesnittet forståelig og hindrer gjentatte klikk.

CLS: unngå at siden hopper#

Cumulative Layout Shift summerer uventede layoutforskyvninger som skjer uten en nylig brukerinteraksjon. Et bilde som plutselig skyver teksten ned, en font som endrer tekstbredden, eller et banner som settes inn over innholdet kan gi høy CLS.

Slik forbedrer du CLS#

angi bredde og høyde eller et fast sideforhold for bilder og video
reserver plass til annonser, samtykkebokser og dynamiske moduler
legg nye varsler og bannere i et reservert område eller som overlay
unngå animasjoner som endrer layout; bruk transform der det passer
preload kritiske fonter og velg fallback-metrikk som ligner sluttfonten
kontroller komponenter som fylles med data etter første rendering

Noen forskyvninger er forventet etter en brukerhandling, for eksempel når en person åpner en trekkspillmeny. Audit-verktøyet bør derfor vise hvilke elementer som faktisk flyttet seg og om forskyvningen var uventet.

Core Web Vitals i React og moderne JavaScript-apper#

Store JavaScript-pakker kan påvirke både LCP og INP. Start med rutebasert kodeoppdeling: en bloggside trenger ikke laste PDF-generator, diagrammer eller admin-funksjoner. Hold første rute liten, og last funksjoner når brukeren navigerer til dem.

Pass også på:

hydreringsarbeid som blokkerer interaksjon
globale state-oppdateringer som rendrer store deler av appen på nytt
effekt-hooks som starter unødvendige nettverkskall
bilder uten dimensjoner i gjenbrukbare komponenter
tredjepartsskript som injiseres på alle ruter

For offentlig innhold kan statisk generering eller serverrendering gi både en raskere førstegangsvisning og mer robust HTML for søk. Interaktive verktøy kan fortsatt lastes på klienten der det gir mening. Les mer i guiden til teknisk SEO.

Prioriter ytelsesarbeidet etter verdi#

Ikke start med den enkleste advarselen. Kombiner omfang, brukerdata og forretningsverdi:

| Prioritet | Situasjon | Handling |

|---|---|---|

| Høy | Viktig sidemal har dårlig felldata og mye trafikk | Rett malårsaken først |

| Høy | Interaksjon stopper skjema eller kjøp | Profilér og reduser blokkerende arbeid |

| Middels | Felldata må forbedres, men siden har begrenset trafikk | Planlegg malforbedring |

| Lav | Kun én laboratorietest viser et lite avvik | Bekreft problemet før utviklingsarbeid |

En komplett SEO-audit bør dokumentere berørte URL-grupper, målingen før endring, konkret teknisk årsak og hvordan effekten skal kontrolleres.

Sjekkliste før du markerer problemet som løst#

Testet du både mobil og datamaskin?
Fant du URL- eller opprinnelsesdata i stedet for å anta?
Identifiserte du faktisk LCP-element, treg interaksjon eller flyttende element?
Testet du flere sider fra samme mal?
Bekreftet du at endringen ikke skapte tilgjengelighets- eller funksjonsfeil?
Målte du produksjonsversjonen etter utrulling?
Ventet du til nye felldata var tilgjengelige før du konkluderte?

Vanlige misforståelser#

«PageSpeed 100 gir topprangering»

Nei. Core Web Vitals og andre siderfaringer inngår i et større bilde, mens relevans og nyttig innhold fortsatt er avgjørende. En laboratoriepoengsum på 100 er heller ikke det samme som gode felldata for alle brukere.

«En grønn test betyr at alle sider er raske»

Nei. Resultatet gjelder URL-en eller datagruppen du testet. Andre maler kan ha andre bilder, skript, annonser og bruksmønstre.

«Lazy loading gjør alle bilder raskere»

Lazy loading er nyttig for bilder utenfor skjermen. På LCP-bildet kan det forsinke oppdagelse og gjøre førstegangsvisningen tregere.

«Et CDN løser INP»

Et CDN kan redusere nettverksventing, men INP-problemer skyldes ofte arbeid på hovedtråden etter at ressursene er lastet. Kode, rendering og tredjepartsskript må profileres.

Offisielle ressurser#

Oppsummering#

Forbedre Core Web Vitals som et brukerproblem, ikke som et poengspill. Bruk felldata til å velge riktig sidegruppe, laboratorietester til å finne årsaken og produksjonsmåling til å bekrefte effekten. Start med LCP-ressurser som oppdages sent, lange JavaScript-oppgaver som rammer INP, og elementer uten reservert plass som skaper CLS.

SEO kunnskapssenter

Bygg videre på SEO-strategien din

Disse guidene dekker de viktigste delene av søkemotoroptimalisering for norske virksomheter. Velg neste steg ut fra hva som begrenser synligheten din nå.

Google Search Console

Gjør visninger, klikk og posisjoner om til prioriterte tiltak.

Les guiden

Søkemotoroptimalisering: komplett guide

Start med strategi, søkeintensjon, innhold og måling.

Les guiden

Teknisk SEO

Sjekk indeksering, ytelse, strukturert data og feil.

Les guiden

Komplett SEO-audit

Prioriter feil i indeksering, innhold, lenker, ytelse og måling.

Les guiden

Lokal SEO i Norge

Arbeid med synlighet i kart og lokale søkeresultater.

Les guiden

SEO-analyse

Kontroller nettsiden og bruk observasjonene som grunnlag for prioritering.

Les guiden

Maaz Surchy

Grunnlegger av SEOGiant og ansvarlig for denne artikkelen. Se Om oss-siden for bakgrunn og kontaktinformasjon.

Core Web Vitals: norsk guide til LCP, INP og CLS