Core Web Vitals forklaret: Hvad de måler, og hvad du skal gøre ved dem

Hvis du har åbnet Google Search Console på det seneste, har du sandsynligvis set rapporten over Core Web Vitals. Måske er der røde tal. Måske gule. Måske ved du ikke helt hvad du kigger på.

Det er der mange der ikke gør. Ikke fordi de er dårlige til SEO, men fordi Core Web Vitals har et terminologiproblem: navnene er tekniske, enhederne er ukendte, og det er ikke åbenlyst hvad man egentlig skal gøre ved dem.

Denne guide løser det. Ingen developer-jargon. Bare hvad de tre metrics måler, hvad tallene skal ligge på – og hvad du gør når de ikke gør det.

Hvad er Core Web Vitals?

Core Web Vitals er tre målinger Google bruger til at vurdere brugeroplevelsen på en hjemmeside. De indgår som et rankingsignal i Googles algoritme – og de måler ikke om dit indhold er godt, men om siden føles hurtig og stabil at bruge.

De tre metrics er:

• LCP – Largest Contentful Paint
• INP – Interaction to Next Paint
• CLS – Cumulative Layout Shift

Alle tre måles fra rigtige brugeres oplevelse (field data), ikke fra et simuleret testmiljø. Det betyder at dine tal afspejler, hvad folk faktisk oplever på din side – ikke hvad de oplever i ideelle netværksforhold.

LCP – Largest Contentful Paint

Hvad måler det? LCP måler, hvor lang tid det tager fra en bruger klikker sig ind på din side, til det største synlige element er fuldt indlæst. Det er typisk et hero-billede, en stor overskrift eller en video-thumbnail.

Det er med andre ord: hvornår ser siden ud til at være klar?

Hvad er godt nok?

• Under 2,5 sekunder = Grøn (god)
• 2,5–4,0 sekunder = Gul (skal forbedres)
• Over 4,0 sekunder = Rød (dårlig)

Hvad er de typiske årsager til dårlig LCP? Langsomme servere er den hyppigste synder. Hvis serveren er langsom til at sende det første byte til browseren, kan alt andet være optimeret – LCP vil stadig være langsom. Derudover er store billeder uden korrekt komprimering og formatering (WebP eller AVIF i stedet for JPG/PNG) en klassiker, ligesom CSS eller JavaScript der blokerer rendering.

Hvad gør du ved det? Start med at tjekke serverresponstiden (TTFB) i Google Search Console eller PageSpeed Insights. Konvertér store billeder til WebP. Sørg for at dit LCP-element – typisk hero-billedet – har loading="eager" og ikke er lazy-loaded.

INP – Interaction to Next Paint

Hvad måler det? INP måler, hvor hurtigt siden reagerer når en bruger interagerer med den – klikker på en knap, udfylder et felt, åbner en menu. Det er ventetiden fra brugerens handling til siden visuelt bekræfter at noget er sket.

INP erstattede FID (First Input Delay) i marts 2024 og er mere præcis, fordi den måler alle interaktioner gennem et besøg – ikke kun den første.

Hvad er godt nok?

• Under 200 millisekunder = Grøn
• 200–500 millisekunder = Gul
• Over 500 millisekunder = Rød

Hvad er de typiske årsager til dårlig INP? Tunge JavaScript-opgaver der blokerer browsertråden. Hvis din side kører meget JS i baggrunden (analytics, chat-widgets, annoncer, store frameworks), kan det forsinke browserens evne til at reagere på brugerens handling.

Hvad gør du ved det? INP er den sværeste af de tre at fikse uden en developer. Det handler typisk om at opdele store JS-opgaver i mindre, udskyde ikke-kritisk JavaScript og reducere tredjepartsscripts. Start med at identificere hvilke interaktioner der er langsomme via Chrome DevTools eller CrUX-data i Search Console.

CLS – Cumulative Layout Shift

Hvad måler det? CLS måler, hvor meget indholdet på siden hopper rundt mens det loader. Har du prøvet at klikke på et link – og så rykker siden sig i sidste sekund fordi et billede loader, og du ender med at klikke på noget helt andet? Det er høj CLS.

Scoren er ikke i sekunder men i en enhed fra 0 til uendeligt, hvor lavere er bedre.

Hvad er godt nok?

• Under 0,1 = Grøn
• 0,1–0,25 = Gul
• Over 0,25 = Rød

Hvad er de typiske årsager til dårlig CLS? Billeder og videoer uden definerede dimensioner i HTML er den mest almindelige årsag. Hvis browseren ikke ved hvor stor en video er, reserverer den ikke plads til den – og siden hopper når elementet loader. Annoncepladser og cookie-bannere der dukker op og skubber indhold ned er også klassikere.

Hvad gør du ved det? Tilføj altid width og height-attributter på billeder og videoer i HTML. Reservér plads til annoncepladser med CSS. Undgå at injicere indhold dynamisk øverst på siden efter det er loaded.

Sådan finder du dine tal

Der er tre primære steder at finde dine Core Web Vitals-data:

Google Search Console Under Oplevelse → Core Web Vitals finder du et overblik over, hvor mange af dine sider der er grønne, gule og røde – opdelt på mobil og desktop. Det er field data fra rigtige brugere.

PageSpeed Insights Gå til pagespeed.web.dev og indsæt en URL. Du får både field data (hvis tilgængeligt) og lab data fra en simuleret test, samt specifikke anbefalinger til hvad der kan forbedres.

CrUX-rapporten i Search Console CrUX (Chrome User Experience Report) er det datasæt Google bruger. Tallene opdateres løbende og afspejler de seneste 28 dages brugeroplevelse.

En vigtig nuance: mobil vs. desktop

Google måler Core Web Vitals separat for mobil og desktop – og det er næsten altid mobilversionen der er problemet. Mobilnetværk er langsommere, processorer er svagere, og billeder der ser fine ud på en stor skærm kan tage evigheder at loade på en telefon.

Tjek altid begge kolonner i Search Console, men prioritér mobil.

Er Core Web Vitals et stort rankingsignal?

Ærligt svar: det er et rankingsignal, men ikke et dominerende et.

Google har selv sagt at indholdsrelevans og E-E-A-T vejer tungere end Core Web Vitals. En side med fremragende indhold og dårlige Core Web Vitals vil typisk ranke over en tom side med perfekte tal.

Men – og det er et vigtigt men – Core Web Vitals er en tiebreaker. Når to sider konkurrerer på lignende indhold og autoritet, kan brugeroplevelsen afgøre hvem der vinder. Og i 2026, hvor AI search-platforme som Google AI Overviews i stigende grad citerer sider direkte, er hurtige og stabile sider bedre positioneret til at blive valgt som kilde.

Det er ikke en grund til at ignorere Core Web Vitals. Det er en grund til ikke at lade dem overtrumfe alt andet.

Den korteste version

Hvis dine tal er røde i Search Console, er prioriteringsrækkefølgen typisk:

1. LCP: Tjek serverresponstid og optimer billeder til WebP
2. CLS: Tilføj dimensioner på billeder og videoer
3. INP: Reducer og udskyd tredjeparts JavaScript

Start med det der fylder mest i rapporten – og husk at ændringer tager op til 28 dage at slå igennem i Search Console, da data opdateres løbende.