Core Web Vitals: LCP, INP og CLS

Modul 4: Hastighed, mobil og https · Læsetid: 13 minutter

Læringsmål: Efter denne lektion kan du forklare de tre Core Web Vitals og deres grænseværdier, sige hvad forskellen er på feltdata og labdata, læse en måling fra PageSpeed Insights, tage fat på de vigtigste årsager til en dårlig score og ærligt vurdere, hvor meget hastighed betyder i søgeresultaterne.

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

Hastighed i tre tal

"Er min side hurtig?" er et uklart spørgsmål. Google og folkene bag Chrome har gjort det til tre målbare spørgsmål, Core Web Vitals:

Et par ting, der er værd at forstå:

• LCP måler tidspunktet, hvor det største synlige element dukker op. Det er som regel et stort billede øverst ("hero"-billedet) eller en stor tekstblok. Hos Bloemenatelier Lotte er det billedet af blomsterdekorationen på forsiden.
• INP ser på alle klik, tryk og tastetryk under besøget og rapporterer (næsten) den langsomste reaktion. INP afløste den 12. marts 2024 den ældre måling FID (First Input Delay), som kun så på det første klik og kun på ventetiden før behandlingen. Støder du på FID i en gammel artikel, er den forældet.
• CLS er ikke en tid, men en score uden enhed. Den stiger, når ting flytter sig, mens du læser: Du vil trykke på en knap, og i samme øjeblik skubbes et banner ind ovenover, så du trykker på noget andet.

Den 75. percentil

En side "består" Core Web Vitals, når 75 procent af besøgene scorer godt på alle tre, målt separat for mobil og computer. Det kaldes den 75. percentil. Det betyder: Det er ikke din egen hurtige computer på fiber, der tæller, men oplevelsen for de fleste besøgende, også dem med en ældre telefon på 4G.

Feltdata og labdata

Der findes to slags målinger, og de giver ofte forskellige tal.

• Feltdata kommer fra rigtige besøgende. Chrome indsamler anonymt (hos brugere, der tillader det), hvor hurtige siderne var, i Chrome User Experience Report (CrUX). PageSpeed Insights viser feltdata for de seneste 28 dage. Rapporten Core Web Vitals i Search Console bruger samme kilde. Har din side for få besøgende, viser PageSpeed Insights tallene for hele dit websted ("origin"), og har det også for få, er der ingen feltdata.
• Labdata kommer fra en simuleret test med Lighthouse: én indlæsning på en efterlignet mellemklassetelefon og forbindelse. Lighthouse kan ikke måle INP (ingen klikker), og giver derfor andre tal, som Total Blocking Time, der dog er en indikation af INP.

Feltdata er det, der tæller i vurderingen. Labdata er nyttigt til at finde årsager og til straks at se, om en forbedring virker, uden at vente 28 dage.

Hvor meget betyder det?

Her bliver der overdrevet meget. Det siger Google selv i dokumentationen om sideoplevelse:

• "Core Web Vitals are used by our ranking systems": De tæller altså med.
• Der findes ikke et særskilt "sideoplevelsessignal". Andre dele af en god sideoplevelse (https, ingen påtrængende pop-ups, brugbar på mobil) hjælper ifølge Google ikke direkte med at komme højere op, men de gør dit websted rarere at bruge.
• "Google Search always seeks to show the most relevant content, even if the page experience is sub-par." En langsom side med det bedste svar kan altså sagtens ligge øverst.
• At gå efter en perfekt score kun for SEO'ens skyld er ifølge Google "måske ikke den bedste brug af din tid".

Konklusion: Sørg for at ligge i det grønne eller i hvert fald det orange område, først og fremmest fordi besøgende falder fra på en langsom eller hoppende side. At jage fra 90 til 100 point i Lighthouse giver ikke meget i søgeresultaterne.

Årsager, du selv kan gøre noget ved

Et langsomt første svar (TTFB)

Alt begynder med det øjeblik, hvor den første byte af HTML'en ankommer, Time to First Byte. TTFB er ikke selv en Core Web Vital, men en langsom TTFB gør en god LCP næsten umulig. web.dev angiver som retningslinje: God er 0,8 sekund eller mindre, dårlig er mere end 1,8 sekund. Årsager ifølge web.dev: for lidt regnekraft hos hostingen, ingen cache (hver side bygges op på ny, typisk for WordPress uden cacheplugin), viderestillinger (lektion 4.1) og en server langt væk uden CDN.

Komprimering hører med: Serveren bør sende HTML, CSS og JavaScript pakket med gzip eller Brotli. Det kan du se på headeren Content-Encoding: gzip eller br. Næsten al hosting gør det som standard, men en forkert indstilling eller en gammel server kan slå det fra.

