Hopp til innhold

Core Web Vitals

Fra LiavaagWiki
Sideversjon per 12. aug. 2026 kl. 17:39 av Administrator (diskusjon | bidrag) (Beskyttet «Core Web Vitals»: Side med mange besøkende ([Redigering=Tillat kun administratorer] (ubestemt) [Flytting=Tillat kun administratorer] (ubestemt)) [dypbeskyttelse])

Core Web Vitals og Googles søkeresultater

Core Web Vitals er spesifikke måleverdier utviklet av Google Search Central for å måle den faktiske brukeropplevelsen på nettsider. De fokuserer på tre hovedområder: lastehastighet, responstid og visuell stabilitet. Gode resultater bidrar til at et nettsted rangerer bedre i søkeresultatene. Etter at Core Web Vitals ble innført, får ikke Accelerated Mobile Pages (AMP) fortrinnsbehandling i søkeresultater. De fleste utviklere og utgivere dropper derfor AMP, og fokuserer istedenfor på å optimalisere vanlige nettsider etter at Core Web Vitals ble den primære ytelsesmetrikken (WPPoland, 2026).

Chrome User Experience Report (CrUX)

Core Web Vitals måler den faktiske brukeropplevelsen på nettsider. Tallene kommer fra ekte brukere ved at Chrome-nettleseren rapporterer anonymisert hvordan nettsider oppleves, og Google samler dataene i Chrome User Experience Report (CrUX) (Berntsen, 2026). Testene måles separat for mobilenheter og desktopper. Minst 75 prosent av sidevisningene må ligge innenfor grenseverdiene for å få bestått (Walton et al., 2025).

LCP, INP og CLS

For å forstår Core Web Vitals og Googles søkeresultater bedre, deler Google Search Central dette inn i tre hovedpunkter:

  • Largest Contentful Paint (LCP): Måler innlastingsytelse. For å sikre en god brukeropplevelse bør du tilstrebe at LCP inntreffer innen de første 2,5 sekundene etter at siden begynner å lastes inn.
  • Interaction To Next Paint (INP): Måler responsivitet. For å sikre en god brukeropplevelse bør du tilstrebe en INP på under 200 millisekunder.
  • Cumulative Layout Shift (CLS): Måler visuell stabilitet. For å sikre en god brukeropplevelse bør du tilstrebe en CLS-verdi på under 0,1.

Largest Contentful Paint (LCP)

Largest Contentful Paint (LCP) måler hvor raskt hovedinnholdet på nettsiden vises. LCP rapporterer gjengivelsestiden for det største bildet, den største tekstblokken eller den største videoen som er synlig i visningsområdet, målt fra tidspunktet da brukeren først navigerte til siden. Grensen for god opplevelse er 2,5 sekunder (Walton et al., 2025). LCP er en viktig og stabil Core Web Vitals-metrikk for å måle opplevd lastehastighet, ettersom den markerer tidspunktet i innlastingsforløpet da sidens hovedinnhold sannsynligvis er ferdig lastet. Rask LCP bidrar til å gi brukeren en følelse av at siden er nyttig.

Historisk sett har det vært en utfordring for webutviklere å måle hvor raskt hovedinnholdet på en nettside lastes inn og blir synlig for brukerne. Eldre målemetoder, som «load» eller «DOMContentLoaded», fungerer dårlig fordi de ikke nødvendigvis samsvarer med det brukeren faktisk ser på skjermen, akkurat som nyere, brukersentrerte ytelsesmål – som «First Contentful Paint» (FCP) – bare opp den aller tidligste fasen av innlastingen (Walton et al., 2025). Hvis en nettside viser en velkomstskjerm eller en lasteindikator, er ikke dette tidspunktet særlig relevant for brukeren. LCP måler når brukeren ser noe nyttig (Berntsen, 2026).

Interaction To Next Paint (INP)

