Core Web Vitals är tre mätvärden som Google använder för att beskriva viktiga delar av den verkliga användarupplevelsen på webben: hur snabbt huvudinnehållet blir synligt, hur snabbt sidan svarar på interaktioner och hur stabil layouten är medan sidan laddas och används.

De tre måtten är Largest Contentful Paint (LCP), Interaction to Next Paint (INP) och Cumulative Layout Shift (CLS). Googles rekommenderade nivåer för en god upplevelse är LCP på högst 2,5 sekunder, INP på högst 200 millisekunder och CLS på högst 0,1. Bedömningen görs normalt vid den 75:e percentilen, vilket betyder att minst tre av fyra besök bör klara den rekommenderade nivån.

LCP mäter när huvudinnehållet blir synligt

LCP mäter tiden tills det största synliga text- eller bildelementet i den första vyn har renderats. På många sidor är det en hero-bild, en stor rubriksektion eller ett annat centralt innehållsblock.

Ett högt LCP-värde kan bero på flera saker: långsam serverrespons, tunga bilder, renderingsblockerande CSS eller JavaScript, sena resursanrop eller att webbläsaren upptäcker det viktigaste elementet för sent. Därför är det bättre att först identifiera vilket element som faktiskt är LCP-elementet än att optimera slumpmässiga filer.

INP mäter hur sidan reagerar när användaren gör något

INP bedömer sidans respons under användarens besök. Måttet tittar på interaktioner som klick, tryck och tangentbordsinmatning och hur lång tid det tar innan nästa visuella uppdatering kan visas.

Vanliga orsaker till svag INP är långa JavaScript-uppgifter på huvudtråden, stora komponentträd, tunga tredjepartsskript och händelsehanterare som gör för mycket arbete innan gränssnittet får ritas om. Det räcker alltså inte att sidan laddar snabbt om den sedan känns trög när användaren försöker använda den.

CLS mäter oväntade layoutförflyttningar

CLS mäter visuell stabilitet. Ett klassiskt problem är att text eller knappar flyttar sig när en bild, annons, cookie-komponent eller webfont laddas in efteråt.

För att minska CLS bör viktiga ytor reserveras i förväg. Bilder och video bör ha kända dimensioner eller ett definierat bildförhållande, dynamiska komponenter bör få utrymme innan de fylls och innehåll bör inte skjutas ned oväntat efter att användaren börjat läsa eller interagera.

Fältdata och labbdata är inte samma sak

PageSpeed Insights och Chrome-ekosystemet kan visa både data från verkliga användare och kontrollerade laboratorietester. De två typerna av data svarar på olika frågor.

Fältdata visar hur verkliga besök fungerar på olika enheter och nätverk. Googles Chrome User Experience Report, CrUX, är en viktig källa för den typen av mätning. Labbdata är användbar för felsökning eftersom samma test kan upprepas under kontrollerade förhållanden.

En sida kan därför få ett bra Lighthouse-resultat i ett enskilt test men ändå ha svag fältdata, eller tvärtom. Vid prioritering bör du först förstå vilken datakälla du tittar på och vilken tidsperiod den representerar.

Så prioriterar du förbättringarna

  1. Identifiera vilket Core Web Vital som faktiskt missar gränsvärdet. Optimera inte alla tre samtidigt utan diagnos.
  2. Kontrollera fältdata. Se om problemet gäller många verkliga besök eller bara ett enskilt labbtest.
  3. Hitta den konkreta orsaken. För LCP kan det vara en hero-bild eller TTFB, för INP en lång huvudtrådsuppgift och för CLS en komponent utan reserverad yta.
  4. Mät efter ändringen. Ett snabbare testvärde är bra, men följ också utvecklingen i verklig användardata.

Jaga inte ett perfekt tal

Core Web Vitals är kvalitetsmått, inte ett mål om att varje sida måste nå noll millisekunder eller noll layoutförskjutning. Googles trösklar är framtagna för att skilja god, förbättringsbar och svag användarupplevelse. För webbplatsägaren är den mest praktiska strategin att först få de viktigaste sidtyperna stabilt inom den goda nivån och därefter optimera vidare där det ger verklig nytta.

Källor