- Udgivet
- Opdateret
Sådan læser du en PageSpeed Insights-rapport
Google PageSpeed Insights er nyttigt, men det er nemt at læse forkert. Rapporten blander data fra virkelige brugere, laboratoriedata, Lighthouse-fund, Core Web Vitals og et synligt resultattal. Hvis de signaler behandles som én simpel karakter, bliver det forkerte arbejde ofte prioriteret.
Om siden får 92 eller 67 point, betyder mindre end, om de sider, der skaber henvendelser, salg, reservationer eller tillid, er hurtige nok for virkelige brugere på deres egne enheder. Når du ved, hvordan PageSpeed Insights indsamler sine data og beregner sit resultattal, bliver det langt nemmere at skelne de to ting fra hinanden.
Start med den side, der testes
Før du læser rapporten, skal du kontrollere, om den rigtige URL er testet.
Et resultat for forsiden er sjældent nok. En hjemmeside kan være afhængig af ydelsessider, produktsider, kontaktformularer, bookingforløb, betalingstrin, landingssider eller indholdssider. De sider kan indlæse andre billeder, scripts, formularer, kort, måleværktøjer, betalingsværktøjer eller indlejret indhold end forsiden.
Hvis den vigtige side ikke testes, kan rapporten se pæn ud, mens det forretningskritiske forløb stadig er langsomt.
Forstå data fra virkelige brugere først
Når PageSpeed Insights har tilstrækkelige data, viser rapporten oplevelser fra virkelige brugere. Dataene kommer fra Chrome User Experience Report (CrUX): målinger fra Chrome-brugere, der har givet samtykke, samlet over de seneste 28 dage og opdateret dagligt.
Det er den sektion, der svarer på: oplever rigtige brugere siden som hurtig, stabil og responsiv?
Tre detaljer i den måde, Google samler dataene på, ændrer, hvordan du bør læse dem:
- Hver måling vises ved 75. percentil. En LCP på 2,4 sekunder betyder, at tre ud af fire besøg havde det største indhold vist inden for 2,4 sekunder, mens hvert fjerde besøg var langsommere. Tallet hælder bevidst mod de langsomme oplevelser, ikke mod gennemsnitsbesøget.
- Perioden er de seneste 28 dage. En rettelse, der blev sat i drift i går, flytter næsten ikke brugerdataene. Regn med omkring fire uger, før ændringen slår fuldt igennem.
- Data for URL’en erstattes af data for domænet. Hvis den præcise URL har for få målinger, viser PageSpeed Insights i stedet tal for hele domænet. De tal blander forsiden, artiklerne og alle andre sider, så de kan både skjule en langsom skabelon og få den til at se bedre ud, end den er.
De farvede bjælker under hver måling viser fordelingen: hvor stor en andel af besøgene der var gode, kunne forbedres eller var dårlige. En side kan ligge lige inden for “god” ved 75. percentil og stadig have en betydelig rød andel. Det er værd at vide, hvis den andel er de mobilbrugere, der forsøger at bestille.
Læs brugerdataene før resultattallet, når de findes. Kig især på:
- Om data gælder den præcise URL eller hele domænet
- Om mobil og computer fortæller forskellige historier
- Om siden består Core Web Vitals
- Hvilken måling der er svag: LCP, CLS eller INP
- Om problemet passer med rigtige brugerklager eller mistede henvendelser
Brugerdata kan mangle for nye eller private sider og sider med lav trafik. Manglende data betyder ikke, at siden er hurtig. Det betyder blot, at PageSpeed Insights ikke har tilstrækkelige oplysninger om virkelige brugere til den visning.
Kend Core Web Vitals-grænserne
PageSpeed Insights samler Core Web Vitals omkring indlæsning, visuel stabilitet og responsivitet.
De aktuelle offentlige grænser er:
- Largest Contentful Paint (LCP): god ved 2,5 sekunder eller hurtigere
- Cumulative Layout Shift (CLS): god ved 0,1 eller lavere
- Interaction to Next Paint (INP): god ved 200 millisekunder eller hurtigere
Vurderingen af, om siden består eller ej, følger en bestemt regel. Når alle tre målinger har nok data, skal alle tre være gode ved 75. percentil. Hvis INP mangler data, hvilket er almindeligt på sider med få interaktioner, er det nok, at LCP og CLS består. Hvis LCP eller CLS mangler data, bliver siden eller domænet slet ikke vurderet.
Læs ikke tallene mekanisk. En side kan teknisk bestå og stadig føles dårlig, hvis kontaktformularen, betalingen, menuen eller bookingforløbet bliver brugbart for sent. En side kan også fejle én måling på grund af en bestemt skabelon eller et tredjepartsscript, som kræver fokuseret arbejde frem for en fuld genopbygning.
Målingerne er forklaret mere detaljeret i Core Web Vitals-guiden.
Sådan beregnes resultattallet
Det store resultattal for hastighed kommer fra én enkelt Lighthouse-test i et kontrolleret miljø, ikke fra brugerdata. Lighthouse indlæser siden én gang under faste forhold (på mobil en simuleret mellemklassetelefon på en neddroslet forbindelse), måler fem ting og lægger dem sammen til ét tal.
I Lighthouse 10 er vægtningen:
| Laboratoriemåling | Vægt | Hvad den dækker |
|---|---|---|
| Total Blocking Time (TBT) | 30% | Hvor længe hovedtråden var blokeret under indlæsningen |
| Largest Contentful Paint (LCP) | 25% | Hvornår hovedindholdet blev vist |
| Cumulative Layout Shift (CLS) | 25% | Hvor meget layoutet flyttede sig |
| First Contentful Paint (FCP) | 10% | Hvornår der først blev vist noget |
| Speed Index | 10% | Hvor hurtigt den synlige del af siden blev fyldt ud |
INP indgår ikke i resultattallet. En test, der kun indlæser siden, klikker ikke på noget og kan derfor ikke måle, hvor hurtigt siden reagerer. Total Blocking Time er laboratoriets erstatning: tungt JavaScript, der blokerer hovedtråden under indlæsningen, gør typisk også interaktioner langsomme. Derfor kan en side få over 90 point og stadig fejle INP i brugerdataene, for eksempel når en bookingwidget eller et filter først bliver tungt, når nogen bruger det.
Hver måling omregnes til et tal mellem 0 og 100 ud fra en kurve, der bygger på data fra rigtige hjemmesider i HTTP Archive. En værdi svarende til 25. percentil af hjemmesiderne giver 50 point. En værdi svarende til 8. percentil, altså hurtigere end omkring 92% af hjemmesiderne, giver 90 point. Over cirka 96 kræver hvert ekstra point en uforholdsmæssigt stor forbedring. At gå fra 70 til 90 er som regel godt brugt udviklingstid. At gå fra 96 til 100 er det sjældent.
Resultattallet svinger også mellem kørsler, uden at siden er ændret. Netværkets rute, belastningen på testmaskinen, A/B-tests og annoncer, der skifter mellem kørslerne, flytter alle tallet. Betragt en forskel på få point som støj, og sammenlign flere kørsler, før du konkluderer, at noget er blevet dårligere.
Det gør resultattallet nyttigt til at sammenligne kontrollerede tests, især før og efter tekniske ændringer. Det er mindre nyttigt som forretningsmål. Brug det til at stille bedre spørgsmål:
- Faldt resultatet efter en udrulning?
- Er mobil meget dårligere end computer?
- Forbedrede en konkret rettelse laboratorieresultatet?
- Gentager de samme problemer sig i vigtige skabeloner?
Brug ikke resultattallet som hele opgavelisten.
Skil laboratoriedata fra data fra virkelige brugere
Laboratoriedata kommer fra en kontrolleret test. Brugerdata viser det, virkelige brugere har oplevet.
Begge dele betyder noget, men de svarer på forskellige spørgsmål.
| Signal | Hvad det fortæller | Vigtig begrænsning |
|---|---|---|
| Brugerdata | Hvordan virkelige brugere oplevede siden eller domænet | Kan mangle, være samlet eller være forsinket |
| Laboratoriedata | Hvad der skete i én kontrolleret Lighthouse-test | Matcher ikke alle enheder, netværk eller brugerforhold |
| Diagnostik | Sandsynlige årsager og tekniske spor | Kræver teknisk vurdering før implementering |
Hvis brugerdataene er dårlige, men laboratorietesten ser god ud, skal du kigge på trafikmønstre, variation hos tredjeparter, geografi, fordelingen af enheder eller sider, der afviger fra den testede URL. Hvis laboratoriedataene er dårlige, men brugerdataene ser fine ud, bør problemerne stadig gennemgås og prioriteres efter deres betydning for forretningen.
Hvad PageSpeed Insights-API’et returnerer
Opbygningen bag rapporten bliver tydeligere, når du ser på det rå svar fra PageSpeed Insights-API’et. Et kald til runPagespeed med en URL og en strategi (mobile eller desktop) returnerer tre adskilte blokke:
loadingExperience: brugerdata for den præcise URL med hver målings værdi ved 75. percentil, fordelingen og en samlet kategori.originLoadingExperience: de samme brugerdata for hele domænet.lighthouseResult: laboratorietesten med Lighthouse-version, alle fund og resultaterne for hver kategori. De gemmes som decimaltal mellem 0 og 1 og vises ganget med 100.
Rapportsiden er de tre kilder stillet op ved siden af hinanden. De måles forskelligt, dækker forskellige perioder og kan være uenige, uden at noget er galt.
URL-analysen her på siden kalder API’et med mobilstrategien. Den bruger brugerdata for URL’en, når Google har dem, falder tilbage til domænets data, når de mangler, og registrerer, hvilken af de to den har brugt, fordi et domæne, der består, kan skjule en langsom side. Den gemmer også Lighthouse-versionen og eventuelle advarsler fra kørslen, som forklarer mange ændringer i resultattallet, der ikke skyldes selve siden.
Én ændring er værd at planlægge efter: Ifølge Googles API-dokumentation vil CrUX-brugerdata ikke længere blive inkluderet i PageSpeed Insights-API’et, og Google anbefaler CrUX API eller CrUX History API i stedet. Der er ikke meldt nogen dato ud. Hvis du bygger overvågning på PageSpeed Insights-API’et, så hold opslaget af brugerdata adskilt, så det kan flyttes til CrUX API uden at resten skal skrives om.
Læs diagnostikken som spor, ikke ordrer
PageSpeed Insights viser fund og anbefalinger fra Lighthouse-kørslen. De er nyttige, men udgør ikke automatisk opgavelisten.
Typiske fund handler om billedstørrelser, ubrugt JavaScript, ressourcer der blokerer visningen, en overbelastet hovedtråd, tredjepartsscripts, indlæsning af skrifttyper, cachepolitik, layoutforskydninger og serverens svartid.
Det afgørende spørgsmål er altid: hvilket fund forklarer det problem, brugerne mærker?
Eksempler:
- Hvis LCP er dårlig, så kig på serverens svartid, hovedbilledet, CSS der blokerer visningen, og hvornår hovedindholdet vises.
- Hvis CLS er dårlig, så kig på billeddimensioner, dynamiske bannere, indlejret indhold, sent indlæste skrifttyper og bookingwidgets.
- Hvis INP er dårlig, så kig på JavaScript-belastning, langvarige opgaver, hændelseshåndtering og tunge komponenter omkring formularer eller menuer.
Den samme advarsel kan være vigtig på én hjemmeside og næsten ligegyldig på en anden.
Kontrollér mobil og computer hver for sig
Rapporter for mobil og computer skal læses hver for sig.
For mange virksomheder er mobilvisningen vigtigst, fordi kunder sammenligner ydelser, finder kontaktoplysninger, sender formularer eller starter booking fra telefonen.
Computeroplevelsen kan stadig være vigtig for B2B, administration, større køb og intern gennemgang. Men et godt resultat på computer må ikke skjule en dårlig mobiloplevelse.
Vælg hvornår du skal bruge et andet værktøj
PageSpeed Insights er et startpunkt, ikke hele undersøgelsen.
Gå videre til et andet værktøj, når rapporten rejser spørgsmål, den ikke selv kan besvare:
- Brug Lighthouse i Chrome DevTools, når du skal reproducere og teste rettelser lokalt.
- Brug WebPageTest, når du har brug for netværksforløb, billedsekvens, gentaget indlæsning, teststed eller detaljeret tidsforbrug pr. forespørgsel.
- Brug Search Console, når du skal se Googles Core Web Vitals-data fra virkelige brugere på tværs af hjemmesiden.
- Brug browserens DevTools, når du skal undersøge netværk, JavaScript-fejl, layout, HTTP-headere eller cache.
Guiden om PageSpeed Insights, Lighthouse og WebPageTest forklarer, hvordan værktøjerne passer sammen.
Omsæt rapporten til arbejde
En PageSpeed-rapport bør ende i en kort, prioriteret liste, ikke et stort oprydningsprojekt.
På en mindre hjemmeside ligner nyttige næste skridt ofte:
- Komprimér eller udskift hovedbilledet på vigtige sider
- Prioritér det reelle LCP-element
- Fjern eller udskyd ikke-nødvendige tredjepartsscripts
- Angiv billeddimensioner, og reserver plads for at reducere layoutforskydninger
- Reducér JavaScript omkring menuer, filtre, bookingwidgets og formularer
- Forbedr cacheheadere og CDN-levering
- Kontrollér serverens svartid, før små detaljer i browseren optimeres
De bedste rettelser er normalt knyttet til skabeloner og brugerforløb, ikke isolerede advarsler.
Officielle kilder
PageSpeed Insights ændrer sig over tid, så de præcise interface-detaljer bør tjekkes i officiel dokumentation. Nyttige kilder:
- Google PageSpeed Insights documentation
- Dokumentation af PageSpeed Insights-API’et
- web.dev Core Web Vitals documentation
- Dokumentation af Lighthouse-resultater for hastighed
Brug dokumentationen til præcise detaljer om interface og målinger. Brug selve rapporten som hjælp til undersøgelsen, ikke som erstatning for vurdering.
Fra rapport til en reelt hurtigere hjemmeside
Det reelle resultat er ikke en pænere rapport. Det er en side, der viser nyttigt indhold hurtigt, forbliver stabil, reagerer på interaktion og hjælper brugeren videre.
Hvis en hjemmeside har en PageSpeed-rapport, der er svær at tolke, kan du sende mig URL’en og rapportens kontekst. Jeg kan hjælpe med at skelne støj fra nyttigt arbejde og pege på konkrete rettelser.