Hvad er Core Web Vitals? LCP, INP og CLS forklaret enkelt

Core Web Vitals er tre brugercentrerede målinger, der siger noget om om siden føles hurtig, reagerer hurtigt og ikke hopper rundt.

Tre konkrete situationer: (1) Høj LCP - hero-billedet på forsiden er 2400 px bredt, sendes som PNG og discoveres sent, så hovedindhold først vises efter flere sekunder. (2) Dårlig INP - menuen på mobil åbner langsomt fordi et analytics-script og et A/B-framework kører lange tasks på main thread når du trykker. (3) Høj CLS - webfonten og fallback-fonten har forskellige linjehøjder, eller et cookie-banner skubber indhold ned efter et sekund. Sådan problemer er præcis det Core Web Vitals hjælper dig med at få øje på - ikke som abstrakte tal, men som spor til hvad du skal rette.

Hvis du arbejder med SEO eller konvertering, er Core Web Vitals et af de bedste steder at starte, fordi signalerne tvinger dig til at optimere de ting, der også påvirker rigtige mennesker: ventetid, respons og stabilitet. De hænger tæt sammen med praktiske guides på sitet - fx LCP med billeder, INP og JavaScript og CLS og layout.

Hvem er denne side til? Websiteejere, marketing og udviklere der vil forstå hvad Google (og brugere) måler, hvorfor det betyder noget, og hvordan du kommer videre uden at drukne i værktøjer. Du behøver ikke være udvikler for at forstå hovedpointerne, men du får også ord nok til at tale med teknik.

De tre signaler

• LCP (Largest Contentful Paint): Hvor hurtigt det vigtigste indhold bliver synligt.
• INP (Interaction to Next Paint): Hvor hurtigt siden reagerer på brugerhandlinger.
• CLS (Cumulative Layout Shift): Hvor meget layout flytter sig uventet.

Hvorfor det betyder noget

Det handler både om brugeroplevelse og om at fjerne tekniske flaskehalse, der ofte påvirker konvertering, engagement og crawl-effektivitet.

Hvad er Core Web Vitals egentlig (og hvad er det ikke)?

Core Web Vitals er Googles “kerne-målinger” for sideoplevelse. De er ikke en samlet “score”, men tre separate målinger, der hver især kan være gode eller dårlige.

Det er også vigtigt at forstå forskellen på:

• Lab-data (Lighthouse/PageSpeed Insights lab): en kontrolleret test i et fast miljø.
• Feltdata (CrUX/Search Console): rigtige brugere over tid (typisk 28 dage).

Når du skal prioritere arbejde, er feltdata ofte det mest troværdige. Når du skal debugge, er lab-data ofte det mest brugbare. Læs mere om forskellen i Lighthouse vs CrUX - og brug waterfall-gennemgang når du skal se rækkefølgen af requests, ikke kun scorer.

Når tallene ser modstridende ud

Det er normalt hvis PageSpeed ser “grøn” ud, mens Search Console viser “skal forbedres”. Lab og felt måler ikke det samme: én simuleret kørsel vs. mange rigtige sessioner med forskellig cache, netværk og enheder. Brug felt til at vælge område, lab til at finde årsag på en konkret URL.

Hvilke grænser er “gode”?

Tommelreglerne du typisk vil se (og som er gode at styre efter) er:

• LCP: under ca. 2,5 sek. (godt), 2,5–4 sek. (skal forbedres), over 4 sek. (dårligt)
• INP: under ca. 200 ms (godt), 200–500 ms (skal forbedres), over 500 ms (dårligt)
• CLS: under ca. 0,1 (godt), 0,1–0,25 (skal forbedres), over 0,25 (dårligt)

Typiske fejlprioriteringer

• Kun at kigge på Lighthouse på wifi-desktop og så konkludere at «alt er fint», mens mobil-felt halter - ret mod feltdata først.
• At optimere LCP med lazy-load af hero eller at skifte billede uden at rette srcset/sizes - du flytter ofte problemet eller skader discovery.
• At ignorere CLS fordi «det kun er 0,15» - små hop underminerer klik og tillid, især på checkout.
• At smide tunge scripts ind via tag manager uden at måle INP efterfølgende - INP er ofte tredjepartsdomineret.

Hvorfor LCP/INP/CLS hænger sammen

I praksis er de ofte forbundet:

• Hvis du loader for meget JavaScript tidligt, får du tit både dårlig LCP (rendering/CPU) og dårlig INP (main thread er blokeret).
• Hvis du lazy-loader hero-billedet, kan LCP blive værre, selvom du “optimerer” load.
• Hvis du ikke reserverer plads til billeder/embeds, får du CLS.

