Når du arbejder med Core Web Vitals, møder du to hovedkilder: Lighthouse (lab) og CrUX / Search Console (feltdata). De kan give modstridende tal - ikke fordi værktøjerne er “forkerte”, men fordi de måler forskellige ting under forskellige forhold. Denne artikel forklarer forskellen, de hyppigste årsager til mismatch, og en arbejdsgang så du prioriterer ud fra feltdata og debugger med lab.
Kort svar: Brug feltdata til at beslutte hvad der er problemet og hvor (hvilke URL-grupper). Brug Lighthouse og waterfall til at finde hvorfor på en konkret side - og accepter at lab kan se “grøn” ud, mens felt stadig er rødt, hvis dine rigtige brugere har langsommere net, svagere enheder eller andre adfærdsmønstre end testprofilen.
To typer data
- Lighthouse: kontrolleret test (lab)
- CrUX / Search Console: rigtige brugere over tid (field)
Hvis du arbejder med Core Web Vitals, støder du næsten altid på det samme problem: Lighthouse siger én ting, men Search Console/CrUX siger noget andet. Det kan føles som om målingerne er “forkerte”, men de måler i virkeligheden forskellige ting.
Det vigtigste at tage med er dette:
- CrUX/feltdata fortæller om den samlede brugeroplevelse over tid.
- Lighthouse/lab hjælper dig med at debugge og reproducere problemer i et kontrolleret miljø.
Når du bruger dem i den rigtige rækkefølge, bliver de et stærkt par: feltdata til prioritering, lab til fejlsøgning. Læs også ordbog: LCP, INP og CLS når du skal oversætte signaler til konkret arbejde.
Search Console, PageSpeed Insights og Lighthouse
- Google Search Console → Core Web Vitals-rapporten viser felt (CrUX) på URL-niveau hvor der er nok data. Brug den til at vælge hvilket problem og hvilke grupper I skal arbejde på.
- PageSpeed Insights (PSI) kombinerer ofte felt (når tilgængeligt) med lab (Lighthouse) for samme URL - praktisk til hurtigt at gå fra «rødt i felt» til konkrete lab-forslag.
- Lighthouse (i Chrome eller via PSI) er stadig lab: én profil, én kørsel - ideel til at finde hvorfor på den konkrete side, ikke til at erstatte CrUX-domænevidden.
Beslutningsmodel: hvilket værktøj hvornår?
| Situation | Start her | Dernæst |
|---|---|---|
| Vil vide om rigtige brugere har et problem | Search Console (felt) | Vælg repræsentativ URL → PSI |
| Vil debugge LCP/CLS på én side | Lighthouse + waterfall | Ret og mål lab først, vent på felt |
| INP / interaktion | Felt + DevTools Performance | Profiler den konkrete handling |
| Ingen feltdata (lav trafik) | Lab + egen RUM/staging | Brug realistiske netværksprofiler |
Hvad er Lighthouse helt konkret?
Lighthouse er en automatiseret test, der kører i et kontrolleret miljø. Typisk:
- fast device-profil (simuleret mobil)
- fast netværksprofil (throttling)
- en enkelt sidevisning ad gangen
Lighthouse er ekstremt nyttigt til at finde:
- render-blocking CSS/JS
- store billeder og tunge assets
- dårlige caching-mønstre
- CPU-tunge scripts
Men det er også en “syntetisk” måling: den kan ikke repræsentere alle dine rigtige brugere, alle netværkstyper, alle enheder og alle interaktionsmønstre.
Hvad Lighthouse ikke lover dig
Lab fortæller ikke, om en bestemt bruger på 3G og en ældre telefon får samme oplevelse. Den kan heller ikke automatisk genskabe dine egne flows (checkout, filter, intern søgning). Brug den derfor som forstørrelsesglas på en side ad gangen - ikke som facit for hele domænet.
Hvad er CrUX (og hvorfor er det så vigtigt)?
CrUX (Chrome UX Report) er feltdata baseret på rigtige Chrome-brugere. Search Console Core Web Vitals rapporten bygger på samme type data (aggregeret over tid, ofte 28 dage).
CrUX er stærkt, fordi det svarer på:
- hvordan går det for rigtige brugere?
- på hvilke URL-grupper?
- er problemet stabilt, eller var det en midlertidig regression?
Det er også derfor CrUX kan “haltere”: du ser ofte først effekten af ændringer efter noget tid.
Tærskler og percentiler (hvorfor “gennemsnit” er misvisende)
I feltdata arbejder du typisk med percentiler (fx 75. percentil): en lille gruppe meget langsomme besøg kan trække resultatet, selvom medianen ser fin ud. I lab får du ét køretøj - én simuleret session. Derfor kan to tal begge være “korrekte” og stadig være umulige at sammenligne direkte.
Hvorfor matcher de ikke? (de hyppigste årsager)
Her er de mest almindelige forklaringer, der reelt forklarer 90% af mismatch:
1) Lab er én test – felt er en hel verden
- Lab: én sidevisning i et kontrolleret miljø
- Felt: tusindvis af besøg på forskellige enheder og netværk
Hvis du har mange mobilbrugere på lav-end enheder, vil feltdata ofte være dårligere end Lighthouse, selv hvis Lighthouse “ser fint ud”.
2) Caching og CDN påvirker feltdata anderledes
Feltdata inkluderer ofte:
- gentagne besøg (varm cache)
- edge cache hits
- browser cache
Lighthouse kører ofte i en “mere ren” kontekst, hvor caching kan opføre sig anderledes. Det kan give både bedre eller dårligere resultater i lab.
3) Sider og URL-grupper bliver aggregeret
Search Console grupperer URL’er. Hvis nogle URL’er i en gruppe er langsomme, kan det “trække” hele gruppen ned.
Derfor er det ofte nyttigt at:
- tjekke hvilke URL’er der er i gruppen
- finde én “repræsentativ” URL og debugge den i lab
4) INP er særligt følsom for rigtige brugerflows
INP handler om interaktion. Lighthouse har begrænset mulighed for at simulere dine rigtige flows:
- menu, søgning, filter, formular
- modals, accordions, infinite scroll
Feltdata kan være dårligere, fordi rigtige brugere trigger tunge interaktioner (tredjepart, state updates, DOM-arbejde).
5) Varians: tid på dagen, server load, geografier
Hvis din server er langsommere i peak hours, eller hvis nogle brugere er langt fra origin, kan feltdata blive dårligere end lab.
Sådan bruger du Lighthouse og CrUX sammen (en praktisk proces)
Trin 1: Brug CrUX/Search Console til at vælge “hvad”
Find:
- hvilke signaler er dårlige (LCP/INP/CLS)?
- hvilke URL-grupper?
- er det desktop eller mobil?
Det svarer på: hvor skal du bruge din tid?
Trin 2: Vælg 1–3 repræsentative URL’er
Vælg URL’er der:
- får trafik
- er typiske for gruppen
- har stabilt indhold (så du kan reproducere)
Trin 3: Brug Lighthouse/WebPageTest til at finde “hvorfor”
Her leder du efter:
- TTFB og caching
- LCP-element og starttidspunkt
- render-blocking CSS/JS
- store assets
- CPU/JS-problemer (som påvirker INP)
Til årsagsanalyse er waterfall ofte mere præcis end én samlet score: du kan se om problemet er langsom HTML, sent startet LCP-billede, eller tunge scripts tidligt i kæden.
Trin 4: Implementér ændringer og mål igen
- Brug lab til at se om ændringen burde hjælpe
- Vent på feltdata til at bekræfte effekten
Husk at dokumentere hvad du ændrede (hero-billede, cache-header, udskudt script). Når feltdata først opdateres uger senere, er det værdifuldt at kunne spore effekten tilbage til en konkret deploy.
Når lab ser bedre ud end felt (eller omvendt)
Det er helt normalt:
- Felt værre end lab: mobil-andel, svage enheder, dårligere netværk end testprofilen, mere varierende serverlast, eller brugere der rammer langsomme URL’er i samme gruppe.
- Lab værre end felt: din lokale test rammer “kold” cache, mens rigtige brugere ofte har varm browsercache og CDN; eller du tester en side med tunge extensions/network conditions som ikke matcher produktion.
De tre løse punkter nedenfor er altså ikke fejl i værktøjerne - de er forskellige betingelser:
- Netværk og telefoner varierer i virkeligheden mere end i en fast Lighthouse-profil.
- Caching og CDN’er påvirker rigtige besøg - især gentagne sessioner.
- Interaktioner (især INP) kan være tungere i praksis end det Lighthouse simulerer.
Hvad hvis de stadig ikke matcher?
Hvis du stadig ser mismatch, så er næste niveau typisk:
- RUM (Real User Monitoring) for INP og interaktioner
- segmentering: device/geo/network
- server profiling og log-analyse for TTFB
Opsamling
- Vælg kamp ud fra feltdata (hvilken metrik, hvilken URL-gruppe).
- Debug på en repræsentativ URL med Lighthouse + waterfall.
- Forvent forsinkelse i Search Console efter rettelser - brug lab til hurtig feedback undervejs.
Relateret: Hvad er Core Web Vitals?, Sådan læser du en waterfall, INP vs FID.
Relaterede blogindlæg
Sådan prioriterer du hastighedsoptimering uden at spilde tid
2026-03-27Lær hvordan du prioriterer hastighedsoptimering rigtigt, så du starter med de ændringer der giver mest effekt på LCP, INP, CLS og TTFB.
Hvad er Core Web Vitals? LCP, INP og CLS forklaret enkelt
2026-03-20Få en praktisk forklaring på LCP, INP og CLS. Lær hvad Core Web Vitals måler, hvorfor de betyder noget, og hvordan du kommer i gang.
Vary-header og caching: undgå forkert indhold og lav cache-hit-rate
2026-03-30Vary bestemmer hvornår caches skal gemme flere varianter af samme URL (fx gzip vs brotli eller dansk vs engelsk). Lær de typiske fejl, og hvordan du tester med headers og curl.
Hvordan tredjeparts scripts gør din hjemmeside langsom
2026-03-26Få overblik over hvordan chat widgets, tracking, consent, video embeds og andre tredjeparts scripts påvirker LCP, INP, CLS og TTFB.
Når PageSpeed score snyder: derfor føles siden stadig langsom
2026-03-25Forstå hvorfor en grøn score ikke altid betyder en hurtig hjemmeside, og lær hvad du i stedet skal kigge på, når brugerne stadig oplever siden som tung.
Cookie banner og Core Web Vitals: den oversete årsag til dårlig brugeroplevelse
2026-03-24Se hvordan cookie bannere og consent scripts kan påvirke load, layout og interaktion, og lær hvordan du undgår at de ødelægger brugeroplevelsen.
FAQ
Skal jeg optimere for Lighthouse score?
Brug Lighthouse som diagnostik og som en regression-alarm, men optimer primært for feltdata og brugeroplevelse. Lab er et værktøj – ikke et facit.
Hvor lang tid går der før Search Console viser forbedringer?
Ofte uger, fordi Core Web Vitals-data er aggregeret over tid (typisk 28 dage). Det afhænger også af trafik og hvor hurtigt nok brugere rammer de forbedrede URL’er.
Hvad gør jeg hvis lab er grøn, men felt stadig er rød?
Segmentér problemet: device (mobil), netværk/geo og URL-grupper. Vælg en repræsentativ URL fra den røde gruppe og debug med waterfall/DevTools – ofte er det svage enheder, høj TTFB i peak hours, eller en langsom skabelon i gruppen.
Eksterne kilder
Officielle beskrivelser af Web Vitals og Lighthouse - nyttige når du skal sammenholde lab og feltdata med dokumentationen.
Næste skridt i samme emne
Fortsæt fra forklaring til handling med guides, emner og ordbog.