Interaction To Next Paint (INP) er et måltall som vurderer en sides generelle responsivitet overfor brukerinteraksjoner, ved å måle forsinkelsen i alle interaksjoner via klikk, trykk og tastatur gjennom hele brukerbesøket. Bruksdata fra Chrome viser at 90 % av tiden en bruker tilbringer på en nettside, er etter at den er lastet inn (Wagner et al., 2025). Derfor er det viktig å måle responsiviteten nøye gjennom hele nettsidens livssyklus, og det er hva måleverdien INP vurderer. INP måler tiden fra brukeren gjør en interaksjon som å klikke, eller trykke på en knapp, åpne en meny eller skrive i et skjema, til skjermen reagerer (Berntsen, 2026). God responsivitet innebærer at en nettside reagerer raskt på interaksjoner. Når en side reagerer på en interaksjon, viser nettleseren visuell tilbakemelding i den neste rammen som tegnes. Slik visuell tilbakemelding forteller brukeren for eksempel om en vare du legger i en handlekurv faktisk blir lagt til, om en navigasjonsmeny på mobil har åpnet seg, om innholdet i et innloggingsskjema blir verifisert av serveren, og så videre (Wagner et al., 2025).

INP beregnes ved å registrere alle interaksjoner med en nettside. For de fleste nettsteder rapporteres interaksjonen med høyest forsinkelse (latens) som INP. For nettsider med svært mange interaksjoner, kan tilfeldige forsinkelser føre til én enkelt interaksjon med uvanlig høy latens, selv om nettsiden ellers er responsiv. For nettsider med mange interaksjoner, fjernes interaksjonen med høyest latens per 50. interaksjon, men siden de aller fleste sidevisninger innebærer færre enn 50 interaksjoner, er det som regel den tregeste interaksjonen som rapporteres. Deretter rapporteres 75-persentilen for alle sidevisninger på vanlig måte, noe som eliminerer ytterligere avvikende verdier, og gir et resultat som gjenspeiler opplevelsen til det store flertallet av brukere, skriver Google Search Central (Wagner et al., 2025).

Google Search Central skriver at for å sikre god responsivitet i brukeropplevelsen, er 75-persentilen av sideinnlastinger registrert i reelle brukermiljøer, fordelt på henholdsvis mobil og datamaskin (Wagner et al., 2025). Men hvis brukeren ikke klikket, trykket eller tastet noe på tastaturet, eller samhandlet ved hjelp av bevegelser som ikke måles, for eksempel rulling eller å holde musepekeren over elementer, eller at nettsiden ble besøkt av en bot, for eksempel en søkerobot, så kan INP måles med enkelte laboratorieverktøy. Siden brukeratferd kan være uforutsigbar og svært varierende, kan laboratorietesting kanskje ikke avdekke problematiske interaksjoner på samme måte som feltdata kan gjøre. Ved innlastingen av nettsiden uten å utføre interaksjoner, kan «Total Blocking Time» (TBT) fungere som en fornuftig indikator (proxy) for INP, men det er ikke en direkte erstatning for selve INP-målet (Wagner et al., 2025).

I mars 2024 erstattet INP den eldre FID, fordi INP fanger opp alle interaksjoner gjennom besøket, ikke bare den første (Berntsen, 2026). Moderne frontend-applikasjoner er svært interaktive, så responsivitet er svært viktig. En INP på 200 millisekunder eller lavere innebærer at siden har god responsivitet (Tawhare, 2026).

Cumulative Layout Shift (CLS)

Cumulative Layout Shift (CLS) er en viktig, brukersentrert metrikk for å måle visuell stabilitet, ettersom den bidrar til å kvantifisere hvor ofte brukere opplever uventede endringer i sideoppsettet (Mihajlija et al., 2023). En lav CLS bidrar til å sikre en god brukeropplevelse.

