Les PageSpeed Insights: Core Web Vitals i vanlig språk
Du har testet nettstedet ditt i PageSpeed Insights og ser et rødt tall, for eksempel 45. Hva betyr det, og hvor alvorlig er det? I denne artikkelen leser du hvordan du leser rapporten, hva de tre Core Web Vitals måler, og hva du selv kan forbedre.
De tre målingene
| Måling | Hva den måler | Bra | Forbedring nødvendig | Dårlig |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | Hvor raskt det største innholdselementet vises, ofte det store bildet øverst | opptil 2,5 s | 2,5 til 4 s | over 4 s |
| INP (Interaction to Next Paint) | Hvor raskt siden reagerer når du klikker, trykker eller skriver | opptil 200 ms | 200 til 500 ms | over 500 ms |
| CLS (Cumulative Layout Shift) | Hvor mye siden hopper under lasting (en poengsum, ikke en tid) | opptil 0,1 | 0,1 til 0,25 | over 0,25 |
En side oppnår Core Web Vitals hvis minst 75 prosent av besøkene scorer bra på alle tre, separat for mobil og desktop. Det er altså ikke din raske datamaskin som teller, men opplevelsen til de fleste besøkende, også på en eldre telefon. INP erstattet den eldre målingen FID i mars 2024. Støter du fortsatt på FID, er den informasjonen utdatert.
Feltdata og labdata
PageSpeed Insights viser to typer målinger, og de gir ofte forskjellige tall:
- Feltdata (øverst): målinger fra ekte besøkende med Chrome de siste 28 dagene. Dette avgjør om du oppnår Core Web Vitals. Har siden din for få besøkende, ser du tallene for hele nettstedet, eller ingen feltdata i det hele tatt.
- Labdata (under): en test med Lighthouse, som laster siden én gang på en simulert middels telefon og forbindelse. Her kommer tallet fra 0 til 100 fra. Lighthouse kan ikke måle INP, for det er ingen som klikker.
Bruk labdata til å finne årsaker og til å se umiddelbart om en forbedring hjelper. Begynn med fanen Mobil: der er det som regel verre, og Google ser hovedsakelig på mobilversjonen av nettstedet ditt.
Hvor mye teller det for Google?
Google skriver at Core Web Vitals teller med i rangeringen. Men Google viser alltid det mest relevante innholdet, selv om den siden ikke er den raskeste. Tallet fra 0 til 100 kommer fra labtesten og er ikke en vurdering fra Google. Den vurderingen kommer fra feltdata. Å oppnå en perfekt score bare for Google er ifølge Google selv ikke den beste bruken av tiden din. Sørg for at du ligger i det grønne eller i det minste det oransje området, særlig fordi besøkende forlater en treg eller hoppende side.
Hva du forbedrer på selve siden
- Mindre bilder. Et bilde på tusenvis av piksler bredt for et felt på 800 piksler er den vanligste årsaken til en treg LCP. Forminsk bilder før opplasting og bruk et moderne format som WebP eller AVIF.
- Bredde og høyde på hvert bilde. Uten
widthogheightvet nettleseren ikke hvor mye plass et bilde trenger, og teksten hopper når det kommer inn. Det øker CLS:<img src="bloemstuk.webp" width="800" height="600" alt="Bruidsboeket met witte rozen">
- Ikke lat innlasting av det viktigste bildet.
loading="lazy"er bra for bilder lenger ned, men ikke for bildet som allerede vises når siden åpnes. Ellers venter nettleseren nettopp med bildet som avgjør LCP-en din. - Ikke sett inn noe over innholdet senere. En informasjonskapsellinje, annonse eller widget som dytter siden nedover, får alt til å hoppe. La en slik linje heller ligge over siden.
- Mindre skript fra andre. En dårlig INP skyldes nesten alltid for mye JavaScript: tunge temaer, glidebrytere, chattevinduer og sporingsverktøy. Vurder kritisk hvert enkelt tillegg eller innebygde tjeneste.
Hva serveren gjør
Alt begynner med serverens første respons, Time to First Byte (TTFB). Den er ikke selv en Core Web Vital, men med en treg første respons er en god LCP nesten umulig. Som retningslinje er 0,8 sekunder eller mindre bra. Årsaker er ofte et nettsted uten cache, for lite regnekraft eller omdirigeringer. Serveren bør også sende tekstfiler komprimert (komprimering med gzip eller Brotli). Hvordan du tilpasser serversiden, kan du lese om i Nettstedet mitt er tregt eller bruker for mye CPU: slik gjør du det raskere og i DirectAdmin-veiledningen, Nettstedet mitt er tregt.
I AI Bouwer og WordPress
Et nettsted fra AI Bouwer setter bredde og høyde på bilder der størrelsen er kjent, laster det første bildet på en side direkte og med prioritet, og resten først når de kommer i bildet, og lager en mindre versjon av store bilder ved publisering. I WordPress hjelper en cache-plugin og forminskning av bilder mest. Det kan du lese om i det gratis WordPress-kurset, leksjonene Hva gjør et nettsted tregt, og hvordan måler du det? og Bilder, PHP og andre hastighetsgevinster.
Les mer
- web.dev: Web Vitals (engelsk)
- Om PageSpeed Insights (engelsk)
- Google: sideopplevelse og Google Søk (engelsk)
- Google: rapporten Nettstedets vitalitet