Core Web Vitals: hvad påvirker placeringer, og hvad irriterer bare

Core Web Vitals måler, hvordan en side føles for brugeren: hvor hurtigt hovedindholdet vises, hvor hurtigt siden svarer på et klik, og om elementerne hopper rundt. Der er tre målinger, og hver har en klar grænse.

Tre målinger og deres grænser

• LCP (visning af det største indhold): godt op til 2,5 sekunder
• INP (respons på interaktion): godt op til 200 millisekunder, dårligt over 500 ms
• CLS (layoutforskydning): godt op til 0,1

Vurderingen sker ud fra 75. percentil af data fra rigtige brugere, adskilt for mobil og desktop. En laboratoriescore (for eksempel Lighthouse) er et hjælpemiddel, ikke dommeren.

Hvordan markedet ser ud

Eksempel: ifølge HTTP Archives Web Almanac 2025 bestod 48 % af mobilsites (året før 44 %) og 56 % af desktopsites alle tre målinger. På mobil havde 77 % af sites en god INP, 62 % en god LCP og 81 % en god CLS. LCP er altså det svageste led.

Det betyder, at de fleste sites taber på LCP, ikke på INP. Hvis din side ligger på gennemsnittet, er en forbedring af LCP den største hurtige gevinst.

INP: hvor forsinkelsen kommer fra

INP afløste FID og måler den længste interaktion under hele besøget (undtagelser fraregnet). Den deles i tre dele: inputforsinkelse, behandlingstid og tegneforsinkelse.

• lange JavaScript-opgaver i hovedtråden blokerer behandlingen af klik
• en stor DOM og dyre stilberegninger forlænger tegningen
• tredjepartsscripts (chat, analytics, reklamer) stjæler tid fra alt andet

Hvad der virkelig påvirker placeringer

Google nævner sidens oplevelse som ét kvalitetssignal, men indholdets relevans vægter tungere. Hastighed alene afgør sjældent, hvem der står øverst, men en dårlig LCP og et hoppende layout får brugeren til at forlade siden. Hastighed er derfor først og fremmest et spørgsmål om konvertering og dernæst om rangering.

Hvad du skal gøre: rækkefølgen for rettelser

1. Mål først rigtige data (rapporten Core Web Vitals i Search Console, CrUX-delen i PageSpeed Insights)
2. LCP: foretræk HTML renderet på serveren, giv hovedbilledet de rigtige mål og høj prioritet, og lad være med at lazy-loade det
3. CLS: angiv width og height på billeder og annonceplaceringer, og indlæs skrifttyper uden spring
4. INP: opdel lange opgaver, udskyd tredjepartsscripts, og reducer DOM'en
5. Tjek resultatet efter 28 dage, for felddata opdateres med et glidende vindue

Eksempel fra praksis

Siderne på dette site genereres på forhånd som statisk HTML, så det første svar med bytes er hurtigt, og hovedindholdet findes uden JavaScript. Billederne har fastsatte mål, så layoutet ikke flytter sig. Det er den billigste vej til god LCP og CLS, og den virker også for INP, fordi mindre JavaScript giver færre lange opgaver.

Hurtig tjekliste før lancering

• Hovedbilledet har mål og er ikke lazy-loadet
• Skrifttyper giver ikke et synligt spring
• Tredjepartsscripts indlæses efter hovedindholdet
• Interaktive elementer svarer på klik uden mærkbar forsinkelse

Tre spørgsmål

Hvorfor adskiller Lighthouse-scoren sig fra Search Console?

Lighthouse er en laboratoriemåling på én enhed og én gennemgang. Search Console viser data fra rigtige brugere ud fra 75. percentil. Når du skal tage en beslutning, er det den sidste, der tæller.

Hvor hurtigt ser man effekten af en rettelse?

Felddata opdateres med et glidende vindue på 28 dage, så den fulde effekt viser sig efter cirka en måned. Træk ikke konklusioner ud fra tre dage.

Hvad er vigtigst: mobil eller desktop?

De vurderes hver for sig, men mobil er svagest: ifølge Web Almanac 2025 består 48 % af mobilsites og 56 % af desktopsites alle tre målinger. Ved LCP er andelen af „dårlige“ sites næsten dobbelt så stor på mobil (13 % mod 7 %).

Opsummering

Start med rigtige data, ret først LCP, derefter CLS og INP, og se resultatet efter en måned. Et hurtigt site garanterer ikke en placering, men et langsomt site mister helt sikkert besøgende.

Kilder

• web.dev: Interaction to Next Paint (INP)
• HTTP Archive: Web Almanac 2025, Performance