Core Web Vitals forklaret: LCP, INP og CLS på almindeligt dansk

Core Web Vitals er ikke en personlighedstest for dit website

Core Web Vitals bliver ofte behandlet som et mystisk karakterblad. En side får et rødt tal, nogen poster et screenshot i Slack, og teamet begynder at diskutere JavaScript-frameworks.

Det er ikke særligt nyttigt.

En bedre måde at tænke på Core Web Vitals er enklere: De er tre målinger af, om en side føles brugbar for et rigtigt menneske på en rigtig enhed. De indfanger ikke alle aspekter af performance, tilgængelighed eller kvalitet. Men de fanger tre almindelige kilder til frustration:

• Hovedindholdet er for længe om at blive vist.
• Siden reagerer langsomt, når brugeren prøver at gøre noget.
• Layoutet hopper rundt, mens brugeren læser eller trykker.

Det er de tre Core Web Vitals: LCP, INP og CLS.

Google bruger dem som en del af sine page experience-signaler, men SEO-vinklen er ikke den bedste grund til at bekymre sig om dem. Den bedre grund er, at langsomme, hoppende og uresponsive sider spilder brugernes tid. De har også en tendens til at konvertere dårligere, give mere supportarbejde og ældes dårligt.

De tre målinger i én sætning hver

Før vi går i detaljer, er her den korte version på almindeligt dansk:

• LCP, eller Largest Contentful Paint, måler, hvor lang tid det tager, før det vigtigste synlige indhold indlæses.
• INP, eller Interaction to Next Paint, måler, hvor hurtigt siden reagerer på brugerinteraktioner gennem besøget.
• CLS, eller Cumulative Layout Shift, måler, hvor meget siden uventet flytter sig rundt.

De sædvanlige grænseværdier er:

| Måling | God | Kræver forbedring | Dårlig | |---|---:|---:|---:| | LCP | 2,5s eller hurtigere | 2,5s–4,0s | Over 4,0s | | INP | 200ms eller hurtigere | 200ms–500ms | Over 500ms | | CLS | 0,1 eller lavere | 0,1–0,25 | Over 0,25 |

Disse tal vurderes normalt ved 75.-percentilen for rigtige brugerbesøg. Det er vigtigt. Du forsøger ikke at skabe én perfekt laboratoriekørsel. Du forsøger at gøre oplevelsen god for de fleste brugere, inklusive mennesker på langsommere telefoner og mere ustabile netværk.

Hvis du sidder med en automatiseret rapport og er usikker på, hvor du skal begynde, hjælper det at adskille diagnose fra panik. Vi har en separat guide til, hvordan man læser en Lighthouse-rapport uden at gå i panik, som gennemgår den arbejdsgang mere detaljeret.

LCP: Hvornår føles siden indlæst?

Largest Contentful Paint måler renderingstiden for det største synlige indholdselement i viewporten. I praksis er det ofte:

• et hero-billede,
• en stor overskrift,
• et fremhævet artikelbillede,
• et produktbillede,
• en stor tekstblok.

LCP spørger ikke, hvornår hvert script, tracking-pixel og billede under folden er færdigindlæst. Den spørger: Hvornår blev det vigtigste, brugeren kom for at se, synligt?

Det gør LCP til en mere menneskelig måling end gammeldags “page load time”. En side kan teknisk set blive færdig med at indlæse sent, men stadig føles hurtig, hvis hovedindholdet vises hurtigt. Det omvendte er også sandt: En side kan udløse load-eventen, mens hero-området stadig er tomt, sløret eller blokeret af en renderingsforsinkelse.

Almindelige årsager til dårlig LCP

De fleste dårlige LCP-problemer kommer fra nogle få forudsigelige steder:

1. Langsom serverrespons

Hvis HTML-dokumentet ankommer sent, starter alt andet sent.

1. Renderingsblokerende CSS eller JavaScript

Browseren har indholdet, men kan endnu ikke tegne det på skærmen.

1. Uoptimerede hero-billeder

Det største element er for stort, i det forkerte format, ikke prioriteret eller indlæses ved en fejl lazy.

1. Web fonts forsinker tekstvisning

En stor overskrift kan være LCP-elementet, og fontindlæsning kan forsinke eller visuelt ændre den.

1. Forsinkelser fra client-side rendering

Hvis siden har brug for en stor JavaScript-bundle, før den kan vise meningsfuldt indhold, lider LCP.

Sådan forbedrer du LCP

Start med det faktiske LCP-element. Optimer ikke tilfældige assets, før du ved, hvad browseren måler.

Praktiske forbedringer omfatter:

