Core Web Vitals er Googles måde at sætte tal på, hvordan en side føles at bruge: Hvor hurtigt kommer det vigtigste frem? Reagerer siden, når jeg trykker? Hopper indholdet rundt, mens jeg læser? Her er, hvad de tre målinger betyder, hvilke grænser der gælder, og hvordan du læser tallene uden at blive snydt af forskellen på labdata og feltdata.
De tre målinger og grænsen for «god»
| Måling | Hvad den måler | God, hvis … |
|---|---|---|
| LCP – Largest Contentful Paint | Hvornår det største synlige element (ofte et billede eller en overskrift) er tegnet. | højst 2,5 sekunder |
| INP – Interaction to Next Paint | Hvor længe der går, fra du klikker, trykker eller taster, til skærmen har opdateret sig. | højst 200 millisekunder |
| CLS – Cumulative Layout Shift | Hvor meget synligt indhold flytter sig uventet, mens siden indlæses og bruges. | højst 0,1 |
Web.dev beskriver, at en side vurderes ved den 75. percentil af sidevisningerne: Mindst tre ud af fire besøg skal opfylde grænsen, før målingen regnes som «god». Én hurtig måling på din egen computer kan derfor ikke afgøre, om siden består.
Labdata og feltdata er to forskellige ting
Labdata kommer fra en kontrolleret test, typisk Lighthouse: samme simulerede enhed og netværk hver gang. Det er godt til at finde og teste fejl. Feltdata kommer fra rigtige besøgende (ofte via Chrome UX Report) og er en fordeling af tal, ikke ét tal. Web.dev er tydelig på forskellen: Feltdata er det, du skal bruge til at prioritere, mens labdata er nyttige, når du fejlsøger eller tester en ændring, før den går live.
Tallene afviger, fordi laben kun har én enhed, ét netværk og tom cache, mens rigtige brugere har alt fra gamle telefoner til hurtigt wifi, og siden ofte ligger i cachen. Laben scroller og klikker heller ikke, så den kan ikke måle INP. Lighthouse nævner derfor Total Blocking Time (TBT) som den nærmeste stedfortræder i laben.
Et eksempel fra min egen hjemmeside viser, hvor let man kan misforstå labtal. Jeg målte den 22. oktober 2026 med Lighthouse (mobil, simuleret langsom 4G) forskellige landingssider på oscarwinther.dk: LCP lå mellem 3,2 og 4,3 sekunder og CLS på 0,011. Da jeg målte en lokal kopi af samme sider på min egen computer, faldt performance-scoren fra 82–89 til 69–83, selvom jeg ikke havde ændret billeder eller JavaScript. Forskellen skyldtes måleopsætningen (lokal server uden CDN og en travl computer), ikke siderne. Konklusionen: Sammenlign kun labmålinger, der er taget under de samme forhold.
LCP: få det vigtigste frem hurtigt
LCP-elementet er på de fleste virksomhedssider et stort billede. Web.devs vejledning peger på fire dele, tiden går til: svar fra serveren, tiden før billedet begynder at hente, selve hentningen og tiden til det tegnes. Praktisk betyder det:
- Lazy-load aldrig LCP-billedet. Web.dev er direkte: det giver altid unødig ventetid.
- Gør billedet synligt i HTML'en, så browseren finder det med det samme. Hvis det først opdages, når JavaScript kører, kan du give browseren et hint med
fetchpriority="high"eller en preload – men kun på ét eller to billeder, ellers mister prioriteringen sin virkning. - Send ikke et større billede end nødvendigt. Et 2560 px bredt billede er overflødigt på en telefon.
På min egen hjemmeside var LCP-elementet på flere case-sider et JPEG-billede, der kunne være mindre, og på Om mig et animeret logo. Jeg prøvede også at forbedre hentningen med preload-hints for sidens kode og stilark. Tre sider blev målt med og uden dem: performance-scoren faldt fra 81 til 71, fra 77 til 75 og fra 69 til 65. Ændringen gav ingen dokumenteret gevinst, så jeg fjernede den igen. Lærdommen er, at en teknisk «optimering» skal måles, før den bliver stående.
CLS: giv billeder og indlejringer faste mål
Web.dev nævner billeder og videoer uden kendte mål, dynamisk indsat indhold, fonte der skifter størrelse og indlejrede widgets som de typiske årsager til layoutskift. Det nemmeste at rette er billeder: Angiv bredde og højde, så browseren kan holde plads, før billedet er hentet. Ved min gennemgang manglede 14 billeder i case-gallerierne på seks sider mål; nu har de alle width og height.
INP: hold hovedtråden fri
INP rammer, når siden er travl med JavaScript, når brugeren trykker. På en almindelig virksomhedsside er årsagen ofte tunge tredjepartsscripts: chat, tracking, indlejrede kort. Ret den ved at indlæse dem, når de er nødvendige (fx efter samtykke eller et klik), og ved at fjerne dem, du ikke bruger. Mål INP i feltdata; Lighthouse kan ikke.
Sådan kommer du i gang
- Se feltdata først: Hvis siden har nok besøgende, viser Search Console og PageSpeed Insights, om grupper af sider består. Er der ikke nok data, er labdata det bedste, du har – men brug dem som fejlfinding, ikke som facit.
- Find LCP-elementet på de vigtigste sider og se, om det er et billede, der kan gøres mindre eller kan hentes tidligere.
- Sæt mål på alle billeder og indlejringer.
- Gennemgå tredjepartsscripts og fjern dem, du ikke bruger.
- Mål igen under de samme forhold, og behold kun de ændringer, der kan ses i tallene.
Hvis du vil have en konkret gennemgang af din side, kan jeg hjælpe med hastighedsoptimering, hvor jeg først måler og derefter prioriterer. Et kig på Search Console er et godt sted at starte.