Core Web Vitals (2026): LCP, INP og CLS forklart uten sjargong

Alle snakker om at nettstedet må være raskt. Men «raskt» er upresist. Core Web Vitals er Googles forsøk på å måle det konkret, og siden 2024 er det tallene i denne målingen som avgjør om nettstedet ditt oppleves som moderne eller trettende.

Hva er Core Web Vitals?

Core Web Vitals er tre målinger som til sammen beskriver hvor rask og behagelig en nettside oppleves:

• LCP (Largest Contentful Paint) — hvor lang tid det tar før det største synlige elementet lastes.
• INP (Interaction to Next Paint) — hvor lang tid det tar før siden reagerer når brukeren klikker eller taster.
• CLS (Cumulative Layout Shift) — hvor mye innhold flytter seg mens siden laster.

Google måler disse via ekte brukerdata fra Chrome (samlet i Chrome User Experience Report, CrUX), og bruker resultatene som en del av rangeringssignalet «Page Experience».

LCP: Largest Contentful Paint

Hva den måler: Tiden fra brukeren klikker på lenken til det største synlige elementet vises i viewport. På de fleste sider er dette hero-bildet, en video, eller en stor overskrift.

Terskler:

• God: under 2,5 sekunder
• Trenger forbedring: 2,5 til 4 sekunder
• Dårlig: over 4 sekunder

Vanlige årsaker til dårlig LCP:

• Store, uoptimaliserte bilder (spesielt hero-bilder over folden)
• Treg server (høy TTFB)
• Render-blokkerende JavaScript eller CSS
• Bilder uten loading="eager" på LCP-elementet (ja, dette er motsatt av vanlig anbefaling)
• Font-lasting som forsinker teksten

Hva som fungerer:

• Komprimer bilder (WebP eller AVIF format, riktig dimensjonering).
• Bruk <img fetchpriority="high"> på LCP-bildet.
• Preloading av kritiske ressurser: <link rel="preload" as="image" href="/hero.webp">.
• Reduser CSS til det kritiske over folden, defer resten.
• Bruk CDN så bilder leveres nærmere brukeren.

INP: Interaction to Next Paint

Hva den måler: Hvor lenge det tar før siden visuelt responderer når brukeren klikker, taster eller trykker. Målingen tar den tregeste interaksjonen (eller 98-persentilen for sider med mange interaksjoner) gjennom hele besøket.

Terskler:

• God: under 200 ms
• Trenger forbedring: 200 til 500 ms
• Dårlig: over 500 ms

INP erstattet FID (First Input Delay) i mars 2024. FID målte bare første klikk, og var ofte grønt selv for tunge nettsteder. INP er strengere fordi den følger hele besøket.

Vanlige årsaker til dårlig INP:

• Tunge JavaScript-oppgaver som blokkerer hovedtråden
• For mange tredjeparts-skript (chat-widgets, tracking, A/B-testing)
• Ineffektive React/Vue-komponenter som re-renderer for ofte
• Store DOM-trær (over 1500 elementer på én side)

Hva som fungerer:

• Del opp lange JavaScript-oppgaver i mindre biter (setTimeout, requestIdleCallback).
• Fjern eller lazy-load tredjeparts-skript du ikke trenger umiddelbart.
• Reduser DOM-størrelsen (spesielt hvis du bruker tunge builder-verktøy).
• Bruk content-visibility: auto på tunge seksjoner under folden.
• Vurder web workers for tung logikk.

CLS: Cumulative Layout Shift

Hva den måler: Hvor mye synlig innhold flytter seg mens siden laster. Score er en akkumulert verdi (målt over sesjonen), der høyere er verre.

Terskler:

• God: under 0,1
• Trenger forbedring: 0,1 til 0,25
• Dårlig: over 0,25

Vanlige årsaker til dårlig CLS:

• Bilder uten width og height-attributter
• Annonser eller embeds som lastes inn og skyver innhold nedover
• Font-swap som endrer tekststørrelse etter render
• Innhold som lastes dynamisk over folden

Hva som fungerer:

• Sett alltid width og height på bilder og iframes (eller bruk CSS aspect-ratio).
• Reserver plass til annonser og embeds med minimum-høyde-container.
• Bruk font-display: swap med bevisst valgt fallback som ligner (subset av samme metrikk).
• Ikke sett inn nye elementer over eksisterende innhold etter render (bruk toast/modal i stedet).

