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

Google PageSpeed Insights er nyttigt, men det er nemt at læse forkert. Rapporten blander rigtige brugerdata, labdata, Lighthouse-diagnostik, Core Web Vitals og en synlig score. Hvis de signaler behandles som én simpel karakter, bliver det forkerte arbejde ofte prioriteret.

For et dansk virksomhedswebsite er det nyttige spørgsmål ikke, om siden scorer 92 eller 67. Det nyttige spørgsmål er, om de sider, der skaber henvendelser, salg, bookinger eller tillid, er hurtige nok for rigtige brugere på rigtige enheder.

Start med den side, der testes

Før du læser rapporten, skal du kontrollere, om den rigtige URL er testet.

En forsidescore er sjældent nok. Et dansk website kan være afhængigt af ydelsessider, produktsider, kontaktformularer, bookingflows, checkout, lokale landingssider eller indholdssider. De sider kan indlæse andre billeder, scripts, formularer, kort, tracking, betalingsværktøjer eller embeds end forsiden.

Hvis den vigtige side ikke testes, kan rapporten se pæn ud, mens det forretningskritiske flow stadig er langsomt.

Forstå feltdata først

Feltdata er rigtige brugerdata, når PageSpeed Insights har nok data til rådighed. De kommer fra Chrome User Experience Report og afspejler, hvordan rigtige Chrome-brugere har oplevet siden eller sitets origin over en nyere indsamlingsperiode.

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

Læs feltdata før scoren, når de findes. Kig især på:

• Om data gælder den præcise URL eller hele origin
• Om mobil og desktop 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

Feltdata kan mangle for nye sider, små sider, lavtrafikerede sider, private sider eller sider uden nok Chrome UX Report-data. Manglende feltdata betyder ikke, at siden er hurtig. Det betyder, at PageSpeed Insights ikke har nok rigtige brugerdata for 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, checkout, menuen eller bookingflowet bliver brugbart for sent. En side kan også fejle én måling på grund af en bestemt template 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 scoren som et lab-signal

Den store performance-score bygger på en Lighthouse-labtest. Den er ikke det samme som rigtige brugerdata.

Scoren er nyttig til at sammenligne kontrollerede tests, især før og efter tekniske ændringer. Den er mindre nyttig som forretnings-KPI. En højere score betyder ikke automatisk flere henvendelser, og en lavere score betyder ikke, at alle anbefalinger skal implementeres.

Brug scoren til at stille bedre spørgsmål:

• Faldt scoren efter en release?
• Er mobil meget dårligere end desktop?
• Forbedrede en konkret rettelse lab-resultatet?
• Gentager de samme problemer sig på vigtige templates?

Brug ikke scoren som hele opgavelisten.

Skil labdata fra feltdata

Labdata er en kontrolleret test. Feltdata er det, rigtige brugere har oplevet.

Begge dele betyder noget, men de svarer på forskellige spørgsmål.

Signal	Hvad det fortæller	Vigtig begrænsning
Feltdata	Hvordan rigtige brugere oplevede siden eller origin	Kan mangle, være aggregeret eller være forsinket
Labdata	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 feltdata er dårlige, men labtesten ser god ud, skal du kigge på trafikmønstre, tredjepartsvariation, geografi, device-mix eller sider, der afviger fra den testede URL. Hvis labdata er dårlige, men feltdata ser fine ud, bør problemerne stadig gennemgås, men prioriteres efter forretningsmæssig betydning.

Læs diagnostikken som spor, ikke ordrer

PageSpeed Insights viser diagnostik og anbefalinger fra Lighthouse-kørslen. De er nyttige, men de er ikke automatisk backloggen.

Typiske fund handler om billedstørrelser, ubrugt JavaScript, render-blokerende ressourcer, tung main thread, tredjepartsscripts, font loading, cachepolitik, layout shifts og serverresponstid.

Det praktiske spørgsmål er altid: hvilket fund forklarer det problem, brugerne mærker?

Eksempler:

• Hvis LCP er dårlig, kig på serverrespons, hovedbilledet, render-blokerende CSS og hvornår hovedindholdet vises.
• Hvis CLS er dårlig, kig på billeddimensioner, dynamiske bannere, embeds, sene fonte og bookingwidgets.
• Hvis INP er dårlig, kig på JavaScript-belastning, long tasks, event handlers og tunge komponenter omkring formularer eller menuer.

Den samme advarsel kan være vigtig på ét site og næsten ligegyldig på et andet.

Tjek mobil og desktop hver for sig

Mobil- og desktoprapporter skal læses hver for sig.

For mange danske virksomheder er mobilvisningen vigtigst, fordi kunder sammenligner ydelser, finder kontaktoplysninger, sender formularer eller starter booking fra telefonen.

Desktop kan stadig være vigtigt for B2B, administration, større køb og intern gennemgang. Men en god desktopscore 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 skal bruge waterfall, filmstrip, repeat view, testlokation eller detaljeret request timing.
• Brug Search Console, når du skal se Google-specifikke Core Web Vitals-feltdata på tværs af sitet.
• Brug browserens DevTools, når du skal inspicere netværk, JavaScript-fejl, layout, headers eller caching.

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å et mindre dansk website 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 layout shifts
• Reducér JavaScript omkring menuer, filtre, bookingwidgets og formularer
• Forbedr cache headers og CDN-levering
• Tjek serverresponstid før små front-end-detaljer optimeres

De bedste rettelser er normalt knyttet til templates og brugerflows, 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
• Lighthouse performance scoring documentation

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 reel performance

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 et dansk website 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.