• Servér HTML hurtigt: cache hvor det giver mening, reducer backend-arbejde, undgå langsomme redirects.
• Optimer LCP-billedet: brug de rigtige dimensioner, komprimering og format.
• Lazy-load ikke hero-billedet over folden.
• Brug fetchpriority="high" med omtanke for hovedbilledet, når det virkelig er prioriteten.
• Inline kun kritisk CSS, når det reelt reducerer renderingsforsinkelse.
• Reducer den JavaScript, der kræves før den første meningsfulde rendering.
• Brug font-display: swap eller en anden bevidst fontstrategi.

Billeder og fonte er hyppige syndere. For billeder handler afvejningen ikke bare om “lille fil godt”. Formatvalg, kodningsindsats og browserunderstøttelse betyder også noget, og derfor har vi et praktisk beslutningstræ for hvornår AVIF slår WebP, og hvornår det ikke gør. På sider med meget tekst er web fonts stadig en af de nemmeste performance-gevinster, fordi mange websites sender flere fontfiler, end de bruger.

INP: Reagerer siden, når man rører ved den?

Interaction to Next Paint måler reaktionsevne. Mere præcist ser den på forsinkelsen mellem en brugerinteraktion og den næste visuelle opdatering, efter browseren har behandlet interaktionen.

Interaktioner omfatter ting som:

• at klikke på en knap,
• at trykke på en menu,
• at vælge en checkbox,
• at skrive i et formularfelt,
• at åbne en accordion.

INP erstattede First Input Delay som en Core Web Vital i 2024. Det var en god ændring. First Input Delay så kun på den første interaktion. INP er bredere: Den tager højde for interaktioner gennem hele sidebesøget og rapporterer en interaktion med høj latenstid som sidens reaktionsevnescore.

På almindeligt dansk: INP fanger sider, der ser indlæste ud, men føles fastlåste.

Du har sandsynligvis brugt en side som denne. Den ser klar ud. Du trykker på menuen. Der sker ingenting i et halvt sekund. Du trykker igen. Så sker to ting på én gang. Det er et INP-problem.

Almindelige årsager til dårlig INP

INP er normalt et problem på hovedtråden. Browseren vil gerne reagere, men JavaScript, renderingsarbejde eller layoutberegning står i vejen.

Typiske årsager omfatter:

• store JavaScript-bundles,
• tunge event handlers,
• hydrering i client-rendered apps,
• tredjepartsscripts, der konkurrerer om hovedtråden,
• langvarige tasks efter sideindlæsning,
• komplekse DOM-opdateringer udløst af små interaktioner,
• layout thrashing, hvor kode gentagne gange læser og skriver layoutværdier.

Marketing-tags, analytics, chat-widgets og samtykkebannere kan alle bidrage. Det betyder ikke “fjern alt”. Det betyder, at hvert script på siden har en omkostning, og interaktionslatenstid er ofte dér, den omkostning bliver synlig.

Sådan forbedrer du INP

At forbedre INP handler mindre om én magisk attribut og mere om at reducere konkurrence om hovedtråden.

Nyttige tilgange omfatter:

• Del lange JavaScript-tasks op i mindre bidder.
• Udskyd ikke-essentielt arbejde, indtil siden er brugbar.
• Fjern ubrugt JavaScript i stedet for blot at minificere det.
• Hold event handlers små og forudsigelige.
• Undgå at re-rendere store dele af grænsefladen ved små state-ændringer.
• Brug CSS til simple visuelle tilstande, hvor det er muligt.
• Gennemgå tredjepartsscripts, og indlæs dem kun, hvor de er nødvendige.

Se også på interaktionsdesign. En knap, der giver øjeblikkelig visuel feedback, kan føles mere responsiv, selv hvis efterfølgende arbejde tager længere tid. Det er ikke en erstatning for performance, men det er en del af god interface-engineering. Vores tjekliste for tilgængelige webknapper overlapper med dette: tydelige tilstande, korrekt semantik og forudsigelig adfærd hjælper både brugere og browsere.

CLS: Bliver siden dér, hvor brugeren forventer?

Cumulative Layout Shift måler uventet bevægelse af synlige elementer. Hvis en bruger begynder at læse et afsnit, og en annonce, et billede eller et banner indlæses over det og skubber teksten ned, bidrager det til CLS.

CLS måles ikke i sekunder. Det er en score baseret på, hvor meget indhold der flyttede sig, og hvor langt det flyttede sig. Lavere er bedre.

Nøgleordet er uventet. Layoutændringer forårsaget af en brugerhandling tælles normalt ikke på samme måde. Hvis nogen trykker på “vis mere”, og indhold udvides, er det forventet. Hvis et nyhedsbrevsbanner dukker op øverst efter tre sekunder og skubber alt ned, er det ikke.