Billeder

Billeder er den mest almindelige årsag til en dårlig LCP og CLS:

1. For store. Et foto på 4.000 pixels i bredden og 5 MB til en plads på 800 pixels. Gør billedet mindre før upload, og brug et moderne format som WebP eller AVIF.

2. Ingen bredde og højde. Uden width og height ved browseren ikke, hvor meget plads billedet skal bruge, og teksten nedenunder hopper, så snart billedet er hentet. web.dev anbefaler at sætte width og height på hvert <img>:

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

3. Lazy loading af det vigtigste billede. loading="lazy" får et billede til først at blive hentet, når det kommer til syne. Fint til billeder længere nede, men web.dev er tydelig: Billeder, der allerede er synlige, når siden åbnes, og især LCP-billedet, skal ikke lazy loades. Ellers venter browseren netop med det billede, der bestemmer din LCP.

Indhold, der hopper, og langsomme reaktioner

Andre årsager til CLS ifølge web.dev: skrifttyper, der skifter størrelse under indlæsning, annoncer og indlejrede widgets, der gør sig selv større, og indhold, der senere indsættes over det eksisterende indhold (som en cookiebar, der skubber siden ned i stedet for at ligge ovenpå). En dårlig INP skyldes næsten altid for meget JavaScript: tunge temaer, slidere, chatwidgets og trackere fra tredjeparter. Se kritisk på hvert plugin og hver indlejret tjeneste; her er mindre virkelig mere.

I praksis: mål med PageSpeed Insights

Gå til pagespeed.web.dev, skriv adressen på din forside, og klik på Analysér. Du får to faner (Mobil og Computer). Øverst står vurderingen af Core Web Vitals ud fra feltdata, hvis der er nogen. Nedenunder kommer Lighthouse-testen med en score og en liste "Diagnosticering" med konkrete punkter, for eksempel om billeder, der er større end nødvendigt, eller et LCP-billede, der lazy loades (de præcise navne ændrer sig med nye versioner af Lighthouse). Start med Mobil: Der står det som regel dårligst til, og Google ser på mobil først (lektion 4.2).

Har du dit websted i Search Console (modul 2), så kig også under Oplevelse, Core Web Vitals. Der ser du grupper af lignende sider med deres status, også for sider, du ikke selv har testet.

Et websted fra AI Builder sætter bredde og højde på billeder, hvor størrelsen er kendt, henter sidens første billede med det samme og med høj prioritet (fetchpriority="high") og resten med lazy loading, og laver ved udgivelse en version på 800 pixels i bredden af store billeder. I WordPress hjælper et cacheplugin og mindre billeder mest; WordPress-kurset går i dybden med det i modul 6. Hos andre websitebyggere og hostingfirmaer fungerer det på samme måde: Knapperne er forskellige, årsagerne er de samme.

Opsummering

• Core Web Vitals er LCP (god op til 2,5 s), INP (god op til 200 ms, siden marts 2024 i stedet for FID) og CLS (god op til 0,1), målt ved den 75. percentil pr. enhedstype.
• Feltdata (CrUX, 28 dage) afgør vurderingen; labdata (Lighthouse) hjælper med at finde årsager.
• Google bruger Core Web Vitals i rangeringen, men relevans går forud: En perfekt score er ikke et mål i sig selv.
• Størst gevinst: hurtigt svar fra serveren med cache og komprimering, små billeder med width og height, ingen lazy loading af det vigtigste billede, mindre JavaScript fra tredjeparter.

Quiz

Opgave

Opgave A4.3: Hurtigt svar og lette billeder. Skriv adressen på en side. Programmet måler tre gange tiden til første byte (TTFB) fra vores server og tager det midterste tal, tjekker om HTML'en sendes komprimeret (gzip, Brotli eller zstd), tæller billederne uden width og height og tjekker, at det vigtigste billede øverst ikke indlæses med loading="lazy". Bemærk: Det er en måling fra ét sted, ikke en måling af dine besøgende. Intet eget websted? Brug www.wikipedia.org.

Opgave D4.3: Dine Core Web Vitals. Kør PageSpeed Insights på din forside og på én anden vigtig side, først på Mobil. Notér for hver side: om der er feltdata (siden eller hele webstedet), LCP, INP og CLS fra feltdataene, Lighthouse-scoren og det element, Lighthouse udpeger som LCP-element. Vælg den ene forbedring, du mener giver mest, og forklar hvorfor.

Læs mere

• 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 Hjælp, Core Web Vitals report: https://support.google.com/webmasters/answer/9205520