Lighthouse og Core Web Vitals: hvad tallene betyder, og hvad der flytter dem

Hastighed er det SEO-emne, hvor flest bruger flest timer på det mindste udbytte. Ikke fordi det er ligegyldigt, men fordi tallene bliver misforstået. Lighthouse-scoren er ikke det, Google måler. Core Web Vitals er. Her er forskellen, og hvad der reelt flytter dem.

Lighthouse og Core Web Vitals er to forskellige ting

Lighthouse er et værktøj. Det ligger i Chrome under DevTools, det driver PageSpeed Insights, og det simulerer en langsom telefon på en dårlig forbindelse og giver en score fra 0 til 100. Det er laboratoriedata: samme test, samme betingelser, hver gang. Godt til at finde årsager. Dårligt til at beskrive virkeligheden.

Core Web Vitals er tre målinger, Google indsamler fra rigtige Chrome-brugere, der besøger dit site. Det er feltdata, og det er dem, der indgår i Googles vurdering af sideoplevelsen. Du finder dem i Search Console under Oplevelse og øverst i PageSpeed Insights, hvis sitet har trafik nok til at få dem vist.

En side kan score 95 i Lighthouse og stadig fejle Core Web Vitals, fordi de rigtige brugere sidder med ældre telefoner end simulatoren. Det omvendte sker også. Derfor: brug felt-data til at afgøre, om der er et problem, og Lighthouse til at finde ud af hvorfor.

De tre målinger og grænserne

LCP, Largest Contentful Paint. Hvor lang tid der går, før det største element over folden er tegnet. Typisk hero-billedet eller overskriften. Grænsen for “god” er 2,5 sekunder.

INP, Interaction to Next Paint. Hvor lang tid der går fra brugeren trykker på noget, til skærmen reagerer. Grænsen er 200 millisekunder. INP erstattede FID i 2024 og er hårdere, fordi den måler alle interaktioner på siden, ikke kun den første.

CLS, Cumulative Layout Shift. Hvor meget indholdet springer, mens siden loader. Grænsen er 0,1. Det er tallet bag den irritation, hvor man vil trykke på et link, og en annonce skubber det væk i sidste øjeblik.

Google vurderer den 75. percentil. Tre ud af fire besøg skal ligge under grænsen, før en side består. Det betyder, at én langsom kunde ikke ødelægger noget, men at et systematisk problem på mobil gør.

Sådan kører jeg Lighthouse

I Chrome: DevTools, fanen Lighthouse, mobil, kun Performance-kategorien, og kør i et inkognitovindue, så udvidelser ikke forstyrrer. Kør tre gange og tag medianen, for scoren svinger. På kommandolinjen bruger jeg npx lighthouse <url>, som giver en JSON-fil, der kan sammenlignes fra uge til uge. Det er den version, jeg bruger, når et site skal måles før og efter en ændring, for øjemål lyver.

michaelkirkegaard.dk Lighthouse

Kig ikke på scoren først. Kig på afsnittet Diagnostics og på det element, Lighthouse har udpeget som LCP. Det svarer på det eneste spørgsmål, der betyder noget: hvad venter siden på?

De fejl, jeg oftest finder

Embeds og iframes, der loader med det samme. Instagram, YouTube, LinkedIn, kort. Hvert embed henter sit eget script og sin egen CSS, ofte flere hundrede kilobyte, og det sker, før dit eget indhold er tegnet. Løsningen er at vente med embeddet, til det er tæt på skærmen, eller vise et billede med en afspil-knap og først hente iframen ved klik.

Billeder i fuld størrelse. Et hero-billede på 2.000 pixels sendt til en telefon med 390 pixels skærm. Brug WebP eller AVIF, lav tre størrelser, og lad browseren vælge med srcset. Sæt fetchpriority="high" på det ene billede, der er LCP, og loading="lazy" på alt under folden.

Fonte fra tredjepart. Google Fonts kræver et opslag til en ny server, derefter et CSS-hentning, derefter fontfilerne. Overskriften kan ikke tegnes, før det er sket. Læg fontfilerne på dit eget domæne, brug preload, og skriv font-display: swap.

Blur-effekter og tunge filtre. filter: blur() på store elementer koster styling- og layouttid ved hver frame på mobile processorer. En radial gradient ser næsten identisk ud og koster ingenting.

Scripts, der loader først. Chat-widgets, marketing-tags og heatmaps behøver ikke være klar før hero-billedet. Udskyd dem til efter load, gerne med et par sekunders forsinkelse. De måler det samme, brugeren mærker ingen forskel, og LCP vinder.

Layoutspring. Billeder uden width og height, fonte der skifter størrelse ved indlæsning, bannere der skubbes ind øverst. Reservér pladsen, før indholdet kommer.

Hvad det gav på mit eget site

Da jeg gik min egen forside igennem i september 2026, scorede den 75 på mobil med en LCP på 14,6 sekunder. Årsagen var seks Instagram-embeds i en karrusel, der alle hentede Instagrams script ved sideindlæsning. Efter udskudte embeds, WebP-billeder med srcset, self-hostede fonte, gradienter i stedet for blur og et marketing-script flyttet til efter load ligger forsiden på 98 og LCP på 1,8 sekunder. Siden blev ikke mindre indholdsrig. Den fik bare den rigtige rækkefølge.

Hvornår hastighed ranker

Sideoplevelse er ikke en primær rankingfaktor, og Google har sagt det klart: indhold og relevans vinder over hastighed. Men i en søgning, hvor to sider svarer lige godt, kan sideoplevelsen afgøre rækkefølgen. Og uden for rankingen betyder det noget hver dag: hurtigere sider konverterer bedre, koster mindre i annoncering, fordi kvalitetsscoren stiger, og bliver crawlet mere. Derfor står hastighed altid på min tjekliste til teknisk SEO, men aldrig øverst.

Min rutine

Nye sider: Lighthouse på mobil før publicering, mål: 95 eller over på sider, der skal ranke. Forsider må gerne være rigere og lande lavere, de skal ikke ranke på søgeord. Hver måned: Core Web Vitals-rapporten i Search Console. Er der en gruppe URL’er i gult eller rødt, så åbner jeg én af dem i Lighthouse, finder årsagen og retter mønstret, ikke siden.