Core Web Vitals och sidhastighet: vad måtten betyder och hur ni förbättrar dem

Det är lätt att tro att en webbplats är snabb för att den är snabb på er egen dator. Men besökarna sitter på mobiler, ofta med sämre uppkoppling, och det är deras upplevelse som räknas. Långsamma sidor, sidor som hoppar när de laddas och knappar som inte reagerar får människor att lämna. Google har samlat det i tre mått som kallas Core Web Vitals, och som ingår i hur de bedömer upplevelsen på en sida.

Den här guiden förklarar vad måtten betyder, hur ni mäter dem och vad ni själva kan göra, även om ni inte kan koden.

De tre måtten

Core Web Vitals mäter tre aspekter av upplevelsen:

LCP: hur snabbt syns det viktigaste?

Largest Contentful Paint mäter hur lång tid det tar innan det största synliga innehållet (oftast en stor bild eller en rubrik) har laddats. Google anger att ett bra värde är 2,5 sekunder eller snabbare. Över 4 sekunder bedöms som dåligt.

Vad besökaren upplever: "Hur snabbt ser jag något som är värt att läsa?"

INP: hur snabbt reagerar sidan?

Interaction to Next Paint mäter hur snabbt sidan svarar när besökaren gör något: klickar, trycker eller skriver. Ett bra värde är 200 millisekunder eller snabbare. Över 500 millisekunder bedöms som dåligt. INP ersatte tidigare måttet FID (first input delay) som ett Core Web Vital 2024.

Vad besökaren upplever: "När jag trycker på en knapp, händer det något direkt?"

CLS: hoppar sidan omkring?

Cumulative Layout Shift mäter hur mycket innehållet flyttar sig oväntat medan sidan laddas. Ett bra värde är 0,1 eller lägre. Över 0,25 bedöms som dåligt.

Vad besökaren upplever: "Jag skulle klicka på en knapp, men sidan hoppade och jag klickade på något annat."

Värdena bedöms för den 75:e percentilen av besöken, alltså det som tre av fyra besökare upplever eller bättre. Det betyder att det räcker inte att sidan är snabb för några, den ska vara det för de allra flesta.

Spelar det någon roll för synligheten?

Google har sagt att upplevelsen på sidan ingår som en signal bland många, men att innehållets relevans och kvalitet är viktigast. En snabb sida med dåligt innehåll rankar inte bra. Men likaså gäller att en sida med bra innehåll som är oanvändbart långsam förlorar besökare, vilket slår mot det ni egentligen vill uppnå: förfrågningar. Därför är hastighet värd arbetet oavsett hur mycket den påverkar placeringen. Se SEO för kommunikatörer.

Fältdata och labbdata

Det finns två sorter av mätningar, och de svarar på olika frågor:

• Fältdata kommer från riktiga besökare i Chrome (Googles register kallas CrUX). Det visar hur sidan faktiskt upplevs. Fältdata finns bara om sidan har tillräckligt många besök.
• Labbdata kommer från ett test som körs i en kontrollerad miljö, till exempel Lighthouse. Det är bra för att hitta orsaker och testa förbättringar, men det visar inte exakt vad era besökare upplever.

Det är labbdata som ofta ger poängen 0–100 ni ser i verktygen, men Googles bedömning av Core Web Vitals bygger på fältdata. Använd labbdata för att felsöka och fältdata för att bedöma resultatet.

Så mäter ni

1. PageSpeed Insights (gratis, från Google). Skriv in en adress och få både fältdata (om det finns) och labbdata, för mobil och dator, med konkreta förslag. Börja med mobilresultatet.
2. Google Search Console har en rapport för upplevelse och sidhastighet som grupperar era sidor som bra, behöver förbättras eller dåliga, för mobil och dator. Se Google Search Console för kommunikatörer.
3. Lighthouse i Chrome och andra verktyg kan köras på en enskild sida.
4. Testa på en riktig telefon, helst en äldre modell och med mobilnät. Det är ofta mer talande än siffror.

Mät flera viktiga sidor: startsida, en tjänstesida, en blogg- och en målsida. Anteckna startvärden så att ni kan se effekten av ändringar.

Vad ni själva kan göra

Mycket av det som påverkar måtten är innehåll och val som ni kan göra utan att skriva kod.

Bilder (påverkar mest LCP)

• Ladda upp bilder i rätt storlek. En bild som visas 800 pixlar bred ska inte vara 5 000 pixlar bred.
• Komprimera och välj moderna format (som WebP eller AVIF) om ert system stödjer det.
• Undvik onödigt stora bilder högst upp. Den stora bilden överst är ofta det som LCP mäter.
• Använd inte bilder för text.
• Ange bildernas storlek så att sidan vet hur mycket plats som behövs (påverkar CLS). Be den som bygger sidan om hjälp om inte systemet gör det.

Teckensnitt

• Använd få teckensnitt och vikter. Varje extra fil ska laddas.
• Se till att text syns medan teckensnittet laddas, så att besökaren inte ser tomma ytor.

Skript och tredjepartstjänster (påverkar INP och LCP)

Spårningskoder, chattfönster, kartor, inbäddade filmer, annonsverktyg och sociala flöden kan göra en sida tung. Gå igenom vad ni har och fråga för varje: behöver vi den, och vad får den kosta i hastighet?

• Ta bort sådant som inte används.
• Ladda tunga inbäddningar först när besökaren vill ha dem (till exempel en filmbild som laddar spelaren vid klick).
• Städa i Tag Manager. Se Google Tag Manager för kommunikatörer.

Kakbanner och pop-ups (påverkar CLS)

En kakbanner som skjuter ner allt innehåll när den visas ger layouthopp. Be att den ligger ovanpå innehållet eller har reserverat utrymme. Pop-ups som täcker sidan försämrar också upplevelsen. Se Cookies och kakbanner och Mobilanpassad hemsida.

Annonser och inbäddat innehåll

Reservera plats för annonser, filmer och inbäddade element så att sidan inte hoppar när de laddas.

Vad som kräver utvecklare eller bättre hosting

• Serverns svarstid. Ett svagt webbhotell eller en tung plattform gör allt långsammare. Se Domännamn och webbhotell.
• Cache och leveransnätverk (CDN) som förkortar avståndet till besökaren.
• Komprimering och minifiering av kod.
• Tung JavaScript som blockerar sidan. En utvecklare kan dela upp och skjuta upp kod som inte behövs direkt.
• Teman och tillägg i publiceringssystem som är onödigt tunga. Se WordPress, Wix eller något annat?.

Ställ krav på hastighet när ni beställer en sajt: skriv in målvärden för mobil. Se Så väljer ni webbyrå.

Så prioriterar ni

1. Börja med mobilen och de sidor som ger flest besök eller förfrågningar.
2. Åtgärda det som ger mest effekt: oftast bilder, tredjepartsskript och layouthopp.
3. Mät före och efter varje ändring.
4. Vänta med finjusteringar tills de stora problemen är lösta.
5. Gör hastighet till en rutin: kontrollera efter varje större ändring och några gånger per år.

En liten checklista

Vanliga frågor