Core Web Vitals: LCP, INP og CLS

Modul 4: Hastighet, mobil og https · Lesetid: 13 minutter

Læringsmål: Etter denne leksjonen kan du forklare de tre Core Web Vitals med grenseverdiene sine, forklare forskjellen på feltdata og labdata, lese en måling i PageSpeed Insights, ta tak i de viktigste årsakene til en dårlig score, og gjøre en ærlig vurdering av hvor mye hastighet teller i søkeresultatene.

Nøkkelbegreper: Core Web Vitals, LCP (Largest Contentful Paint), INP (Interaction to Next Paint), CLS (Cumulative Layout Shift), 75. persentil, feltdata (CrUX), labdata (Lighthouse), PageSpeed Insights, rapporten Core Web Vitals i Search Console, TTFB, komprimering, width og height på bilder, loading="lazy", sideopplevelse

Hastighet i tre tall

"Er nettsiden min rask?" er et vagt spørsmål. Google og utviklerne av Chrome har gjort det om til tre målbare spørsmål, Core Web Vitals:

Noen ting det er lurt å forstå godt:

• LCP måler tidspunktet da det største synlige elementet dukker opp. Det er som regel et stort bilde øverst ("hero"-bildet) eller en stor tekstblokk. Hos Bloemenatelier Lotte er det bildet av blomsteroppsatsen på forsiden.
• INP ser på alle klikk, trykk og tastetrykk under besøket og rapporterer (nesten) den tregeste reaksjonen. INP erstattet 12. mars 2024 den eldre målingen FID (First Input Delay), som bare så på det første klikket og bare på ventetiden før behandlingen. Ser du FID i en gammel artikkel, er det utdatert.
• CLS er ikke en tid, men en score uten enhet. Den blir høyere når ting flytter seg mens du leser: du skal trykke på en knapp, og akkurat da dukker det opp et banner over, så du trykker på noe annet.

75. persentil

En side "består" Core Web Vitals når 75 prosent av besøkene scorer godt på alle tre, målt separat for mobil og datamaskin. Det kalles 75. persentil. Det betyr at det ikke er din egen raske datamaskin på fiber som teller, men opplevelsen til de fleste besøkende, også de med en eldre telefon på 4G.

Feltdata og labdata

Det finnes to typer målinger, og de gir ofte ulike tall.

• Feltdata kommer fra ekte besøkende. Chrome samler anonymt inn (hos brukere som tillater det) hvor raske sidene var, i Chrome User Experience Report (CrUX). PageSpeed Insights viser feltdata fra de siste 28 dagene. Rapporten Core Web Vitals i Search Console bruker samme kilde. Har siden din for få besøkende, viser PageSpeed Insights tallene for hele nettstedet ditt ("origin"), og har heller ikke det nok, finnes det ingen feltdata.
• Labdata kommer fra en simulert test med Lighthouse: én lasting på en etterlignet middels telefon og forbindelse. Lighthouse kan ikke måle INP (ingen klikker), og gir derfor andre tall, som Total Blocking Time, som likevel gir en pekepinn om INP.

Det er feltdata som teller for vurderingen. Labdata er nyttig for å finne årsaker og for å se med en gang om en forbedring hjelper, uten å vente 28 dager.

Hvor mye teller det?

Her overdrives det mye. Dette sier Google selv i dokumentasjonen om sideopplevelse:

• "Core Web Vitals are used by our ranking systems": de teller altså med.
• Det finnes ikke noe eget "sideopplevelsessignal". Andre deler av en god sideopplevelse (https, ingen påtrengende popup-vinduer, brukbar på mobil) hjelper deg ifølge Google ikke direkte til å rangere høyere, men de gjør nettsiden din mer behagelig å bruke.
• "Google Search always seeks to show the most relevant content, even if the page experience is sub-par." En treg side med det beste svaret kan altså fint ligge øverst.
• Å jage en perfekt score bare for SEO er ifølge Google "kanskje ikke den beste bruken av tiden din".

Konklusjon: sørg for at du ligger i det grønne, eller i det minste det oransje, området, først og fremst fordi besøkende gir opp på en treg side eller en side som hopper. Å jage fra 90 til 100 poeng i Lighthouse gir lite i søkeresultatene.

Årsakene du kan gjøre noe med selv

En treg første respons (TTFB)

Alt starter med tidspunktet da den første byten av HTML-en kommer inn, Time to First Byte. TTFB er ikke selv en Core Web Vital, men en treg TTFB gjør en god LCP nesten umulig. web.dev oppgir som retningslinje: godt er 0,8 sekunder eller mindre, dårlig er mer enn 1,8 sekunder. Årsaker ifølge web.dev: for lite regnekraft hos webhotellet, ingen hurtigbuffer (hver side bygges på nytt, typisk for WordPress uten cache-plugin), videresendinger (leksjon 4.1) og en server langt unna uten CDN.

Komprimering hører med: serveren skal sende HTML, CSS og JavaScript pakket med gzip eller Brotli. Det ser du på hoderaden Content-Encoding: gzip eller br. Nesten alle webhotell gjør dette som standard, men en feil innstilling eller en gammel server kan slå det av.

Bilder

Bilder er den vanligste årsaken til dårlig LCP og CLS:

1. For store. Et bilde på 4.000 piksler i bredden og 5 MB til en plass på 800 piksler. Gjør bildet mindre før du laster det opp, og bruk et moderne format som WebP eller AVIF.

