PageSpeed Insights vs. virkelige brugere: lab-data og CrUX

Kort svar: PageSpeed Insights viser to slags data: lab-data (Lighthouse-scoren fra én simuleret kørsel på en langsom mobil) og feltdata (CrUX – rigtige Chrome-brugeres oplevelser gennem de seneste 28 dage). Feltdata er dommen; lab-data er værkstedet. Styr efter Core Web Vitals i feltdata, brug lab-tallene til at forklare og reproducere problemerne – og jag aldrig en 100-score, som dine rigtige besøgende ikke kan mærke.

Fagligt gennemgået: 2. oktober 2026

„Vores score er 62 – er sitet langsomt?“ Det korte svar: det kommer an på, hvilket af de to tal du kigger på. PageSpeed Insights blander to verdener på én side, og næsten al forvirring om hastighedsmåling kommer fra at forveksle dem.

Denne guide skiller feltdata og lab-data ad, forklarer hvorfor de er uenige, og viser hvordan du bruger dem hver til sit – så du kan træffe beslutninger på de tal, der faktisk tæller.

To slags data på én side

Feltdata (øverst): Chrome-brugeres faktiske oplevelser på din side de seneste 28 dage, hentet fra Chrome User Experience Report (CrUX). Core Web Vitals måles ved 75-percentilen, dvs. at tre ud af fire besøg skal være mindst så gode som tallet. Det er de tal, Google bruger i sin vurdering af sideoplevelsen, og de tal, dine kunder mærker.

Lab-data (nederst): én enkelt Lighthouse-kørsel på en simuleret mellemklasse-mobil med kunstigt langsomt netværk – deraf scoren fra 0 til 100. Den er et kontrolleret eksperiment: fremragende til at finde og reproducere problemer, men ikke en facitliste for virkeligheden:

De tre Core Web Vitals og grænserne

Feltdata vurderes på tre målinger. INP afløste FID som responsivitetsmåling i marts 2024, så ældre guides, der nævner FID, er forældede.

Måling	Hvad den måler	God	Dårlig
LCP (Largest Contentful Paint)	Hvornår det største indholdselement er synligt	Højst 2,5 s	Over 4 s
INP (Interaction to Next Paint)	Hvor hurtigt siden reagerer på klik, tryk og tastetryk	Højst 200 ms	Over 500 ms
CLS (Cumulative Layout Shift)	Hvor meget layoutet hopper	Højst 0,1	Over 0,25

Bemærk, at INP slet ikke kan måles i et lab-miljø uden brugerinteraktion. Lighthouse viser i stedet Total Blocking Time (TBT) som en indikator for, hvor meget JavaScript blokerer hovedtråden. En høj TBT er et varsel om dårlig INP – men ikke det samme tal.

Hvorfor de er uenige

Fire systematiske forskelle forklarer næsten alle uoverensstemmelser:

• Enheden: lab simulerer en langsom mobil – dine besøgende har måske nyere telefoner på hurtigt net.
• Cachen: lab rammer et koldt førstebesøg; feltdata indeholder gengangere med varm browsercache.
• Tiden: feltdata er et rullende vindue på 28 dage – din rettelse i går ses først gradvist.
• Målepunktet: lab måler én URL nu; feltdata kan vise hele domænet (origin), hvis den enkelte URL har for lidt trafik.

Deraf de to klassiske situationer. God score og dårlige feltdata betyder, at virkelige forhold – typisk ældre mobiler, cookiebannere og tredjepartsscripts, der indlæses efter testen er slut – er værre end testen. Dårlig score og gode feltdata betyder oftest bare, at dine brugere har bedre forhold end simulationen.

1. Start i feltdata

Består LCP, INP og CLS ved 75-percentilen? Så er opgaven vedligehold – ikke jagt på en højere score. Kig både på mobil og computer; mobil er næsten altid den svære del.

2. Skeln mellem URL og origin

Viser PageSpeed Insights origin-data, dækker tallene hele domænet. Problemet kan derfor bo på helt andre skabeloner end den, du tester – fx produktsider, kategorisider eller blogindlæg med tunge indlejringer. Search Consoles Core Web Vitals-rapport grupperer URL’er med samme problem og er det bedste sted at finde, hvilke skabeloner der trækker ned. Læsningen af den står i Search Console-guiden.

3. Brug lab-data som mikroskop

