Core Web Vitals & Technical UX

I SEO er markedslederne sjelden de som bare er best på innhold, og heller ikke de som bare er best på lenker. Det er de som i tillegg bruker Googles egne verktøy til å forstå og forbedre den tekniske helsen på nettstedet. Core Web Vitals er det mest konkrete av dem: tre målinger som sier hvordan siden faktisk oppleves av folk som bruker den.

De tre målingene

Hver måling for seg sier lite. Sammen gir de et brukbart bilde av opplevelsen.

Largest Contentful Paint (LCP) måler hvor lang tid det tar før det største bildet eller tekstelementet er synlig, regnet fra siden begynner å laste. Grensen for god ytelse er 2,5 sekunder. Mellom 2,5 og 4 sekunder er forbedringsverdig, over 4 sekunder er dårlig.

Interaction to Next Paint (INP) måler hvor raskt siden svarer når brukeren gjør noe. Målingen dekker alle interaksjoner på siden og gir en score basert på varigheten til den lengste av dem. Under 200 millisekunder er godt, 200 til 500 er forbedringsverdig, over 500 er dårlig.

Cumulative Layout Shift (CLS) måler visuell stabilitet, eller rettere sagt ustabilitet. Den fanger opp uventede forskyvninger i layouten, ikke designvalg. Fordi den ikke måler tid, får dere en score: under 0,1 er godt, 0,1 til 0,25 er forbedringsverdig, over 0,25 er dårlig.

Alle tre vurderes på 75. persentil av sidevisningene. Det betyr at det ikke holder at gjennomsnittsbrukeren har det bra. Tre av fire må ha det bra, også de på svak mobildekning.

INP erstattet FID, og det gjorde en reell forskjell

12. mars 2024 tok INP over plassen til First Input Delay. FID målte bare ventetiden før nettleseren begynte å behandle den første interaksjonen, og den kritikken var berettiget: målingen fanget ikke opp det som faktisk irriterer folk.

INP måler hele forløpet, og det er verdt å kjenne de tre delene, for det er der feilsøkingen begynner:

1. Input delay: tiden fra brukeren klikker til nettleseren kan begynne å jobbe. Ofte fordi hovedtråden er okkupert av JavaScript.
2. Processing time: tiden det tar å kjøre event-handlerne som hører til interaksjonen.
3. Presentation delay: tiden det tar å tegne den første framen som viser et svar.

Konsekvensen for arbeidet er tydelig: INP er i praksis et JavaScript-problem. Lange oppgaver på hovedtråden, tunge event-handlere og enorme DOM-strukturer er de vanligste årsakene. Hvordan rendering påvirker resten av bildet, går vi gjennom i guiden om JavaScript-SEO og rendering.

Slik jobber vi: undersøk, analysér, gjennomfør

Metoden er den samme hver gang, og rekkefølgen er hele poenget.

Undersøk. Start i Core Web Vitals-rapporten i Google Search Console. Den grupperer URL-er med samme problem, og det er den eneste kilden som viser om feilen gjelder én side eller en hel sidetype. Det er den vanligste tidstyven vi ser: noen optimaliserer én URL når problemet ligger i malen bak tusen.

Analysér. Ta URL-ene rapporten peker på inn i PageSpeed Insights. Der ser dere hvilke konkrete elementer som utløser problemet. Under Avoid large layout shifts står ofte hele forklaringen på en dårlig CLS-score, ned til det enkelte elementet.

Gjennomfør. Rett årsaken, ikke symptomet. Den klassiske CLS-feilen er utdaterte bildefiler i PNG og JPG som er for tunge å laste. De kommer inn sent, og skjøv de først resten av layouten nedover på én URL, gjør de det på alle URL-er som bruker samme mal. Komprimering og moderne formater løser det på hele nettstedet i én omgang.

Hva som faktisk gir utslag på tallene

• LCP: komprimer og lever bilder i moderne formater, prioriter hero-bildet med fetchpriority, forhåndskoble til de domenene som leverer kritiske ressurser, og se på TTFB. Er svartiden fra serveren høy, hjelper ingen frontend-triks.
• INP: del opp lange JavaScript-oppgaver, utsett alt som ikke trengs ved første visning, rydd i tredjepartsskript, og hold DOM-en så liten som temaet tillater.
• CLS: reserver plass til bilder, annonser og innbygde elementer med faste dimensjoner, unngå innhold som settes inn over eksisterende innhold, og last inn webfonter slik at teksten ikke hopper når fonten kommer.

Feltdata og labdata er ikke det samme

Skillet er verdt å ha klart. Feltdata er målinger fra virkelige brukere, samlet i Chrome User Experience Report, og det er dette Google faktisk vurderer dere på. Labdata er en simulert måling fra Lighthouse, praktisk under utvikling fordi den er stabil og gjentakbar.

Én fallgruve: Lighthouse kan ikke måle INP direkte, siden det ikke finnes en bruker som klikker. Der får dere Total Blocking Time som en tilnærming. Ser labtallene fine ut mens feltdataene er røde, er det feltdataene som har rett.

Hvorfor dette betyr mer nå

Core Web Vitals er en del av sideopplevelsen, ikke en enkeltstående rankingfaktor som løfter dere på egen hånd. Godt innhold på en langsom side rangerer bedre enn tynt innhold på en rask. Men mellom to sider som svarer omtrent like godt, avgjør opplevelsen, og det gjelder i alle bransjer der noen har gjort dette arbeidet allerede.

Så kom AI-flatene, og det ble et ledd til. Søkeagenter og AI-assistenter henter innhold i sanntid, og en side som er treg eller ustabil å hente, blir en dårligere kilde å bygge et svar på. Rask, ren levering er blitt en forutsetning for å bli sitert, på samme måte som den lenge har vært det for å bli klikket på.

Neste steg

Core Web Vitals er én del av den tekniske helsen. Resten, fra indekseringsfeil til redirects, ligger i pillaren om teknisk SEO og i guiden om health score og redirects.

Skal nettstedet gjennomgås ordentlig, er tekniske audits leveransen for det. Trenger dere et utgangspunkt først, peker en gratis SEO-analyse ut hvilke sidetyper som koster dere synlighet i dag.