Almindelige årsager til dårlig CLS

CLS-fejl er ofte jordnære:

• billeder uden width- og height-attributter,
• annoncer eller embeds uden reserveret plads,
• cookie-bannere indsat over indhold,
• web fonts, der skifter ind med andre metrics,
• sent indlæste kampagnebjælker,
• dynamisk injiceret indhold nær toppen af siden.

Løsningen er normalt at reservere plads, før indholdet ankommer. Browseren bør kende sidens form så tidligt som muligt.

Sådan forbedrer du CLS

Start med de synlige skift. Se en optagelse, eller brug browserværktøjer til at identificere, hvilke elementer der flytter sig.

Anvend derefter de kedelige løsninger:

• Tilføj eksplicitte width- og height-attributter til billeder.
• Brug CSS aspect-ratio til responsive mediecontainere.
• Reservér fast eller minimumsplads til annoncer, embeds og iframes.
• Undgå at injicere bannere over eksisterende indhold efter indlæsning.
• Vælg font-fallbacks med metrics, der ligner den endelige font.
• Undgå animationer, der ændrer layoutegenskaber som top, left, width eller height; foretræk transforms.

CLS er en af de få performance-målinger, hvor disciplin slår snilde. Hvis siden har stabile bokse, scorer den som regel godt.

Feltdata og laboratoriedata er begge nyttige, men de besvarer forskellige spørgsmål

En almindelig kilde til forvirring er, at forskellige værktøjer viser forskellige tal. Det er normalt.

Feltdata kommer fra rigtige brugere. De afspejler faktiske enheder, netværk, lokationer og browserforhold. Googles Chrome User Experience Report er et eksempel på feltdata.

Laboratoriedata kommer fra et kontrolleret testmiljø. Lighthouse er det velkendte eksempel. Det er gentageligt og nyttigt til debugging, men det er ikke det samme som dine brugeres oplevede virkelighed.

Brug feltdata til at afgøre, om brugerne har et reelt problem. Brug laboratoriedata til at reproducere og debugge det problem.

Husk også, at Core Web Vitals normalt vurderes pr. URL eller URL-gruppe, ikke som en enkelt abstrakt egenskab ved dit brand. Din forside, blogartikel, prisside og checkout kan have meget forskellige flaskehalse.

En fornuftig rækkefølge for arbejdet

Hvis alle tre målinger er dårlige, er fristelsen at begynde overalt. Lad være med det.

En praktisk rækkefølge er:

1. Ret åbenlyse CLS-problemer først

Manglende billeddimensioner og ustabile bannere er ofte hurtige gevinster.

1. Forbedr LCP for vigtige templates

Fokuser på sider, der betyder noget: produktsider, landingssider, artikler, tilmeldingsflows.

1. Undersøg INP med rigtige interaktioner

Klik på de ting, brugerne faktisk klikker på. Menuer, filtre, formularer og checkout-kontroller afslører ofte mere end den indledende load trace.

1. Gennemgå tredjepartsscripts

Behold dem, der retfærdiggør deres omkostning. Fjern eller forsink dem, der ikke gør.

1. Sæt et performance-budget

Uden et budget forfalder performance-forbedringer. Nye scripts, billeder og designkomponenter vil stille og roligt ophæve arbejdet.

Det vigtige punkt: Optimer ikke for et badge. Optimer for brugerrejsen. En marginal scoreforbedring på en side med lav trafik kan betyde mindre end en lidt uperfekt, men meget hurtigere checkout-interaktion.

<!-- tool-cta:start -->

💡 Prøv dette: Da LCP normalt er et billedproblem, så gør dit hero-aktiv mindre med Image Compressor som en første, nem gevinst.

<!-- tool-cta:end -->

Hvad Core Web Vitals ikke fortæller dig

Core Web Vitals er nyttige, men ufuldstændige.

De fortæller dig ikke, om dit indhold er godt. De fortæller dig ikke, om din navigation giver mening. De garanterer ikke tilgængelighed. De måler ikke privatliv, sikkerhed, tillid, læsbarhed eller om siden besvarer brugerens spørgsmål.

De erstatter heller ikke dømmekraft. En side kan bestå Core Web Vitals og stadig være ubehagelig. En kompleks applikation kan misse en grænseværdi og stadig være ansvarligt udviklet inden for sine begrænsninger.

Behandl LCP, INP og CLS som røgalarmer. Når de går i gang, så undersøg sagen. Når de er stille, så bliv ved med at vedligeholde bygningen.