Lab-data vs felt-data: hvorfor det er viktig

Når du åpner pagespeed.web.dev, får du to sett med tall:

Lab-data (Lighthouse): Google spinner opp en simulert enhet, med simulert nettverk (4G, ofte 4x throttling), og måler alt der og da. Nyttig for debugging fordi det er reproduserbart, men det er ikke det Google bruker for rangering.

Felt-data (CrUX): Reelle målinger fra Chrome-brukere som har besøkt siden din de siste 28 dagene. Dette er det Google bruker for rangering. Ulempen er at det tar tid før endringer synes, og små nettsteder får ikke nok trafikk til å ha felt-data.

Regel: fiks først basert på lab-data, verifiser i felt-data over de neste ukene. Har du ikke nok felt-data, bruk lab som proxy.

Slik måler du systematisk

• Ad-hoc: pagespeed.web.dev på nøkkelsider.
• Løpende overvåkning: Google Search Console har en dedikert Core Web Vitals-rapport (grupperer sider som passerer/feiler).
• Utvikleroppsett: Chrome DevTools > Performance-fanen, eller web-vitals-biblioteket for å samle inn egne målinger og sende til analytics.
• Sanntid: WebPageTest for detaljerte flame graphs og waterfalls.

Dette ser jeg ofte gå galt

• Alle måler forsiden, ingen måler produktsidene. Forsiden er ofte optimalisert, mens produkt- og kategorisider er der brukerne faktisk lander, og der problemene sitter.
• «Rask på lab, treg i felt». Lab-testen kjører fra Google Cloud i USA på en simulert 4G. Ekte norske brukere sitter på ekte 4G med lag og trege enheter. Felt-data lyver ikke.
• Fikset LCP, ødela INP. Man legger til preloads, animasjoner og tracking for å måle konvertering, og INP kollapser stille.
• CLS på mobile menyer. Sider som ser stabile ut på desktop, hopper voldsomt på mobil fordi menyen renderer sent.
• Ingen re-testing etter fiks. Man deployer en fiks, feirer, og lar den regressere igjen etter neste feature-release.

Case-studie: LCP fra 4,8 til 1,9 på én uke

En nettbutikk med solid organisk trafikk merket at rangeringen på flere hovedkategorier sakte men sikkert falt gjennom Q1. Google Search Console viste at 68 % av sidene hadde «dårlig» LCP.

Diagnose: Hero-banneret på kategori-sidene var et 1,4 MB PNG-bilde, servert uten CDN, uten lazy-loading-hint og uten priorityfixing.

Handlingen: Konverterte bildet til WebP (280 KB), la til fetchpriority="high", satte opp Cloudflare foran hosten, og fjernet et tredjeparts anmeldelses-skript som blokkerte renderingen i 900 ms.

Resultatet: LCP i felt-data falt fra median 4,8 s til 1,9 s over 14 dager. INP forbedret seg som bieffekt fra 340 ms til 190 ms. Innen 6 uker hadde tre av fem hovedkategorier rangert opp mellom 1 og 3 plasser.

Prioritet: hva du fikser først

Du kan ikke fikse alt samtidig. Slik prioriterer jeg:

1. LCP først. Ofte størst effekt, ofte lettest fiks (bildeoptimalisering + CDN).
2. CLS neste. Krever design/utviklings-oppmerksomhet, men gir umiddelbar UX-gevinst.
3. INP sist. Krever ofte dypere refaktorering av JavaScript. Verdt det, men mer arbeid.

Din handlingsplan: Steg-for-steg

Oppsummert: Min mening om Core Web Vitals

Core Web Vitals er ikke den viktigste rangeringsfaktoren, men det er en av de mest håndgripelige. Innhold og lenker er større spak, men Core Web Vitals er noe du faktisk kan påvirke i løpet av dager, ikke måneder.

Bonus: alt du gjør for å forbedre Core Web Vitals forbedrer også konverteringsraten. Google har målt at forbedringer i Core Web Vitals konsekvent henger sammen med økt engasjement og salg, uavhengig av rangering.

Start med LCP. Fiks bildene. Legg til CDN. Se hva som skjer i felt-data over neste 14 dager. Fortsett derfra.