Core Web Vitals: LCP, INP och CLS

Modul 4: Hastighet, mobil och https · Lästid: 13 minuter

Lärandemål: Efter den här lektionen kan du förklara de tre Core Web Vitals och deras gränsvärden, beskriva skillnaden mellan fältdata och labbdata, läsa en mätning i PageSpeed Insights, åtgärda de viktigaste orsakerna till ett dåligt resultat och realistiskt bedöma hur mycket hastighet väger i sökresultaten.

Nyckelbegrepp: Core Web Vitals, LCP (Largest Contentful Paint), INP (Interaction to Next Paint), CLS (Cumulative Layout Shift), 75:e percentilen, fältdata (CrUX), labbdata (Lighthouse), PageSpeed Insights, rapporten Core Web Vitals i Search Console, TTFB, komprimering, width och height på bilder, loading="lazy", sidupplevelse

Hastighet i tre siffror

"Är min webbplats snabb?" är en vag fråga. Google och utvecklarna av Chrome har gjort om den till tre mätbara frågor, Core Web Vitals:

Några saker som är bra att förstå:

• LCP mäter när det största synliga elementet visas. Oftast är det en stor bild högst upp ("hero"-bilden) eller ett stort textblock. Hos Blomsterateljé Elsa är det bilden på blomsterarrangemanget på startsidan.
• INP tittar på alla klick, tryck och tangenttryckningar under besöket och rapporterar (nästan) den långsammaste reaktionen. INP ersatte den 12 mars 2024 den äldre mätningen FID (First Input Delay), som bara tittade på det första klicket och bara på väntetiden före bearbetningen. Ser du FID i en gammal artikel är den uppgiften inaktuell.
• CLS är ingen tid utan ett värde utan enhet. Det blir högre när saker flyttar sig medan du läser: du ska trycka på en knapp och just då skjuts en banner in ovanför, så att du trycker på något annat.

75:e percentilen

En sida "klarar" Core Web Vitals när 75 procent av besöken får ett bra resultat på alla tre, mätt separat för mobil och dator. Det kallas 75:e percentilen. Det betyder: det är inte din egen snabba dator på fiber som räknas, utan upplevelsen för de flesta besökare, även de med en äldre telefon på 4G.

Fältdata och labbdata

Det finns två sorters mätningar, och de ger ofta olika siffror.

• Fältdata kommer från riktiga besökare. Chrome samlar anonymt in (hos användare som tillåter det) hur snabba sidorna var, i Chrome User Experience Report (CrUX). PageSpeed Insights visar fältdata från de senaste 28 dagarna. Rapporten Core Web Vitals i Search Console använder samma källa. Har din sida för få besökare visar PageSpeed Insights siffrorna för hela webbplatsen ("origin"), och har även den för få finns ingen fältdata.
• Labbdata kommer från ett simulerat test med Lighthouse: en enda laddning på en efterliknad medelbra telefon och uppkoppling. Lighthouse kan inte mäta INP (ingen klickar), och visar därför andra siffror, till exempel Total Blocking Time, som ändå ger en fingervisning om INP.

Det är fältdata som räknas i bedömningen. Labbdata är praktiskt för att hitta orsaker och för att direkt efter en förbättring se om den hjälper, utan att vänta i 28 dagar.

Hur mycket väger det?

Här överdrivs det mycket. Det här säger Google själv i dokumentationen om sidupplevelse:

• "Core Web Vitals are used by our ranking systems": de räknas alltså in.
• Det finns ingen separat "sidupplevelsesignal". Andra delar av en bra sidupplevelse (https, inga påträngande popup-fönster, mobilvänlighet) hjälper dig enligt Google inte direkt att ranka högre, men de gör webbplatsen trevligare att använda.
• "Google Search always seeks to show the most relevant content, even if the page experience is sub-par." En långsam sida med det bästa svaret kan alltså mycket väl hamna högst upp.
• Att jaga ett perfekt resultat bara för SEO är enligt Google "kanske inte det bästa sättet att använda din tid".

Slutsats: se till att du ligger i det gröna eller åtminstone det orange området, framför allt eftersom besökare lämnar en sida som är långsam eller hoppar. Att jaga från 90 till 100 poäng i Lighthouse ger lite i sökresultaten.

Orsakerna du kan åtgärda själv

Ett långsamt första svar (TTFB)

Allt börjar med ögonblicket när den första byten av HTML-koden kommer fram, Time to First Byte. TTFB är i sig ingen Core Web Vital, men en långsam TTFB gör en bra LCP nästan omöjlig. web.dev anger som riktvärde: bra är 0,8 sekunder eller mindre, dåligt är mer än 1,8 sekunder. Orsaker enligt web.dev: för lite datorkraft hos webbhotellet, ingen cache (varje sida byggs upp på nytt, typiskt för WordPress utan cacheplugin), vidarebefordringar (lektion 4.1) och en server långt bort utan CDN.

Komprimering hör också hit: servern ska skicka HTML, CSS och JavaScript packat med gzip eller Brotli. Det ser du på svarshuvudet Content-Encoding: gzip eller br. Nästan alla webbhotell gör det som standard, men en felaktig inställning eller en gammal server kan stänga av det.

