Sådan læser du PageSpeed Insights: Core Web Vitals i almindeligt sprog
Du har testet dit website i PageSpeed Insights og ser et rødt tal, for eksempel 45. Hvad betyder det, og hvor slemt er det? I denne artikel kan du læse, hvordan du læser rapporten, hvad de tre Core Web Vitals måler, og hvad du selv kan forbedre.
De tre målinger
| Måling | Hvad den måler | Godt | Forbedring nødvendig | Dårligt |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | Hvor hurtigt det største stykke indhold vises, ofte det store billede øverst | op til 2,5 s | 2,5 til 4 s | over 4 s |
| INP (Interaction to Next Paint) | Hvor hurtigt siden reagerer, når du klikker, trykker eller skriver | op til 200 ms | 200 til 500 ms | over 500 ms |
| CLS (Cumulative Layout Shift) | Hvor meget siden flytter sig under indlæsning (en score, ikke en tid) | op til 0,1 | 0,1 til 0,25 | over 0,25 |
En side opfylder Core Web Vitals, hvis mindst 75 procent af besøgene scorer godt på alle tre, separat for mobil og desktop. Det er altså ikke din hurtige computer, der tæller, men oplevelsen for de fleste besøgende, også på en ældre telefon. INP erstattede i marts 2024 den ældre måling FID. Støder du stadig på FID, er den information forældet.
Feltdata og labdata
PageSpeed Insights viser to typer målinger, og de giver ofte forskellige tal:
- Feltdata (øverst): målinger hos rigtige besøgende med Chrome over de seneste 28 dage. Dette afgør, om du opfylder Core Web Vitals. Har din side for få besøgende, ser du tallene for hele dit website, eller slet ingen feltdata.
- Labdata (nedenunder): en test med Lighthouse, der indlæser siden én gang på en simuleret mellemklasse telefon og forbindelse. Her kommer tallet fra 0 til 100 fra. Lighthouse kan ikke måle INP, for der er ingen, der klikker.
Brug labdata til at finde årsager og til straks at se, om en forbedring virker. Begynd på fanen Mobil: her er det som regel værre, og Google kigger primært på den mobile version af dit website.
Hvor meget vejer det i Google?
Google skriver, at Core Web Vitals tæller med i rangeringen. Men Google viser altid det mest relevante indhold, også hvis den side ikke er den hurtigste. Tallet fra 0 til 100 kommer fra labtesten og er ikke en vurdering fra Google; den vurdering kommer fra feltdata. At opnå en perfekt score udelukkende for Google er ifølge Google selv ikke den bedste brug af din tid. Sørg for at ligge i det grønne eller mindst det orange område, især fordi besøgende falder fra på en langsom eller hoppende side.
Hvad du forbedrer på selve siden
- Mindre billeder. Et billede på tusindvis af pixels bredt til et felt på 800 pixels er den mest almindelige årsag til en langsom LCP. Formindsk billeder før upload, og brug et moderne format som WebP eller AVIF.
- Bredde og højde på hvert billede. Uden
widthogheightved browseren ikke, hvor meget plads et billede kræver, og teksten hopper, når billedet indlæses. Det øger CLS:<img src="bloemstuk.webp" width="800" height="600" alt="Bruidsboeket med hvide roser">
- Indlæs ikke det vigtigste billede dovent.
loading="lazy"er godt til billeder længere nede, men ikke til det billede, der allerede er synligt ved åbning. Ellers venter browseren netop med det billede, der afgør din LCP. - Indsæt ikke noget senere over indholdet. En cookiebanner, annonce eller widget, der skubber siden nedad, får alt til at hoppe. Lad hellere sådan en banner ligge henover siden.
- Færre scripts fra andre. En dårlig INP skyldes næsten altid for meget JavaScript: tunge temaer, sliders, chatvinduer og trackere. Se kritisk på hvert plugin eller indlejret tjeneste.
Hvad serveren gør
Alt begynder med serverens første svar, Time to First Byte (TTFB). Den er ikke selv en Core Web Vital, men med et langsomt første svar er en god LCP næsten umulig. Som vejledende værdi er 0,8 sekund eller mindre godt. Årsager er ofte en side uden cache, for lidt regnekraft eller omdirigeringer. Serveren bør også sende tekstfiler komprimeret (komprimering med gzip eller Brotli). Hvordan du håndterer serversiden, kan du læse i Mit website er langsomt eller bruger for meget CPU: sådan gør du det hurtigere og i DirectAdmin-vejledningen, Mit website er langsomt.
I AI Builder og WordPress
En side fra AI Builder angiver bredde og højde på billeder, hvor målet er kendt, indlæser det første billede på en side direkte og med prioritet, og først resten, når de kommer i syne, og laver ved publicering en mindre version af store billeder. I WordPress hjælper et cacheplugin og formindskelse af billeder mest. Det kan du læse om i det gratis WordPress-kursus, lektionerne Hvad gør en side langsom, og hvordan måler du det? og Billeder, PHP og andre hastighedsgevinster.
Læs mere
- web.dev: Web Vitals (engelsk)
- Om PageSpeed Insights (engelsk)
- Google: sidens oplevelse og Google Søgning (engelsk)
- Google: rapporten om sidens oplevelse