Fejler et felttal, så brug lab-delen til at finde årsagen: hvilket element er LCP, hvilke scripts blokerer, og hvad flytter sig. Diagnosen af netop det tal står i guiderne om LCP, INP og CLS. Til INP er Performance-panelet i Chrome DevTools mere brugbart end Lighthouse, fordi du selv kan klikke og se, hvilke opgaver der tager tid.

4. Gentag lab-målinger, før du konkluderer

Én kørsel svinger naturligt med netværk, serverbelastning og tredjepartsscripts. Kør tre målinger, og sammenlign medianen – og mål altid samme URL under samme forhold før og efter en ændring. Vil du køre Lighthouse lokalt, kan du gøre det fra kommandolinjen:

npx lighthouse https://dit-domæne.dk/ --only-categories=performance --output=json --output-path=./maaling-1.json

Gem resultaterne med dato, så du kan sammenligne over tid. Forskellige værktøjer (PageSpeed Insights, GTmetrix, Pingdom) måler forskelligt, så sammenlign aldrig tal på tværs af dem – se guiden om de tre fartmålere.

Når der ingen feltdata er

Mindre danske sites får ofte beskeden om, at der ikke er nok CrUX-data – trafikken er simpelthen for lille til statistikken. Så arbejder du efter lab-tallene og de tekniske mål (TTFB, sidevægt, antal requests) med den ro, at når selv en kunstigt langsom testenhed leverer pæne målinger, gør dine rigtige besøgende det typisk også. Search Consoles rapport har samme datakilde og samme begrænsning.

Vil du have egne feltdata uanset trafikmængde, kan du måle dem selv (Real User Monitoring). Googles open source-bibliotek web-vitals måler LCP, INP og CLS i besøgendes browsere og kan sende tallene til dit analyseværktøj. Husk, at det er indsamling af data fra besøgende, så det skal passe ind i din privatlivspolitik og samtykkeløsning.

Typiske fejlslutninger

• „Scoren faldt i dag, så sitet er blevet langsommere.“ Lab-scoren svinger mellem kørsler. Gentag målingen, og tjek feltdata, før du handler.
• „Vi har 98 på computer, så vi er færdige.“ Mobil er den svære del og den, de fleste besøgende bruger.
• „Forsiden er grøn, så hele sitet er grønt.“ Forsiden er sjældent den tungeste skabelon. Test de sider, der får trafik og omsætning.
• „Vi rettede det i går, men feltdata er uændrede.“ Det rullende 28-dages vindue gør, at forbedringen først ses gradvist.

5. Verificér, at du måler rigtigt

Du måler rigtigt, når dine beslutninger tages på feltdata (eller på medianen af flere lab-kørsler, hvor feltdata mangler), når hver optimering følges op med samme måling efter 28 dage – og når ingen i teamet længere rapporterer én enkelt Lighthouse-kørsel som „sitets hastighed“. Skriv målet ned (fx „LCP under 2,5 s i feltdata på mobil“) – så stopper diskussionen om, hvilken score der „tæller“.

Læs også

• Hub: WordPress performance og cache
• Core Web Vitals-rapporten i Search Console
• Dårlig INP i WordPress: find lange JavaScript-opgaver
• Sådan gør du en WordPress-side hurtigere: diagnose før plugins
• Hastighedsoptimering hos Hostious
• WordPress hosting hos Hostious – LiteSpeed og NVMe som udgangspunkt for gode feltdata

Ofte stillede spørgsmål om PageSpeed og CrUX

Påvirker Lighthouse-scoren min Google-placering?

Nej – Google bruger feltdata (Core Web Vitals), ikke lab-scoren. En side med score 60 og grønne feltdata står bedre end en med score 95 og røde. Scoren er et værktøj til dig, ikke et signal til Google.

Hvorfor ændrer feltdata sig ikke efter min rettelse?

Fordi de er et rullende 28-dages vindue: gamle, langsomme oplevelser fases gradvist ud. Regn med 2-4 uger, før en reel forbedring står tydeligt i tallene – og bekræft den i mellemtiden med lab-målinger.

Hvilket værktøj skal jeg så bruge til daglig?

Feltdata (PageSpeed Insights og Search Console) som kompas hver måned; lab-værktøjer (Lighthouse og DevTools) som mikroskop, når noget skal findes og rettes. Kompas til retning, mikroskop til årsager – aldrig omvendt.

Hvorfor viser lab-data ingen INP?

INP kræver rigtige brugerinteraktioner, som en automatisk sideindlæsning ikke har. Lighthouse viser i stedet Total Blocking Time som indikator. Vil du måle INP selv, så klik dig gennem siden med Performance-panelet i Chrome DevTools åbent.