2. Ingen bredde og høyde. Uten width og height vet ikke nettleseren hvor mye plass bildet trenger, og teksten under hopper så snart bildet er lastet. web.dev anbefaler å sette width og height på hver <img>:

   <img src="bloemstuk.webp" width="800" height="600" alt="Bruidsboeket met witte rozen">

3. Lat lasting av det viktigste bildet. loading="lazy" laster et bilde først når det kommer til syne. Fint for bilder lenger ned, men web.dev sier tydelig: bilder som er synlige allerede når siden åpnes, og særlig LCP-bildet, skal ikke lastes med lat lasting. Ellers venter nettleseren med nettopp det bildet som avgjør LCP-en din.

Innhold som hopper og trege reaksjoner

Andre årsaker til CLS ifølge web.dev: skrifttyper som endrer størrelse under lasting, annonser og innebygde widgeter som gjør seg selv større, og innhold som settes inn senere over det eksisterende innholdet (som en cookie-banner som skyver siden nedover i stedet for å ligge over den). En dårlig INP skyldes nesten alltid for mye JavaScript: tunge temaer, slidere, chat-widgeter og sporingsverktøy fra tredjeparter. Se kritisk på hver plugin og hver innebygde tjeneste; her er mindre virkelig mer.

I praksis: mål med PageSpeed Insights

Gå til pagespeed.web.dev, skriv inn adressen til forsiden din og klikk Analyze. Du får to faner (Mobile og Desktop). Øverst står vurderingen av Core Web Vitals basert på feltdata, hvis det finnes. Under den kommer Lighthouse-testen med en score og en liste "Diagnostics" med konkrete punkter, for eksempel om bilder som er større enn nødvendig eller et LCP-bilde som lastes med lat lasting (de nøyaktige navnene endres med nye versjoner av Lighthouse). Start med Mobile: der er det som regel dårligst, og Google ser på mobilversjonen først (leksjon 4.2).

Har du nettstedet ditt i Search Console (modul 2), se også under Experience, Core Web Vitals. Der ser du grupper av like sider med status, også for sider du ikke har testet selv.

Et nettsted fra AI Builder setter bredde og høyde på bilder der størrelsen er kjent, laster det første bildet på siden med en gang og med prioritet (fetchpriority="high") og resten med lat lasting, og lager ved publisering en variant på 800 piksler i bredden av store bilder. I WordPress hjelper en cache-plugin og mindre bilder mest; WordPress-kurset går dypere inn på dette i modul 6. Hos andre nettsidebyggere og webhotell fungerer det på lignende måte: knappene er forskjellige, men årsakene er de samme.

Oppsummering

• Core Web Vitals er LCP (god opptil 2,5 s), INP (god opptil 200 ms, siden mars 2024 i stedet for FID) og CLS (god opptil 0,1), målt på 75. persentil per enhetstype.
• Feltdata (CrUX, 28 dager) avgjør vurderingen; labdata (Lighthouse) hjelper deg å finne årsaker.
• Google bruker Core Web Vitals i rangeringen, men relevans går foran: en perfekt score er ikke et mål i seg selv.
• Størst gevinst: rask serverrespons med hurtigbuffer og komprimering, små bilder med width og height, ingen lat lasting av det viktigste bildet, mindre JavaScript fra tredjeparter.

Quiz

Oppgave

Oppgave A4.3: Raskt svar og lette bilder. Skriv inn adressen til en side. Programmet måler tiden til første byte (TTFB) tre ganger fra serveren vår og tar det midterste tallet, sjekker om HTML-en sendes komprimert (gzip, Brotli eller zstd), teller bildene uten width og height, og sjekker at det viktigste bildet øverst ikke lastes med loading="lazy". Merk: dette er en måling fra ett sted, ikke en måling av de besøkende dine. Har du ikke eget nettsted? Bruk www.wikipedia.org.

Oppgave D4.3: Dine Core Web Vitals. Kjør PageSpeed Insights på forsiden din og på én annen viktig side, først på Mobile. Noter for hver side: finnes det feltdata (for siden eller hele nettstedet), LCP, INP og CLS fra feltdataene, Lighthouse-scoren, og elementet Lighthouse peker ut som LCP-element. Velg den ene forbedringen du mener gir mest, og forklar hvorfor.

Les mer

• web.dev, Web Vitals: https://web.dev/articles/vitals
• web.dev, Largest Contentful Paint (LCP): https://web.dev/articles/lcp
• web.dev, Interaction to Next Paint (INP): https://web.dev/articles/inp
• web.dev, Cumulative Layout Shift (CLS): https://web.dev/articles/cls
• web.dev, Time to First Byte (TTFB): https://web.dev/articles/ttfb
• web.dev, Browser-level image lazy loading: https://web.dev/articles/browser-level-image-lazy-loading
• Google Search Central, Understanding page experience in Google Search results: https://developers.google.com/search/docs/appearance/page-experience
• PageSpeed Insights, About PageSpeed Insights: https://developers.google.com/speed/docs/insights/v5/about
• Search Console Help, Core Web Vitals report: https://support.google.com/webmasters/answer/9205520
• Les PageSpeed Insights: Core Web Vitals i vanlig språk
• Nettstedet mitt er tregt eller bruker for mye CPU: slik gjør du det raskere
• Gratis WordPress-kurs 6.1: Hva gjør et nettsted tregt, og hvordan måler du det?
• Gratis WordPress-kurs 6.3: Bilder, PHP og andre hastighetsgevinster