Core Web Vitals: hvad der reelt flytter tallene
Core Web Vitals er tre feltmålinger af, hvordan en side føles: hvor lang tid der går, før hovedindholdet dukker op, hvor meget det hopper under indlæsning, og hvor hurtigt siden reagerer på input.
Denne guide gennemgår, hvad hver måling måler, de konkrete årsager bag dårlige værdier, og de rettelser der flytter feltdata frem for blot labscorer.
Hvad de tre målinger måler#
Hver har en tærskel for «god» og et lille sæt sædvanlige årsager. Bemærk at det tal, der tæller for placeringer, er feltdata fra rigtige besøgende, ikke en score fra din bærbare.
| Måling | God | Måler | Sædvanlig årsag ved dårlig værdi |
|---|---|---|---|
| LCP | Under 2,5 s | Tid til det største synlige element er tegnet | Uoptimeret hovedbillede, langsom server, blokerende CSS |
| CLS | Under 0,1 | Hvor meget layoutet hopper under indlæsning | Billeder uden mål, indskudte bannere, sent indlæste skrifttyper |
| INP | Under 200 ms | Reaktionshastighed ved interaktion | Lange JavaScript-opgaver der blokerer hovedtråden |
Labværktøjer måler én indlæsning på én maskine. Feltdata er 75. percentil af rigtige besøg, inklusive gamle telefoner på dårlige net — netop de besøgende der forsvinder hurtigst.
At rette LCP#
LCP er næsten altid et billede eller en overskrift blokeret af noget andet. Gå punkterne igennem i rækkefølge; de to første løser de fleste sider.
- Find ud af hvilket element der reelt er LCP-elementet i feltdata. At optimere det forkerte billede er det hyppigste spildte arbejde.
- Indlæs aldrig LCP-billedet udskudt. Giv det i stedet fetchpriority="high".
- Servér det i moderne format i den størrelse, det vises i, med srcset til mindre skærme.
- Forudindlæs skrifttypen til LCP-teksten og brug font-display: swap.
- Fjern blokerende CSS og JavaScript fra head; læg kritisk CSS inline, hvis siden er lille nok.
- Sænk Time to First Byte med cache og CDN — intet frontendarbejde opvejer en langsom server.
- Skær tredjepartsscripts fra den kritiske sti. Hvert er et DNS-opslag, en forbindelse og en uforudsigelig fil.
At rette CLS#
Hoppende layout kan næsten helt undgås, og rettelserne er billige. Det er også den måling, besøgende mærker stærkest — det er den, der får folk til at trykke på det forkerte.
- Sæt width og height på hvert billede og hver video, så browseren reserverer plads.
- Reservér plads til annoncer, indlejringer og iframes med en container med fast sideforhold.
- Indsæt aldrig indhold over eksisterende efter indlæsning — cookiebanneret hører nederst eller som overlejring.
- Tilpas reserveskrifttypens mål til webskrifttypen, eller brug size-adjust, så skiftet ikke omarrangerer siden.
- Undgå at animere layoutegenskaber. Animér transform og opacity, som ikke fremtvinger genberegning.
- Giv dynamisk indlæste sektioner en min-height, så de ikke folder ud fra nul.
At rette INP#
INP afløste First Input Delay og er sværere, fordi den måler hver interaktion under besøget frem for kun den første. Dårlig INP er næsten altid for meget JavaScript på hovedtråden.
| Årsag | Rettelse |
|---|---|
| Stor pakke der behandles ved indlæsning | Del koden op; indlæs kun det siden bruger |
| Lange opgaver over 50 ms | Del arbejdet op og giv tråden tilbage |
| Dyre hændelseshåndteringer | Debounce, og flyt tungt arbejde ud af interaktionsstien |
| Tunge tredjepartstags | Indlæs efter interaktion, eller fjern — tjek hvad hvert giver |
| Stor DOM, over 10.000 knuder | Virtualisér lange lister; forenkl dyb indlejring |
| Skiftende læsning og skrivning af layout | Saml læsninger og skrivninger i stedet for at skifte |
På indholdssider er den mest værdifulde INP-indgriben som regel at fjerne JavaScript frem for at optimere det. Spørg hvad hvert script giver; tag managers samler scripts, ingen husker at have tilføjet.
Ofte stillede spørgsmål
Hvor meget påvirker Core Web Vitals placeringen?
De er et reelt men beskedent signal, der virker mere som afgørelse ved uafgjort end som erstatning for relevans. En hurtig side om det forkerte emne slår ikke en langsommere, der besvarer spørgsmålet. Det stærkere argument for at rette dem er adfærd: langsomme og hoppende sider mister besøgende, før placering overhovedet kommer i spil.
Hvorfor har jeg god Lighthouse-score og dårlige feltdata?
Fordi Lighthouse simulerer én indlæsning på din maskine med din forbindelse, mens feltdata er 75. percentil af rigtige besøg — inklusive tre år gamle telefoner på overbelastede mobilnet. Modsiger de to hinanden, er det feltdata der gælder. Brug labværktøjer til at diagnosticere, ikke til at score.
Skal jeg rette alle tre målinger?
Ret dem der fejler, i rækkefølge efter hvad besøgende oplever. CLS er som regel billigst at rette og mest irriterende for brugeren, så det er et godt sted at starte. LCP har størst effekt på, om folk venter. INP betyder mest på interaktive sider og mindst på statiske artikler.
Hvor lang tid går der, før forbedringer viser sig?
Feltdata er et rullende vindue på 28 dage, så meningsfuld bevægelse tager cirka fire uger, efter rettelsen har nået alle besøgende. Vurdér ikke en ændring efter tre dage. Tjek til gengæld labværdierne med det samme for at bekræfte, at rettelsen gjorde det, du forventede.
core web vitalslcpclsinpsidehastighedwebydeevne
