Mange WordPress-ejere stirrer sig blinde på den grønne score i PageSpeed Insights. Men den store tal-score er primært lab data - en simuleret Lighthouse-test. Det Google bruger til page experience, er i højere grad field data fra rigtige brugere via Chrome UX Report (CrUX).

Derfor kan din side “score 90” i lab og stadig have dårlige Core Web Vitals i Search Console. Det er ikke, fordi værktøjet er ødelagt. Det er, fordi du sammenligner to forskellige ting.

Hvad er lab data?

Lab data er en test under kontrollerede forhold: en bestemt enhed, netværksprofil og cache-tilstand. Lighthouse (som driver lab-delen i PSI) er god til at pege på konkrete tekniske problemer:

Lab er altså et diagnostikværktøj. Det svarer på: “Hvad kan jeg rette i koden og opsætningen?” Det svarer ikke nødvendigvis på: “Hvordan oplever mine danske mobilbrugere siden i aften?”

Hvad er field data (CrUX)?

Field data er anonymiserede målinger fra rigtige Chrome-brugere på din origin (domæne). Her ser du LCP, INP og CLS, som de faktisk opleves - på langsomme telefoner, ustabilt net, med cookies, extensions og den chat-widget, der kun loader i produktion.

  • Kræver nok trafik, før Google viser data
  • Opdateres over tid (typisk et rullende ~28-dages vindue)
  • Er det, der tæller for “page experience” i praksis

I PageSpeed Insights ser du field-delen øverst (når der er data) og lab-delen længere nede. Mange kigger kun på den store cirkel-score. Den er lab.

Hvorfor tallene divergerer

Når lab er grøn og field er rød - eller omvendt - er forklaringen næsten altid en af disse:

  • Du tester den forkerte URL. Lab kører ofte forsiden. Dine brugere lander på produktsider, kategorier eller blogindlæg med tungere templates.
  • Produktion ≠ testmiljø. Chat, A/B-tests, cookie-banners og marketing-pixels loader forskelligt, når der er rigtig trafik.
  • Geo og cache. TTFB og LCP varierer med CDN, cache-hit og hvor brugeren sidder.
  • INP er svær at simulere. Lab kan vise TBT-hints, men field-INP afhænger af, hvad brugerne faktisk klikker på.
  • Enhedsfordeling. CrUX indeholder mange mid-range Android-telefoner. Din MacBook-test er ikke repræsentativ.

Hvad du bør optimere efter

  1. Sandhed: Search Console → Core Web Vitals (eller CrUX) for de URL-grupper, der fejler.
  2. Diagnose: PSI/Lighthouse på de samme URL’er for at finde tekniske årsager.
  3. Prioritering: Ret det, der påvirker field på forretningskritiske sider - ikke kun forsiden.
  4. Tålmodighed: Efter rettelser bliver lab grøn først. Field følger, når vinduet er rullet videre.

En praktisk rækkefølge på WordPress er ofte: cache og TTFB → LCP-billede/CSS → JavaScript/INP → CLS (dimensioner og banners). Brug ordbogen til de enkelte audits, når PSI nævner dem.

Sådan læser du en PSI-rapport uden at blive snydt

  • Har field-data? Start der. Rød LCP i field er vigtigere end en gul lab-detalje.
  • Ingen field-data endnu? Brug lab + Real User Monitoring (hvis du har det), og mål mobil manuelt.
  • Kig på “Hvilke URL’er?” i Search Console - ikke kun origin-niveau.
  • Gentag testen flere gange. En enkelt lab-kørsel svinger, især på delt hosting.

Eksempel: grøn lab, rød field

En shop kan score højt i lab, fordi full page cache og et optimeret hero-billede gør forsiden lynhurtig i Lighthouse. Samtidig kan produktsider have store gallerier, variation-JS og cart fragments, som trækker field-LCP og INP ned for dem, der faktisk køber. Løsningen er ikke “mere lab-score på forsiden” - det er at måle og rette produkt- og checkout-templates.

Kort sagt

Lab fortæller dig, hvad du kan rette. Field fortæller dig, om rettelsen virkede for rigtige brugere. Brug begge - men lad field være dommeren, når der er data nok.

Har du grøn lab-score men rød field-data? Skriv til mig - så finder vi gap’et mellem test og virkelighed. Du kan også starte med et hurtigt helbredstjek.