Derfor giver det mening at optimere i den rækkefølge:

1. Stabilitet (CLS) – ofte nemme fixes
2. Serverrespons og ressourcer (TTFB/LCP) – caching, billeder, CSS
3. Interaktivitet (INP) – JavaScript og tredjepart

Sådan finder du ud af hvad der er din LCP/INP/CLS

1) Search Console (Core Web Vitals rapport)

Brug Search Console til at se om problemerne findes i feltdata, og hvilke URL-grupper der er påvirket.

2) PageSpeed Insights

Brug PSI til at få:

• et hurtigt overblik (lab + felt)
• hints om hvad der blokerer (opportunities/diagnostics)

3) WebPageTest (waterfall + video)

WebPageTest er ofte det bedste sted at forstå hvorfor LCP er høj: hvornår starter LCP-ressourcen, er der render-blocking, er TTFB høj, osv.

4) Chrome DevTools (Performance)

Brug Performance-panelet til at finde:

• long tasks (INP/JS-problemer)
• layout shifts (CLS)

Hvad man typisk skal optimere (de store “buckets”)

Når Core Web Vitals er dårlige, er det næsten altid en kombination af:

Server og caching (TTFB)

Hvis serveren bruger lang tid på at svare, starter alt sent.

Typiske tiltag:

• page cache / full-page cache
• edge cache via CDN hvor det giver mening
• database- og backend-optimering

Billeder (LCP)

Hero-billedet er meget ofte LCP-elementet.

Typiske tiltag:

• AVIF/WebP
• responsive størrelser (srcset)
• korrekt dimensionering
• preload af hero-billede (med måde)

CSS og render-blocking

Store stylesheets eller render-blocking scripts kan forhindre tidlig rendering.

Typiske tiltag:

• critical CSS
• fjern unused CSS
• defer ikke-kritisk JS

JavaScript og tredjepart (INP)

INP bliver ofte dårlig af:

• store bundles
• tunge frameworks
• tracking/marketing scripts der kører tidligt

Typiske tiltag:

• reduktion og splitting
• udskyd tredjepart
• mål og fjern long tasks

En simpel “kom i gang”-plan (hurtig triage)

Hvis du vil have et effektivt forløb uden at overanalysere:

1. Find LCP-elementet og se om det er et billede (ofte ja)
2. Fix åbenlyse CLS (dimensioner på media, embeds, fonts)
3. Reducér TTFB med caching
4. Trim JavaScript og tredjepart (INP)
5. Mål igen og dokumentér ændringerne (så du ved hvad der virker)

Relaterede blogindlæg

Sådan prioriterer du hastighedsoptimering uden at spilde tid

2026-03-27

Lær hvordan du prioriterer hastighedsoptimering rigtigt, så du starter med de ændringer der giver mest effekt på LCP, INP, CLS og TTFB.

Lighthouse vs CrUX: hvorfor tallene ikke matcher og hvad du gør

2026-02-28

Forstå forskellen på Lighthouse og CrUX. Lær hvorfor labdata og feltdata kan vise noget forskelligt, og hvordan du bruger dem rigtigt.

Vary-header og caching: undgå forkert indhold og lav cache-hit-rate

2026-03-30

Vary 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-26

Få 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-25

Forstå 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-24

Se 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

Er Core Web Vitals “alt” i SEO?

Nej. Core Web Vitals hjælper dig med at finde tekniske problemer der rammer brugere, men indhold, relevans og links betyder stadig meget.

Kan man have gode Core Web Vitals og stadig være langsom?

Ja. Du kan have gode CWV i første viewport, men stadig have en tung oplevelse efterfølgende (store downloads, tunge flows). CWV er et kompas – ikke hele kortet.

Skal jeg optimere for lab eller felt?

Optimér for feltdata (CrUX/Search Console), og brug lab (Lighthouse/PSI) til at debugge årsagen på en konkret URL.

Hvor starter jeg, hvis alt ser dårligt ud?

En robust standardrækkefølge er: (1) CLS (dimensioner/fonts), (2) TTFB og caching, (3) LCP (hero/render-blocking), (4) INP (JavaScript og tredjepart).

Næste skridt i samme emne

Fortsæt fra forklaring til handling med guides, emner og ordbog.

Se relaterede guidesGå til emneoversigtSlå begreb op i ordbogLæs om metode og kilder