CLS måler forskyvning av layouten mens nettsiden lastes inn, som når en knapp flytter seg idet brukeren klikker, eller når tekst forskyver seg fordi bilder lastes inn sent (Tawhare, 2026). Uventede endringer i sideoppsettet kan forstyrre brukeropplevelsen på mange måter, alt fra at brukeren mister oversikten under lesing hvis teksten plutselig flytter på seg, til at vedkommende klikker på feil lenke eller knapp. I enkelte tilfeller kan dette få alvorlige konsekvenser. Uventet forskyvning av sideinnhold oppstår vanligvis når ressurser lastes inn asynkront, eller når DOM-elementer legges til dynamisk på siden før eksisterende innhold (Mihajlija et al., 2023). Årsaken til slike layoutforskyvninger kan være bilder eller videoer med ukjente dimensjoner, fonter som vises større eller mindre enn den opprinnelige reservefonten, eller tredjepartsannonser og -widgeter som endrer størrelse dynamisk (Tawhare, 2026). Forskjeller mellom hvordan et nettsted fungerer under utvikling, og hvordan brukerne opplever det, forverrer dette problemet (Mihajlija et al., 2023):

  • Personlig tilpasset innhold, eller innhold fra tredjeparter, oppfører seg ofte ulikt i utviklings- og produksjonsmiljøer.
  • Testbilder ligger ofte allerede i utviklerens nettleserbuffer, men tar lengre tid å laste inn for sluttbrukeren.
  • API-kall som kjøres lokalt, er ofte så raske at forsinkelser som ikke er merkbare under utvikling, kan bli betydelig i produksjon.

Hvordan måle CLS

Poengsummen (layout shift score) beregnes ved at nettleseren ser på størrelsen på visningsområdet (viewport size) og bevegelsen til de ustabile elementene mellom to gjengitte bilderammer i visningsområdet. Poengsummen er et produkt av to mål på denne bevegelsen: påvirkningsandelen (impact fraction) og avstandsandelen (distance fraction) som definert under (Mihajlija et al., 2023):

layout shift score = impact fraction * distance fraction

CLS kan måles i laboratoriet eller ute i felt. Verdien er tilgjengelig i følgende verktøy (Mihajlija et al., 2023):

Feltverktøy

  • Chrome User Experience Report
  • PageSpeed Insights
  • Search Console (Core Web Vitals report)
  • web-vitals JavaScript library

Lab-verktøy

  • Chrome DevTools
  • Lighthouse
  • PageSpeed Insights
  • WebPageTest

Det er også mulig å måle layoutforskyvninger i JavaScript (Mihajlija et al., 2023).

Forbedre CLS

For å gi en god brukeropplevelse bør nettsteder tilstrebe en CLS på 0,1 eller lavere for minst 75 % av sidebesøkene (Osmani et al., 2025). I motsetning til de andre Core Web Vitals-verdiene, som er tidsbaserte verdier målt i sekunder eller millisekunder, er CLS-scoren en enhetsløs verdi basert på en beregning av hvor mye innhold som flytter på seg, og hvor langt det flytter seg.

De vanligste årsakene til dårlig CLS er:

  • Bilder uten angitte dimensjoner.
  • Annonser, innebygd innhold og iframes uten angitte dimensjoner.
  • Dynamisk innsatt innhold – som annonser, innebygd innhold og iframes – uten angitte dimensjoner.
  • Web-fonter.

