Core Web Vitals: hva som reelt flytter tallene
Core Web Vitals er tre feltmålinger av hvordan en side føles: hvor lang tid det tar før hovedinnholdet dukker opp, hvor mye det hopper under lasting, og hvor raskt siden reagerer på inndata.
Denne guiden går gjennom hva hver måling måler, de konkrete årsakene bak dårlige verdier, og rettelsene som flytter feltdata snarere enn bare labscorer.
Hva de tre målingene måler#
Hver har en terskel for «god» og et lite sett vanlige årsaker. Merk at tallet som teller for plasseringer, er feltdata fra ekte besøkende, ikke en score fra din bærbare.
| Måling | God | Måler | Vanlig årsak ved dårlig verdi |
|---|---|---|---|
| LCP | Under 2,5 s | Tid til det største synlige elementet er tegnet | Uoptimalisert hovedbilde, treg server, blokkerende CSS |
| CLS | Under 0,1 | Hvor mye layouten hopper under lasting | Bilder uten mål, innskutte bannere, sent lastede skrifttyper |
| INP | Under 200 ms | Reaksjonshastighet ved interaksjon | Lange JavaScript-oppgaver som blokkerer hovedtråden |
Labverktøy måler én lasting på én maskin. Feltdata er 75. persentil av ekte besøk, inkludert gamle telefoner på dårlige nett — nettopp de besøkende som forsvinner raskest.
Å rette LCP#
LCP er nesten alltid et bilde eller en overskrift blokkert av noe annet. Gå gjennom punktene i rekkefølge; de to første løser de fleste sider.
- Finn ut hvilket element som reelt er LCP-elementet i feltdata. Å optimalisere feil bilde er det vanligste bortkastede arbeidet.
- Last aldri LCP-bildet utsatt. Gi det i stedet fetchpriority="high".
- Server det i moderne format i den størrelsen det vises i, med srcset for mindre skjermer.
- Forhåndslast skrifttypen til LCP-teksten og bruk font-display: swap.
- Fjern blokkerende CSS og JavaScript fra head; legg kritisk CSS inline om siden er liten nok.
- Senk Time to First Byte med cache og CDN — intet frontendarbeid veier opp for en treg server.
- Kutt tredjepartsskript fra den kritiske stien. Hvert er et DNS-oppslag, en forbindelse og en uforutsigbar fil.
Å rette CLS#
Hoppende layout kan nesten helt unngås, og rettelsene er billige. Det er også målingen besøkende merker sterkest — det er den som får folk til å trykke på feil ting.
- Sett width og height på hvert bilde og hver video, så nettleseren reserverer plass.
- Reserver plass til annonser, innbygginger og rammer med en beholder med fast sideforhold.
- Skyt aldri inn innhold over eksisterende etter lasting — informasjonskapselbanneret hører nederst eller som overlegg.
- Tilpass reserveskriftens mål til nettskriften, eller bruk size-adjust, så byttet ikke omorganiserer siden.
- Unngå å animere layoutegenskaper. Animer transform og opacity, som ikke fremtvinger ny beregning.
- Gi dynamisk lastede seksjoner en min-height, så de ikke folder ut fra null.
Å rette INP#
INP avløste First Input Delay og er vanskeligere, fordi den måler hver interaksjon under besøket snarere enn bare den første. Dårlig INP er nesten alltid for mye JavaScript på hovedtråden.
| Årsak | Rettelse |
|---|---|
| Stor pakke som behandles ved lasting | Del opp koden; last kun det siden bruker |
| Lange oppgaver over 50 ms | Del opp arbeidet og gi tråden tilbake |
| Dyre hendelseshåndterere | Debounce, og flytt tungt arbeid ut av interaksjonsstien |
| Tunge tredjepartsmerker | Last etter interaksjon, eller fjern — sjekk hva hvert gir |
| Stor DOM, over 10 000 noder | Virtualiser lange lister; forenkle dyp nesting |
| Vekslende lesing og skriving av layout | Samle lesinger og skrivinger i stedet for å veksle |
På innholdssider er det mest verdifulle INP-tiltaket som regel å fjerne JavaScript snarere enn å optimalisere det. Spør hva hvert skript gir; tag managers samler skript ingen husker å ha lagt til.
Ofte stilte spørsmål
Hvor mye påvirker Core Web Vitals plasseringen?
De er et reelt men beskjedent signal, som virker mer som avgjørelse ved uavgjort enn som erstatning for relevans. En rask side om feil tema slår ikke en tregere som besvarer spørsmålet. Det sterkere argumentet for å rette dem er atferd: trege og hoppende sider mister besøkende før plassering i det hele tatt kommer i spill.
Hvorfor har jeg god Lighthouse-score og dårlige feltdata?
Fordi Lighthouse simulerer én lasting på din maskin med din forbindelse, mens feltdata er 75. persentil av ekte besøk — inkludert tre år gamle telefoner på overbelastede mobilnett. Motsier de to hverandre, er det feltdata som gjelder. Bruk labverktøy til å diagnostisere, ikke til å score.
Må jeg rette alle tre målingene?
Rett dem som feiler, i rekkefølge etter hva besøkende opplever. CLS er som regel billigst å rette og mest irriterende for brukeren, så det er et godt sted å starte. LCP har størst effekt på om folk venter. INP betyr mest på interaktive sider og minst på statiske artikler.
Hvor lang tid går det før forbedringer viser seg?
Feltdata er et rullende vindu på 28 dager, så meningsfull bevegelse tar omtrent fire uker etter at rettelsen har nådd alle besøkende. Vurder ikke en endring etter tre dager. Sjekk til gjengjeld labverdiene med én gang for å bekrefte at rettelsen gjorde det du forventet.
core web vitalslcpclsinpsidehastighetwebytelse
