Core Web Vitals & Technical UX

Core Web Vitals är Googles försök att sätta siffror på något som annars är en känsla: hur det är att använda er webbplats. Måtten är få, tröskelvärdena är offentliga och datan kommer från verkliga besökare. Det gör dem till ett av de få ställen inom teknisk SEO där ni kan se exakt var ni står och exakt vad som behöver förbättras.

Vad är Core Web Vitals?

Core Web Vitals (CWV) är tre mått som tillsammans beskriver hur snabbt sidan blir användbar, hur snabbt den svarar när någon interagerar, och hur stilla den ligger under laddningen.

Var för sig säger de inte mycket. Tillsammans efterliknar de ganska väl vad en besökare faktiskt upplever.

Largest Contentful Paint (LCP)

LCP mäter tiden till att sidans största bild eller textblock har renderats i vyn, räknat från att laddningen börjar. Tidigare tittade man på First Contentful Paint, men det största elementet beskriver upplevelsen bättre: det är då sidan känns klar. Bra LCP ligger under 2,5 sekunder.

De vanligaste bovarna är stora hero-bilder i gamla format, typsnitt som blockerar renderingen och långsamma serversvar.

Interaction to Next Paint (INP)

INP mäter hur responsiv sidan är genom hela sitt liv. Webbläsaren loggar varje interaktion från laddningens början till att besökaren lämnar, och det sämsta värdet blir sidans INP. Måttet räknar hela kedjan: fördröjningen innan klicket börjar behandlas, behandlingstiden, och tiden till att nästa bildruta visar resultatet. Bra INP ligger under 200 millisekunder.

Cumulative Layout Shift (CLS)

CLS uppskattar den visuella instabiliteten efter första rendering, alltså hur mycket innehållet hoppar. Poängen räknas som andelen av vyn som påverkas multiplicerat med hur långt elementen flyttar sig, och bara oväntade förflyttningar räknas, så en webbplats straffas inte för medvetna designval. Bra CLS är 0,1 eller lägre.

Klassikern bakom en dålig CLS-poäng är bilder utan angivna dimensioner, annonsplatser som fylls sent och banners som skjuts in ovanför innehållet.

Varför FID försvann

Fram till 2024 var det tredje måttet First Input Delay. FID mätte bara fördröjningen före behandlingen av den första interaktionen, alltså inte behandlingstiden och inte renderingen. I praktiken klarade nästan alla webbplatser gränsvärdet med marginal, vilket gjorde måttet oanvändbart som skiljelinje.

INP ersatte FID i mars 2024 och löser precis det. I stället för förstahandsintrycket bedöms hela sidan, och i stället för en enskild interaktion räknas grupper av interaktioner inom en handling. Har ni äldre dokumentation eller rapporter som fortfarande nämner FID är de föråldrade.

TTFB: diagnostiken, inte betyget

Time to First Byte är inget Core Web Vital. Det är ett diagnostiskt mått som förklarar varför de andra ser ut som de gör. TTFB mäter tiden från att en begäran skickas till att serverns första byte kommer tillbaka, och en hög TTFB drar med sig LCP direkt. Måttet syns i CrUX-rapporten, i Chromes nätverkspanel och i testverktyg som WebPageTest.

Field data slår lab data

CWV kan mätas på två sätt, och skillnaden spelar roll när ni ska tolka en rapport.

Lab data är en simulering: sidan mäts under kontrollerade förhållanden med standardiserad hårdvara och strypt bandbredd, för att ge en konservativ uppskattning. Det är vad Lighthouse ger er, och det är utmärkt för felsökning.

Field data är mätningar från riktiga besökare med riktiga enheter och riktiga uppkopplingar. Det är den data som Google faktiskt använder, och den finns i Chrome User Experience Report och i Search Console. Bedömer ni webbplatsen enbart på lab data kan ni sitta med gröna siffror medan besökarna upplever något annat.

Så förbättrar ni INP

Målet är lätt att formulera och jobbigt att genomföra: det som ska hända direkt ska hända direkt, och allt annat får vänta.

• Hitta long tasks. I Chrome DevTools under Performance spelar ni in en sidladdning och får en tidslinje över vad som blockerar huvudtråden. Allt över 50 millisekunder är en kandidat.
• Mät hur mycket kod som faktiskt körs. Coverage-fliken i DevTools visar hur stor andel av varje fil som aldrig körs hos besökaren. Röda staplar är kod som ni levererar men inte använder.
• Dela upp paketen. Code splitting flyttar det som inte behövs vid första rendering till senare. Det är den enskilt största vinsten på tunga sajter, och hänger tätt samman med hur ni renderar över huvud taget, vilket vi går igenom i guiden till JavaScript, SEO och rendering.
• Lämna tillbaka huvudtråden. Bryt långa uppgifter i mindre bitar och låt webbläsaren hinna rita mellan dem, i stället för att låta ett skript hålla tråden i en halv sekund.

Så förbättrar ni TTFB

TTFB bestäms till stor del av hosting och backend. Därför är det oftare ett samtal med utvecklingsteamet än en ren SEO-uppgift.

• Rensa i redirect-kedjorna. Har en sida två eller fler omdirigeringar i rad dyker det upp i Lighthouse och kostar direkt i TTFB. Hur ni håller ordning på det finns i guiden till site health och redirects.
• Använd HTTP/2 eller HTTP/3. Båda levererar resurser märkbart effektivare än HTTP/1.1.
• Föranslut det som ändå ska hämtas. Typsnitt, stilmallar och skript från andra domäner kan förberedas med resource hints. Det låter som en detalj, men Splunk har rapporterat att de sänkte sin time to interactive med 37 % med just resource hints.
• Bygger ni nytt, så välj rätt från början. En snabb webbserver med bra infrastruktur är betydligt billigare att välja än att migrera till.

Så använder vi Core Web Vitals i praktiken

Arbetsgången är densamma varje gång: undersök, analysera, genomför.

När vi arbetade med Brödernas rapporterade PageSpeed Insights problem i alla tre kategorierna. Genom att gå igenom de URL:er som CWV-rapporten flaggade blev det tydligt att det som faktiskt påverkade upplevelsen var CLS.

Analysen av de drabbade sidorna pekade på ett enda mönster. Bilderna låg i gamla format, PNG och JPG, tog för mycket resurser att ladda, kom in sent och sköt layouten ur läge mitt framför besökaren. Med rätt format och angivna dimensioner föll CLS-poängen på plats.

Poängen med exemplet är verktygsvalet. PageSpeed Insights ger er ögonblicksbilden av en enskild sida. Search Console-rapporten över Core Web Vitals ger er vilka sidgrupper som faktiskt drabbar besökare, baserat på field data. Först i kombination pekar de ut vad som ska göras först.

Vad CWV betyder för rankings

Låt oss vara raka: Core Web Vitals är sällan det som lyfter er från position elva till position tre. Innehåll, relevans och auktoritet väger tyngre. Men måtten fungerar som tröskel och skiljelinje. Står det jämnt mellan er och en konkurrent är det upplevelsen som skiljer, och en sida som är trög att använda tappar besökare innan de hinner konvertera, helt oberoende av vad Google tycker.

Samma sak gäller på AI-ytorna. En sida som renderas långsamt eller kräver mycket JavaScript för att visa sitt innehåll är svårare för både Googles crawler och AI-crawlerna att läsa och citera korrekt.

Vill ni veta var era sidor faktiskt står i field data, och vilka som är värda att åtgärda först, ligger genomgången i våra tekniska audits. Vill ni börja bredare täcker vår gratis SEO-analys både den tekniska basen och synligheten över klassisk search och AI-search.