Bilder

Bilder är den vanligaste orsaken till dålig LCP och CLS:

1. För stora. En bild som är 4.000 pixlar bred och 5 MB för en ruta på 800 pixlar. Förminska bilden innan du laddar upp den och använd ett modernt format som WebP eller AVIF.

2. Ingen bredd och höjd. Utan width och height vet webbläsaren inte hur mycket plats bilden behöver, och texten under hoppar när bilden kommer fram. web.dev rekommenderar att sätta width och height på varje <img>:

   <img src="blomsterarrangemang.webp" width="800" height="600" alt="Brudbukett med vita rosor">

3. Lat laddning av den viktigaste bilden. loading="lazy" gör att en bild laddas först när den kommer in i bild. Utmärkt för bilder längre ner, men web.dev är tydlig: bilder som syns direkt när sidan öppnas, och absolut LCP-bilden, ska inte laddas lat. Annars väntar webbläsaren med just den bild som avgör din LCP.

Innehåll som hoppar och långsamma reaktioner

Andra orsaker till CLS enligt web.dev: typsnitt som ändrar storlek när de laddas, annonser och inbäddade widgetar som gör sig själva större, och innehåll som senare läggs in ovanför befintligt innehåll (som en cookiebanner som trycker ner sidan i stället för att lägga sig ovanpå). En dålig INP beror nästan alltid på för mycket JavaScript: tunga teman, bildspel, chattwidgetar och spårare från tredje part. Granska varje plugin och inbäddad tjänst kritiskt; mindre är verkligen mer här.

I praktiken: mät med PageSpeed Insights

Gå till pagespeed.web.dev, fyll i adressen till din startsida och klicka på Analysera. Du får två flikar (Mobil och Dator). Högst upp visas bedömningen av Core Web Vitals baserad på fältdata, om sådan finns. Därunder finns Lighthouse-testet med ett resultat och en lista "Diagnostik" med konkreta punkter, till exempel om bilder som är större än nödvändigt eller en LCP-bild som laddas lat (de exakta namnen ändras med nya versioner av Lighthouse). Börja med Mobil: där är det oftast sämre, och Google tittar på mobilen först (lektion 4.2).

Har du din webbplats i Search Console (modul 2), titta då också under Upplevelse, Core Web Vitals. Där ser du grupper av liknande sidor med deras status, även för sidor du inte själv har testat.

En webbplats från AI Builder sätter bredd och höjd på bilder vars storlek är känd, laddar sidans första bild direkt och med förtur (fetchpriority="high") och resten lat, och skapar vid publicering en 800 pixlar bred variant av stora bilder. I WordPress hjälper ett cacheplugin och förminskade bilder mest; WordPress-kursen går djupare in på det i modul 6. Hos andra webbplatsbyggare och webbhotell fungerar det på liknande sätt: knapparna skiljer sig, men orsakerna är desamma.

Sammanfattning

• Core Web Vitals är LCP (bra upp till 2,5 s), INP (bra upp till 200 ms, sedan mars 2024 i stället för FID) och CLS (bra upp till 0,1), mätt vid 75:e percentilen per enhetstyp.
• Fältdata (CrUX, 28 dagar) avgör bedömningen; labbdata (Lighthouse) hjälper dig att hitta orsaker.
• Google använder Core Web Vitals i rankningen, men relevans går först: ett perfekt resultat är inget mål i sig.
• Störst vinst: snabbt serversvar med cache och komprimering, små bilder med width och height, ingen lat laddning av den viktigaste bilden, mindre JavaScript från tredje part.

Quiz

Uppgift

Uppgift A4.3: Snabbt svar och lätta bilder. Fyll i adressen till en sida. Programmet mäter tre gånger tiden till första byten (TTFB) från vår server och tar mittenvärdet, kontrollerar om HTML-koden skickas komprimerad (gzip, Brotli eller zstd), räknar bilderna utan width och height, och kontrollerar att den viktigaste bilden högst upp inte laddas med loading="lazy". Obs: det här är en mätning från en enda plats, inte en mätning av dina besökare. Ingen egen webbplats? Använd www.wikipedia.org.

Uppgift D4.3: Dina Core Web Vitals. Kör PageSpeed Insights på din startsida och på en annan viktig sida, först på Mobil. Anteckna för varje sida: finns det fältdata (för sidan eller hela webbplatsen), LCP, INP och CLS från fältdatan, Lighthouse-resultatet och det element som Lighthouse pekar ut som LCP-element. Välj den enda förbättring som du tror ger mest, och förklara varför.

Läs 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 Hjälp, Core Web Vitals report: https://support.google.com/webmasters/answer/9205520
• Läsa PageSpeed Insights: Core Web Vitals i vanligt språk
• Min webbplats är långsam eller använder för mycket CPU: så gör du den snabbare
• Gratis WordPress-kurs 6.1: Vad gör en webbplats långsam, och hur mäter du det?
• Gratis WordPress-kurs 6.3: Bilder, PHP och annan hastighetsvinst