Kort svar: PageSpeed Insights viser to slags data: lab-data (Lighthouse-scoren fra en simuleret, langsom enhed) og feltdata (CrUX – rigtige 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.
“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 dem ad – og gør dig immun over for de klassiske fejlslutninger.
Kontrolramme: WordPress 7.1 og PHP 8.4.23 udgør versionsgrundlaget pr. 30. august 2026. Eksemplet i billedet er genskabt med illustrative tal.
Feltdata (øverst): Chrome-brugeres faktiske oplevelser på din side de seneste 28 dage – Core Web Vitals målt ved 75-percentilen. Det er de tal, Google bruger, 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-100. Den er et kontrolleret eksperiment: fremragende til at finde og reproducere problemer, ubrugelig som facitliste for virkeligheden:
Fire systematiske forskelle forklarer næsten alle uoverensstemmelser: enheden (lab simulerer en langsom mobil – dine besøgende har måske nyere telefoner på hurtigt dansk net), cachen (lab rammer ofte et koldt første-besøg; feltdata indeholder gengangere med varm cache), tiden (feltdata er 28 dages gennemsnit – din rettelse i går ses først gradvist) og målepunktet (lab måler én URL nu; felt kan vise hele origin). Deraf de to klassiske situationer: god score + dårlige feltdata betyder, at virkelige forhold (typisk mobil og tredjepartsscripts) er værre end testen – og dårlig score + gode feltdata betyder oftest bare, at dine brugere har bedre forhold end simulationen.
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, vægt, requests) – med den ro, at når selv en kunstigt langsom testenhed leverer pæne Core Web Vitals, gør dine rigtige besøgende det også. Search Consoles CWV-rapport har samme datakilde og samme begrænsning – læsningen af den står i Search Console-guiden.
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ålemålet ned (fx “LCP under 2,5 s i feltdata på mobil”) – så stopper diskussionen om, hvilken score der “tæller”.
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.
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 rent i tallene – og bekræft den i mellemtiden med lab-målinger.
Feltdata (PageSpeed/Search Console) som kompas hver måned; lab-værktøjer (Lighthouse, DevTools) som mikroskop, når noget skal findes og fikses. Kompas til retning, mikroskop til årsager – aldrig omvendt.
