Sådan læser du PageSpeed uden at jagte resultattallet

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.

På en virksomhedshjemmeside er det nyttige spørgsmål ikke, om siden får 92 eller 67 point. Det nyttige spørgsmål er, om de sider, der skaber henvendelser, salg, bookinger eller tillid, er hurtige nok for virkelige brugere på deres egne enheder.

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 og afspejler, hvordan Chrome-brugere har oplevet siden eller domænet over en nyere indsamlingsperiode.

Det er den sektion, der svarer på: oplever rigtige brugere siden som hurtig, stabil og responsiv?

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

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.

Behandl resultatet som en laboratoriemåling

Det store resultattal for hastighed bygger på en Lighthouse-test i et kontrolleret miljø. Det er ikke det samme som data fra virkelige brugere.

Resultattallet er nyttigt til at sammenligne kontrollerede tests, især før og efter tekniske ændringer. Det er mindre nyttigt som forretningsmål. Et højere resultat betyder ikke automatisk flere henvendelser, og et lavere resultat betyder ikke, at alle anbefalinger skal gennemføres.

Brug resultatet 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.

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
• 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.