Läsa PageSpeed Insights: Core Web Vitals i vanligt språk
Du har testat din webbplats i PageSpeed Insights och ser en röd siffra, till exempel 45. Vad betyder det, och hur illa är det? I den här artikeln läser du hur du tolkar rapporten, vad de tre Core Web Vitals mäter och vad du själv kan förbättra.
De tre mätningarna
| Mätning | Vad det mäter | Bra | Behöver förbättras | Dåligt |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | Hur snabbt det största innehållsblocket visas, ofta den stora bilden högst upp | upp till 2,5 s | 2,5 till 4 s | över 4 s |
| INP (Interaction to Next Paint) | Hur snabbt sidan reagerar när du klickar, trycker eller skriver | upp till 200 ms | 200 till 500 ms | över 500 ms |
| CLS (Cumulative Layout Shift) | Hur mycket sidan hoppar till under inläsningen (ett poäng, ingen tid) | upp till 0,1 | 0,1 till 0,25 | över 0,25 |
En sida klarar Core Web Vitals om minst 75 procent av besöken får bra poäng på alla tre, separat för mobil och dator. Det är alltså inte din snabba dator som räknas, utan upplevelsen hos de flesta besökare, även på en äldre telefon. INP ersatte den äldre mätningen FID i mars 2024. Stöter du fortfarande på FID är den informationen föråldrad.
Fältdata och labbdata
PageSpeed Insights visar två typer av mätningar, och de ger ofta olika siffror:
- Fältdata (högst upp): mätningar hos riktiga besökare med Chrome under de senaste 28 dagarna. Det här avgör om du klarar Core Web Vitals. Har din sida för få besökare ser du siffrorna för hela din webbplats, eller ingen fältdata alls.
- Labbdata (därunder): ett test med Lighthouse, som laddar sidan en gång på en simulerad medelmåttig telefon och anslutning. Det är härifrån siffran från 0 till 100 kommer. Lighthouse kan inte mäta INP, eftersom ingen klickar.
Använd labbdata för att hitta orsaker och för att direkt se om en förbättring hjälper. Börja med fliken Mobil: där är det oftast sämre, och Google tittar främst på den mobila versionen av din webbplats.
Hur mycket väger det hos Google?
Google skriver att Core Web Vitals räknas in vid rankningen. Men Google visar alltid det mest relevanta innehållet, även om den sidan inte är den snabbaste. Siffran från 0 till 100 kommer från labbtestet och är inte ett betyg från Google; det betyget kommer från fältdata. Att uppnå ett perfekt resultat enbart för Google är enligt Google själv inte den bästa användningen av din tid. Se till att du ligger i det gröna eller åtminstone det orangea området, särskilt eftersom besökare lämnar en långsam eller hoppig sida.
Vad du kan förbättra på själva sidan
- Mindre bilder. Ett foto på tusentals pixlars bredd för en ruta på 800 pixlar är den vanligaste orsaken till en långsam LCP. Förminska bilder innan uppladdning och använd ett modernt format som WebP eller AVIF.
- Bredd och höjd för varje bild. Utan
widthochheightvet webbläsaren inte hur mycket utrymme ett foto behöver, och texten hoppar till när det laddas in. Det ökar CLS:<img src="bloemstuk.webp" width="800" height="600" alt="Brudbukett med vita rosor">
- Ladda inte den viktigaste bilden lat.
loading="lazy"är bra för bilder längre ner, men inte för bilden som redan syns när sidan öppnas. Annars väntar webbläsaren just med bilden som avgör din LCP. - Infoga ingenting senare ovanför innehållet. En cookiebanner, annons eller widget som trycker ner sidan gör att allt hoppar till. Låt hellre en sådan banner ligga ovanpå sidan.
- Färre skript från andra. En dålig INP beror nästan alltid på för mycket JavaScript: tunga teman, slidrar, chattfönster och spårare. Granska varje plugin eller inbäddad tjänst kritiskt.
Vad servern gör
Allt börjar med serverns första respons, Time to First Byte (TTFB). Den är i sig ingen Core Web Vital, men med en långsam första respons är en bra LCP nästan omöjlig. Som riktvärde är 0,8 sekunder eller mindre bra. Orsaker är ofta en webbplats utan cache, för lite processorkraft eller omdirigeringar. Servern ska också skicka textfiler komprimerade (komprimering med gzip eller Brotli). Hur du åtgärdar serversidan läser du i Min webbplats är långsam eller använder för mycket CPU: så gör du den snabbare och i DirectAdmin-handboken, Min webbplats är långsam.
I AI Bouwer och WordPress
En webbplats från AI Bouwer sätter bredd och höjd för bilder vars mått är kända, laddar den första bilden på en sida direkt och med prioritet och resten först när de kommer i bild, och skapar en mindre version av stora bilder vid publicering. I WordPress hjälper en cache-plugin och förminskning av bilder mest. Det läser du i den kostnadsfria WordPress-kursen, lektionerna Vad gör en webbplats långsam, och hur mäter man det? och Bilder, PHP och andra hastighetsvinster.
Läs mer
- web.dev: Web Vitals (engelska)
- Om PageSpeed Insights (engelska)
- Google: sidupplevelse och Google Sök (engelska)
- Google: rapporten Sidans vitalitet