Core Web Vitals og INP: hva som påvirker SEO og hva som bare irriterer

Core Web Vitals måler hvordan en side oppleves for brukeren: hvor raskt hovedinnholdet vises, hvor raskt siden svarer på et klikk, og om elementer hopper rundt. Det er tre målinger, og hver har en tydelig grense.

De tre målingene og grensene

• LCP (når det største innholdet vises): bra opp til 2,5 sekunder
• INP (respons på interaksjon): bra opp til 200 millisekunder, dårlig over 500 ms
• CLS (forskyvning i layout): bra opp til 0,1

Vurderingen bygger på 75. persentil av data fra ekte brukere, separat for mobil og desktop. Labscore (for eksempel Lighthouse) er et hjelpemiddel, ikke dommeren.

Slik ligger markedet an

Eksempel: ifølge HTTP Archives Web Almanac 2025 besto 48 % av mobilsidene (året før 44 %) og 56 % av desktopsidene alle tre målingene. På mobil hadde 77 % av sidene god INP, 62 % god LCP og 81 % god CLS. LCP er dermed det svakeste leddet.

Det betyr at de fleste nettsteder taper på LCP, ikke på INP. Ligger siden din på samme nivå som gjennomsnittet, er forbedring av LCP den største raske gevinsten.

INP: hvor forsinkelsen kommer fra

INP erstattet FID og måler den lengste interaksjonen gjennom hele besøket (med unntak av ekstremverdier). Den deles i tre: forsinkelse i inndata, behandlingstid og forsinkelse i tegning av siden.

• lange JavaScript-oppgaver i hovedtråden blokkerer behandlingen av klikk
• stor DOM og kostbare stilberegninger forlenger tegningen
• skript fra tredjeparter (chat, analyse, annonser) stjeler tid fra alle

Hva som faktisk påvirker plasseringene

Google omtaler sideopplevelsen som ett av kvalitetssignalene, men innholdets relevans er viktigere. Hastighet alene avgjør sjelden hvem som havner øverst, men dårlig LCP og hoppende layout får brukeren til å forlate siden. Hastighet er derfor først og fremst et spørsmål om konvertering, og deretter om rangering.

Hva du bør gjøre: rekkefølgen på utbedringene

1. Mål først ekte data (rapporten for Core Web Vitals i Search Console, CrUX-delen i PageSpeed Insights)
2. LCP: foretrekk HTML som er rendret på serveren, gi hovedbildet riktige dimensjoner og høy prioritet, og ikke lazy-load det
3. CLS: sett width og height på bilder og annonseplasser, og last skrifttyper uten hopp
4. INP: del opp lange oppgaver, utsett skript fra tredjeparter og reduser DOM-en
5. Kontroller resultatet etter 28 dager, for feltdata oppdateres med et glidende vindu

Eksempel fra praksis

Sidene på dette nettstedet genereres på forhånd som statisk HTML, slik at det første svaret kommer raskt og hovedinnholdet finnes uten JavaScript. Bildene har dimensjoner, så layouten ikke forskyves. Dette er den rimeligste veien for LCP og CLS, og den virker også for INP, fordi mindre JavaScript gir færre lange oppgaver.

Rask sjekkliste før lansering

• Hovedbildet har dimensjoner og er ikke lazy-lastet
• Skrifttyper gir ikke synlige hopp
• Skript fra tredjeparter lastes etter hovedinnholdet
• Interaktive elementer svarer på klikk uten merkbar forsinkelse

Tre spørsmål

Hvorfor er Lighthouse-scoren forskjellig fra Search Console?

Lighthouse er en labmåling fra én enhet og én surfing. Search Console viser data fra ekte brukere etter 75. persentil. Når du skal ta beslutninger, er det den siste som teller.

Hvor fort ser jeg effekten av en forbedring?

Feltdata oppdateres med et glidende vindu på 28 dager, så full effekt vises etter omtrent en måned. Ikke trekk konklusjoner etter tre dager.

Hva er viktigst: mobil eller desktop?

Begge vurderes hver for seg, men mobil er svakest: ifølge Web Almanac 2025 består 48 % av mobilsidene og 56 % av desktopsidene alle tre målingene. For LCP er andelen «dårlige» sider nesten dobbelt så stor på mobil (13 % mot 7 %).

Oppsummering

Start med ekte data, rett opp LCP først, deretter CLS og INP, og se på resultatet etter en måned. Et raskt nettsted garanterer ikke plassering, men et tregt nettsted taper helt sikkert besøkende.

Kilder

• web.dev: Interaction to Next Paint (INP)
• HTTP Archive: Web Almanac 2025, Performance