Core Web Vitals – mål LCP, INP og CLS riktig
Core Web Vitals beskriver lasting, respons og visuell stabilitet for reelle brukere. Les feltdata først, finn hvilken del av målingen som feiler, og bruk labverktøy til å gjenskape årsaken.
Vymo · · 5 min lesing
Core Web Vitals er tre brukeropplevelsesmål fra Google: LCP for hovedinnholdets lasting, INP for respons på interaksjoner og CLS for uventede layoutskift.
Tallene er nyttige fordi de beskriver et resultat brukeren kan merke. De forteller ikke alene hvilken kode eller leverandør som er årsaken.
Tersklene
| Måling | God | Trenger forbedring | Dårlig |
|---|---|---|---|
| LCP | ≤ 2,5 sek | > 2,5 og ≤ 4,0 sek | > 4,0 sek |
| INP | ≤ 200 ms | > 200 og ≤ 500 ms | > 500 ms |
| CLS | ≤ 0,1 | > 0,1 og ≤ 0,25 | > 0,25 |
For å vurdere flertallet uten å skjule de svakere opplevelsene brukes 75-persentilen, separat for mobil og desktop. En verdi på 2,4 sekunder for LCP ved 75-persentilen betyr at minst 75 prosent av de målte sidevisningene var like raske eller raskere.
Google anbefaler gode Core Web Vitals for brukeropplevelse og søk, men relevans og innholdskvalitet er fortsatt sentralt. En grønn score garanterer ikke rangering, og en relevant side blir ikke automatisk usynlig fordi ett mål er gult. Les Googles beskrivelse av Core Web Vitals i søkeresultater .
Feltdata og labdata svarer på ulike spørsmål
| Datatype | Svarer på | Begrensning |
|---|---|---|
| CrUX-feltdata | Hvordan kvalifiserte Chrome-brukere faktisk opplevde URL-en eller origin | Aggregert, uten full kodekontekst og bare ved nok trafikk |
| Egen RUM | Hvilke brukere, sider og interaksjoner som opplever problemet | Krever instrumentering og personvernvurdering |
| Lighthouse/lab | Hva som skjer i én simulert innlasting | Ikke en representativ fordeling av reelle besøk |
| DevTools | Nøyaktig request-, hovedtråd- og layoutarbeid i en gjenskapt økt | Den testede enheten og handlingen er bare ett scenario |
PageSpeed Insights viser CrUX-feltdata for de foregående 28 dagene og en separat Lighthouse-test. Feltdataene oppdateres som et rullerende vindu; en retting i dag gir derfor ikke full utslag i morgen.
Kontroller alltid om feltpanelet gjelder den eksakte URL-en eller hele origin. Hvis URL-en ikke har nok data, kan origin-data beskrive en blanding av raske og trege sidetyper. Google forklarer 28-dagersvinduet, 75-persentilen og forskjellen på felt og lab .
Search Console grupperer URL-er med lignende opplevelse. Bruk gruppen til å finne et mønster, og test flere representative URL-er før dere endrer en felles mal.
LCP: Når vises hovedinnholdet?
Largest Contentful Paint måler når det største kvalifiserte innholdselementet i visningsområdet rendres. Det kan være et bilde, en poster for video eller en tekstblokk. Elementet kan endre seg under innlastingen.
Del LCP i fire deler:
- TTFB: ventetid til første byte av HTML
- resource load delay: tid før LCP-ressursen begynner å lastes
- resource load duration: selve overføringen
- element render delay: tid fra ressursen er klar til elementet vises
En høy TTFB kan peke mot redirects, origin, applikasjon, database eller cache. Sen ressursstart kan skyldes at bildet først oppdages i CSS eller JavaScript. Lang render delay kan skyldes blokkerende CSS, font eller hovedtrådarbeid.
Finn LCP-elementet og requesten i verktøyet før dere komprimerer tilfeldige bilder. Ikke lazy-load LCP-bildet; legg det i første HTML og prioriter det bare når det faktisk er kritisk. Googles LCP-guide viser hele oppdelingen.
INP: Hvor raskt kommer neste visuelle svar?
Interaction to Next Paint observerer klikk, trykk og tastaturinteraksjoner gjennom besøket. Målingen rapporterer normalt en av de tregeste interaksjonene, med en outlierregel for sider med svært mange interaksjoner.
En interaksjon består av:
- input delay: brukeren har handlet, men hovedtråden er opptatt før callbacks starter
- processing duration: event handlers kjører
- presentation delay: nettleseren beregner layout, tegner og viser neste bilde
Derfor er «mindre JavaScript» ikke alltid presist nok. Dere må vite om problemet ligger i en tidligere lang oppgave, selve handleren eller dyr rendering etterpå.
Gjenskap faktiske brukerflyter: åpne meny, skriv i søk, send skjema, bytt variant, legg i handlekurv. Test også mens siden fortsatt laster. Google beskriver hvordan INP brytes i tre deler og diagnostiseres fra felt til lab .
En Lighthouse-score kan gi nyttige signaler om hovedtrådarbeid, men en vanlig labinnlasting erstatter ikke feltmåling av interaksjoner gjennom et helt besøk.
CLS: Flytter innholdet seg uventet?
Cumulative Layout Shift måler uventede layoutskift. Dagens CLS-verdi bruker den største gruppen av raske skift: skiftene ligger mindre enn ett sekund fra hverandre, og gruppen varer maksimalt fem sekunder.
Vanlige årsaker:
- bilder eller video uten reservert sideforhold
- annonser, iframe eller embeds uten avsatt plass
- banner eller samtykkeboks som skyver eksisterende innhold
- fontbytte som endrer tekstens størrelse
- innhold som settes inn over det brukeren allerede leser
Sett width og height på bilder, eller reserver plass med CSS aspect-ratio. Registrer layout shifts i Performance-panelet og se hvilket element som flyttet seg – årsaken kan være et annet element som kom inn over det.
Felt-CLS kan være dårlig selv om labtesten ser stabil ut, fordi skift kan oppstå etter scrolling, samtykke, annonser eller andre handlinger. Se Googles forklaring av CLS og session windows for beregningen.
En praktisk arbeidsflyt
- Velg mobil eller desktop og noter 75-persentilen i feltdata.
- Kontroller om data gjelder URL eller origin.
- Finn sidemalen og brukergruppen med dårlig resultat.
- Gjenskap problemet i en realistisk labprofil.
- Identifiser element, interaksjon eller shift – ikke bare totalscoren.
- Del målingen i komponenter og rett den største delen.
- Sammenlign før og etter i samme laboppsett.
- Følg nye feltdata gjennom hele 28-dagersvinduet.
- Legg testen til i publiseringsløpet så feilen ikke kommer tilbake.
Endre én hovedfaktor om gangen når det er mulig. Ellers er det vanskelig å vite hva som hjalp eller skadet.
Hva kan hosting påvirke?
Hosting og plattform kan påvirke TTFB, cache, komprimering, transport, tilgjengelighet og hvor raskt HTML og ressurser leveres. Dette er særlig relevant for LCP.
INP bestemmes ofte mer av JavaScript, DOM og rendering på brukerens enhet. CLS skyldes ofte mal, bilder, fonter og dynamisk innhold. Et hostingskifte retter derfor ikke automatisk dårlige Core Web Vitals.
Bruk arbeidsflyten for en raskere nettside når dere har funnet den svake målingen, og webhotell-sjekklisten hvis serverlaget faktisk er flaskehalsen.
Core Web Vitals og Vymo
Vymo setter opp og publiserer én enkel, mobiltilpasset bedriftsside i standardtilbudet. Vymo lover foreløpig ikke en bestemt Core Web Vitals-verdi, Lighthouse-score eller serverplassering som en del av leveransen.
Har virksomheten et konkret ytelseskrav, oppgi URL-er, enhetstype og 75-persentilmål før bestilling. Send målegrunnlaget til Vymo så kan behovet vurderes, eller se om den enkle nettsiden passer .
Trenger bedriften en enkel nettside?
Vi lager én enkel nettside for bedriften og inkluderer hosting de første 12 månedene.