Core web vitals forklaring: hvad betyder det?

Når en hjemmeside føles langsom eller “hopper rundt”, mister den hurtigt folks tålmodighed. Det gælder, uanset om du sælger produkter, vil have telefonen til at ringe, eller bare prøver at få læst dine vigtigste sider.

Core Web Vitals er Googles måde at sætte tal på den oplevelse. De er ikke kun tekniske nørdetal. De er tæt knyttet til, om besøgende bliver hængende, klikker videre og ender med at købe eller kontakte dig.

Hvad Core Web Vitals egentlig er

Core Web Vitals er tre målinger, som Google bruger til at vurdere, hvordan en side opleves af rigtige brugere. Fokus er på:

hvor hurtigt sidens vigtigste indhold bliver synligt
hvor hurtigt siden reagerer på handlinger
om layoutet er stabilt, mens siden indlæser

Det er altså ikke “hvor flot” siden er, men hvordan den føles.

Og ja, de hænger sammen med synlighed: Google har bekræftet, at Core Web Vitals indgår som en del af deres sideoplevelsessignal. Det betyder sjældent, at en hurtig side automatisk slår en langsommere side med bedre indhold, men når to resultater ellers ligner hinanden, kan oplevelsen tippe vægten.

De tre målinger, forklaret i almindeligt sprog

Core Web Vitals består af LCP, INP (tidligere FID) og CLS. Her er de, uden at drukne i tekniske detaljer.

LCP: hvor hurtigt ser jeg “det vigtige”?

Largest Contentful Paint (LCP) måler, hvor lang tid der går, før det største synlige element i viewporten er gengivet. I praksis er det ofte et hero-billede, en stor overskrift eller en stor tekstblok.

Hvis LCP er høj, kan brugeren opleve siden som tom eller “i gang med at tænke”, selv om der teknisk set sker ting i baggrunden.

En typisk situation: Du lander på en side, men du venter lige det ekstra sekund på, at det vigtigste indhold viser sig. Mange når at trykke tilbage, før du overhovedet får en chance.

INP: hvor hurtigt reagerer siden, når jeg klikker?

Google bruger nu INP (Interaction to Next Paint) som hovedmål for interaktivitet. Tidligere var det FID (First Input Delay). Begge handler om, hvor responsiv siden føles, men INP ser bredere på interaktioner over tid.

Hvis INP er dårlig, kan siden virke færdigindlæst, men knapper, menuer eller formularfelter reagerer langsomt. Det er ofte JavaScript, der blokerer.

Enkelt sagt: Brugeren klikker, og der sker ingenting med det samme. Det er præcis dér, hvor tillid og konvertering kan ryge.

CLS: flytter tingene sig, mens jeg læser?

Cumulative Layout Shift (CLS) måler, hvor meget indholdet “hopper” uventet under indlæsning.

Du kender det, hvis du er ved at trykke på en knap, og så kommer et billede, en cookiebar eller en annonce ind og skubber det hele ned, så du klikker forkert.

Efter du har læst definitionen, giver det pludselig mening, hvorfor CLS kan være direkte konverterings-skadeligt.

Efter nogle få sider med dårlige oplevelser lægger mange en slags mental afgift på dit brand: “De har ikke styr på deres site.”

Typiske tegn på CWV-problemer i hverdagen kan være:

Lang “hvid” skærm før indhold vises
Knapper der reagerer forsinket
Menu der føles tung på mobil
Tekst der flytter sig, mens du læser
Formularer der “glitcher” ved første klik

Hvad er gode tal, og hvad betyder de i praksis?

Google arbejder med tærskler, hvor målinger typisk kategoriseres som “god”, “skal forbedres” eller “dårlig”. Man skal ikke jage perfekte scores for sportens skyld, men det giver mening at komme ud af rød zone, især på de sider der driver mest trafik og omsætning.

Her er en praktisk oversigt:

Metrik	Hvad måles	God	Skal forbedres	Dårlig
LCP	Tid til største synlige element er vist	≤ 2,5 s	2,5 til 4,0 s	> 4,0 s
INP	Respons på brugerinteraktioner	≤ 200 ms	200 til 500 ms	> 500 ms
CLS	Uventede layoutskift	≤ 0,1	0,1 til 0,25	> 0,25

Tallene ovenfor er retningslinjer, men det vigtigste er at måle konsekvent og prioritere der, hvor forbedringer giver mærkbar effekt.

Du kan måle med gratis værktøjer, og de dækker både laboratorietests og data fra rigtige brugere.

De mest brugte steder at starte er:

PageSpeed Insights: kombinerer lab-data med feltdata (CrUX) når det findes
Lighthouse (i Chrome): god til at finde konkrete flaskehalse på en bestemt side
Google Search Console: overblik på tværs af URL-grupper, især mobil vs. desktop
Chrome UX Report (CrUX): aggregerede data fra rigtige Chrome-brugere, når der er volumen nok

Core Web Vitals går fra at være en frustrerende rapport til at blive et konkret værktøj, der beskytter både synlighed og salg.

Sådan hænger Core Web Vitals sammen med synlighed i Google