Enkle grep for å løse dette er å alltid angi høyde og bredde for bilder, reservere plass til dynamiske brukergrensesnittelementer, og unngå å sette inn innhold over eksisterende innhold (Tawhare, 2026). Tradisjonelle metoder for å laste ned web-fonter kan medføre dårlig CLS. Følgende verktøy kan hjelpe deg med å minimere forskyvning av tekst (Osmani et al., 2025):

  • Koden «font-display: optional» kan forhindre ny layout, ettersom web-fonten bare brukes hvis den er tilgjengelig når den første layouten utføres.
  • Sørg for at det brukes en egnet reservefont. Hvis du for eksempel bruker «font-family: "Google Sans", sans-serif;», sikrer du at nettleserens sans-serif-reservefont brukes mens “Google Sans” lastes inn. Hvis du ikke angir en reservefont, vil standardfonten i nettleseren bli brukt.
  • Minimer størrelsesforskjellene mellom reservefonten og web-fonten ved å bruke de nye API-ene «size-adjust», «ascent-override», «descent-override» og «line-gap-override».
  • «Font Loading API» kan redusere tiden det tar å hente nødvendige fonter.
  • Last inn kritiske webfonter så tidlig som mulig ved hjelp av <link rel=preload>. En forhåndslastet web-font har større sjanse for å være klar til den første renderingen («first paint»), noe som hindrer layoutforskyvning.

En svært effektiv metode for å holde CLS-verdiene lave, er å sørge for at nettsidene dine kan benytte seg av back/forward-bufferen (bfcache) (Osmani et al., 2025). «bfcache» (back/forward cache) holder nettsider i nettleserens minne en kort stund etter at du har navigert bort fra dem. De vil derfor gjenopprettes nøyaktig slik de var da du forlot dem – uten forskyvninger.

First Contentful Paint (FCP)

I tillegg til LCP, INP og CLS, arbeides det også med First Contentful Paint (FCP). FCP måler hvor lang tid det tar før det første synlige innholdet (tekst, bilde eller lasteindikator) vises på skjermen (Tawhare, 2026). Godt resultat er under 1,8 sekunder.

Vanlige årsaker til treg FCP er store CSS- eller JS-filer,blokkerende skript og treg serverrespons. Praktiske tips for å løse dette er å bruke «lazy loading» for moduler, reduse ubrukt CSS/JS, og komprimere bildene (Tawhare, 2026).

Time to First Byte (TTFB)

Time to First Byte (TTFB) tiden det tar fra nettleseren spør om nettsiden, til serveren svarer, bør være under 200 millisekunder (Veniro, 2026). Er TTFB over 600 ms, er det et klart hostingsignal, det vil si at webhotellet deler serverressurser med hundrevis av andre nettsider, der alle bremser hverandre i travle perioder (Veniro, 2026). Hvis Googles PageSpeed Insights viser «Reduce server response times» øverst på listen over forbedringsmuligheter, er hosting sannsynligvis problemet.

Kostnader på trege nettsider

En treg nettside er en usynlig kostnad. En nettside som bruker over 3 sekunder å laste, mister over halvparten av mobilbesøkende (Veniro, 2026). I studien «Milliseconds Make Millions» ble det analysert 30 millioner brukerøkter på mobilnettsider i Europa og USA (Berntsen, 2026). Funnet var at en forbedring på 0,1 sekunder i nettstedshastighet på tvers av de målte parameterne, observerte deltakerne i studien en økning i konverteringsraten (andelen brukere som går videre fra én nettside til neste steg i konverteringstrakten) i nesten alle ledd av mobilreisen. Spesielt var det en økning på 3,2 % fra produktoversiktssiden til produktdetaljsiden, og en økning på 9,1 % fra produktdetaljsiden til siden for å legge varer i handlekurven, samt at forbrukerne brukte 9,2 % mer penger (Demidova, 2020).

Alle forbedringene ovenfor ble observert etter en forbedring på 0,1 sekunder i fire måleparametere: First Meaningful Paint, Estimated Input Latency, Observed Load (gjennomsnittlig sideinnlastingstid i Google Analytics) og Max Server Latency (TTFB) (Demidova, 2020). Hver nettside i kundereisen måtte vise en forbedring på 0,1 sekunder for hver av disse parameterne for at de positive effektene skulle kunne observeres.

Kilder

Hentet fra «https://www.liavaag.org/wiki/index.php?title=Core_Web_Vitals&oldid=1872»