Core Web Vitals er tre målepunkter for, hvor hurtigt en side viser sit vigtigste indhold, reagerer på input og holder layoutet stabilt. De hedder LCP, INP og CLS. Målingerne hjælper dig med at finde problemer i brugeroplevelsen og prioritere konkrete forbedringer.
En høj samlet PageSpeed-score er noget andet end gode Core Web Vitals hos virkelige besøgende. Se på de enkelte målepunkter, datakilden og de sider, der har betydning for dine brugere.
De tre målepunkter og deres grænser
- LCP – Largest Contentful Paint: Tiden til det største relevante billede, tekstblok eller videoindhold i det synlige område bliver vist. Det handler om indlæsning.
- INP – Interaction to Next Paint: Sidens respons på klik, tryk og tastaturinput frem til næste visuelle opdatering. Målingen dækker interaktioner under besøget, ikke kun den første.
- CLS – Cumulative Layout Shift: Uventede layoutskift under besøget. Det er en score uden tidsenhed, ikke en måling i sekunder.
| Målepunkt | God | Kræver forbedring | Dårlig |
|---|---|---|---|
| LCP | Højst 2,5 sek. | Over 2,5 til og med 4 sek. | Over 4 sek. |
| INP | Højst 200 ms | Over 200 til og med 500 ms | Over 500 ms |
| CLS | Højst 0,1 | Over 0,1 til og med 0,25 | Over 0,25 |
Grænserne er kontrolleret i Googles dokumentation 9. oktober 2026. INP er det aktuelle mål for respons; FID er ikke længere en af de tre Core Web Vitals.
Hvad betyder 75. percentil?
Vurderingen bygger på 75. percentil af de målte besøg, opdelt på mobil og computer. Ved en LCP på 2,5 sekunder ved 75. percentil har mindst omkring 75 % af de registrerede besøg en LCP på 2,5 sekunder eller hurtigere. Det er ikke gennemsnittet, og det betyder ikke, at alle har en god oplevelse.
Når der er tilstrækkelige data for alle tre målepunkter, skal alle tre ligge i kategorien “God” ved 75. percentil for at bestå vurderingen. PageSpeed Insights kan vurdere LCP og CLS alene, hvis der mangler INP-data. Manglende INP er derfor ikke dokumentation for, at siden reagerer hurtigt.
Feltdata og laboratoriedata viser forskellige ting
Feltdata: oplevelsen ved virkelige besøg
Feltdata kommer fra faktiske brugere med forskellige enheder, forbindelser og adfærd. I PageSpeed Insights stammer de fra Chrome User Experience Report, også kaldet CrUX, og dækker de seneste 28 dage.
Kontrollér, om rapporten viser den konkrete URL eller hele webstedets origin, altså kombinationen af protokol, domæne og eventuel port. Hvis URL’en har for få observationer, kan værktøjet vise samlede data for origin. De fortæller ikke nødvendigvis, hvordan netop den side klarer sig. Manglende feltdata betyder heller ikke, at siden er hurtig.
Laboratoriedata: hjælp til at finde årsagen
En Lighthouse-test undersøger siden under bestemte simulerede forhold. Den er nyttig til at finde flaskehalse og sammenligne en ændring under ens betingelser. Resultatet kan variere mellem kørsler og afvige fra feltdata.
En almindelig indlæsningstest kan overse langsomme klik eller layoutskift senere i besøget. Total Blocking Time, TBT, kan pege på problemer med respons, men erstatter ikke INP. Test derfor også handlinger som at åbne menuen, bruge et filter eller lægge en vare i kurven.
Sådan diagnosticerer og prioriterer du problemer
- Vælg vigtige sidetyper. Start med eksempelvis en produktkategori, en produktside og en central ydelsesside. Undersøg mobil og computer hver for sig.
- Læs feltdata først, hvis de findes. Notér periode, URL- eller origin-niveau og de enkelte målepunkter. Brug også Core Web Vitals-rapporten i Search Console til at finde grupper af berørte sider.
- Genskab problemet. Brug en laboratorietest og browserens performanceværktøjer på konkrete eksempler. Følg de handlinger, brugerne normalt udfører.
- Find årsagen bag målepunktet. Ved LCP: undersøg serversvar og det indhold, der bliver vist sent. Ved INP: undersøg den langsomme interaktion og arbejdet i browseren. Ved CLS: find det element, der flytter sig, og hvad der udløser skiftet.
- Prioritér efter omfang og betydning. En fejl i en fælles skabelon på mange vigtige sider kan være mere relevant end en enkelt mindre advarsel. Vurdér også arbejdsindsats og risiko.
- Ret afgrænset og test igen. Notér ændringen og datoen. Kontrollér både målingen og funktioner som menu, formular og kurv.
- Følg op i feltdata. Et 28-dages datavindue indeholder også besøg før rettelsen. Forvent ikke, at hele rapporten afspejler ændringen samme dag.
Et konkret eksempel: Hvis en knap flytter sig, når et sent billede vises, bør du undersøge pladsreservationen til billedet. Hvis knappen bliver stående, men reagerer sent på et tryk, er det en anden diagnose. En mindre billedfil løser ikke nødvendigvis begge problemer.
Hvor meget betyder Core Web Vitals for SEO?
Google bruger Core Web Vitals i sine rangeringssystemer. Gode målinger garanterer dog ikke topplaceringer, og Google søger fortsat at vise relevant indhold. Der findes ingen fast gevinst i placeringer eller salg, som kan beregnes ud fra en forbedret score alene.
Brug målingerne til at gøre siden lettere at bruge. En grøn rapport fortæller ikke alt om navigation, tilgængelighed eller kundens mulighed for at løse sin opgave. Målet bør være dokumenterede forbedringer frem for en laboratoriescore på 100.
Tjekliste før du konkluderer
- Du ved, om tallet kommer fra feltdata eller en laboratorietest.
- Du har skelnet mellem URL-data og samlede origin-data.
- Du har vurderet mobil og computer hver for sig.
- Du har undersøgt det konkrete målepunkt og den berørte brugerhandling.
- Du har noteret periode og ændringsdato.
- Du har testet, at forbedringen også bevarer sidens funktioner.
Læs videre i forklaringen af sidehastighed og den større guide til teknisk SEO. De sætter målingerne ind i en samlet gennemgang af hjemmesiden.
Faglige kilder: web.dev: Web Vitals, INP, CLS, PageSpeed Insights: Data og grænser og Google Search Central: Sideoplevelse og rangering. Kilder kontrolleret 9. oktober 2026.