Google prøver grundlæggende at sende brugeren videre til sider, der svarer godt på søgningen og føles rare at bruge. Core Web Vitals passer ind i den logik, fordi de er et mål for “kan jeg bruge siden uden irritation?”

Det er samtidig værd at holde fast i en vigtig pointe: indhold og relevans vejer tungere end Core Web Vitals. Hvis din side ikke svarer bedre på søgeintentionen end konkurrentens, redder en hurtigere LCP dig ikke alene.

Men når du konkurrerer i et felt, hvor mange tilbyder nogenlunde det samme, og hvor SERP’en er tæt, kan sideoplevelse blive det ekstra signal, der hjælper.

Og det påvirker også indirekte: Hvis brugere klikker ind og hurtigt forlader siden igen, er det sjældent et godt tegn. En hurtigere og mere stabil side giver bedre chance for, at folk faktisk læser, scroller, klikker og bliver hængende.

Hvorfor Core Web Vitals også rammer konvertering

Konvertering handler ofte om små friktioner. Ikke den ene store fejl, men summen af irriterende øjeblikke.

En langsom hero-sektion kan gøre, at man aldrig når frem til budskabet.
En tung menu kan gøre, at man ikke finder produkterne.
En “hoppende” side kan gøre, at man mister lysten til at udfylde formularen.

Især på mobil, og især for nye besøgende, kan en lille forsinkelse føles stor. Mange vurderer din troværdighed på få sekunder.

Det giver mening at prioritere optimering ud fra sider, der betyder mest for forretningen, ikke ud fra en tilfældig Lighthouse-score på en blogpost fra 2019.

En enkel måde at prioritere indsatsen på er:

Landingssider fra Google: sider der får organisk trafik, og hvor førsteindtryk betyder alt
Salgssider og kategorioversigter: her skal folk kunne skimme og klikke uden ventetid
Kontakt, booking og checkout: alt der føles langsomt eller ustabilt her, koster direkte leads og ordrer
Skabeloner før enkeltsider: ret årsagen i tema, plugins og komponenter, ikke kun på én URL

De typiske årsager til dårlige scores og de mest oplagte greb

Når man først begynder at måle, ser man ofte det samme mønster igen og igen. Core Web Vitals er sjældent “mystiske”. De kommer som regel af nogle få klassikere.

LCP: langsomt hovedindhold

LCP bliver ofte dårlig på grund af store billeder, tung CSS, langsom serverrespons eller for meget, der skal hentes, før browseren kan tegne siden.

På WordPress ser man tit, at hero-billeder uploades i alt for høj opløsning, eller at et tema trækker unødvendige assets ind på alle sider.

Greb der ofte virker:

komprimer og server billeder i moderne formater (WebP/AVIF)
sørg for caching, så serveren svarer hurtigt
prioriter kritiske ressourcer og udskyd det, der ikke er nødvendigt for første visning

INP: JavaScript der blokerer

Dårlig INP handler tit om, at browserens hovedtråd har for meget at lave. Det kan være tracking-scripts, tunge plugins, sliders, chat-widgets eller scripts, der kører tidligt og ofte.

Nogle gange er løsningen at fjerne, andre gange at udskyde og rydde op, så siden kan reagere hurtigt på klik og input.

Typiske greb:

fjern scripts du ikke bruger, eller som kan erstattes af noget lettere
brug på ikke-kritiske scripts, så de ikke blokerer rendering
del store bundles op, hvis du har en mere custom løsning

CLS: plads der ikke er reserveret

CLS er ofte den mest “pinlige”, fordi den er så synlig. Den kommer tit fra:

billeder og iframes uden fast bredde og højde
bannere og cookie-løsninger, der skubber indhold ned
dynamiske elementer, der bliver injiceret øverst på siden

En effektiv basisregel er, at browseren skal kende pladsen på elementer, før de indlæses. Så kan layoutet tegnes stabilt fra start.

Det kan også kræve, at man tænker lidt mere UX: Hvis noget skal dukke op, så lad det ligge ovenpå som en overlay, i stedet for at flytte alt andet.

En enkel måde at arbejde med det på i en travl hverdag

Det er fristende at tage én stor optimeringsrunde og så glemme det igen. Mange sites bliver langsommere over tid, fordi der løbende kommer nye billeder, nye kampagner, nye plugins og nye trackings.

Et pragmatisk setup er at gøre Core Web Vitals til en fast del af vedligeholdelse, ikke et særprojekt.

Det kan gøres ret jordnært:

Mål fast: tjek Search Console og PageSpeed Insights med faste intervaller.
Ret dér hvor det batter: start med skabeloner, top-landingssider og dine vigtigste konverteringsflows.
Hold det samlet: mange vælger at have web, tracking, SEO og tekniske rettelser samlet ét sted, så ændringer ikke modarbejder hinanden.

Når du har styr på de store bremser, bliver resten ofte et spørgsmål om disciplin: ingen enorme hero-billeder uden komprimering, ingen nye scripts uden formål, og ingen elementer der skubber layoutet rundt.

Det er typisk her, Core Web Vitals går fra at være en irriterende rapport til at være et konkret værktøj, der beskytter både synlighed og salg.

Vi står altid klar til at tage imod dit opkald