Core Web Vitals utan jargong.

Core Web Vitals är Googles försök att mäta något svårmätt: hur det känns att använda en sida. Tre mått, en fråga var. Gränsvärdena i tabellen nedan är hämtade från Googles egen definition på web.dev.

Mått	Frågan det svarar på	Bra	Behöver åtgärd	Dåligt
LCP Largest Contentful Paint	När syns huvudinnehållet?	≤ 2,5 s	2,5–4,0 s	> 4,0 s
INP Interaction to Next Paint	Hur snabbt reagerar sidan på klick?	≤ 200 ms	200–500 ms	> 500 ms
CLS Cumulative Layout Shift	Hoppar innehållet under laddning?	≤ 0,1	0,1–0,25	> 0,25

INP ersatte det gamla måttet FID i mars 2024 (web.dev om INP). Ser du fortfarande FID i ett verktyg eller en offert är materialet minst två år gammalt.

Detaljen nästan alla missar

Gränsvärdena mäts inte på ett snitt. De mäts på 75:e percentilen av dina faktiska besökare, rullande över 28 dagar. Det är så Chrome UX Report (CrUX) — datakällan Google faktiskt läser av — är konstruerad.

Det betyder att du inte optimerar för dig själv på fiber med en ny dator. Du optimerar för besökaren på fyra år gammal telefon med svajigt 4G i en bil på E6:an. Är den upplevelsen usel spelar det ingen roll att din egen är fin.

Vad som brukar orsaka vad

LCP — huvudinnehållet syns för sent

Nästan alltid en av fyra saker:

• En stor, ooptimerad hjältebild. En 3 MB JPEG överst på sidan är den vanligaste enskilda orsaken vi ser.
• Typsnitt som laddas sent. Rubriken finns men går inte att rita förrän typsnittet kommit hem.
• Innehåll som byggs med JavaScript. Webbläsaren måste ladda, tolka och köra kod innan texten finns.
• Långsam server. Mindre vanligt än folk tror, men det förekommer.

INP — sidan svarar trögt på klick

Handlar nästan alltid om JavaScript som blockerar huvudtråden. Klickar någon på en meny och webbläsaren är upptagen med att köra en analysskript-bunt, händer ingenting förrän den är klar. Vanliga bovar: chattwidgetar, cookiebanners som gör mer än de borde, och sidbyggare som skickar femhundra kilobyte kod till en sida med tre stycken text.

CLS — innehållet hoppar

Alltid samma grundorsak: något tar plats som webbläsaren inte visste om i förväg.

• Bilder utan width och height — webbläsaren reserverar ingen yta, texten hoppar när bilden kommer.
• Annonser och inbäddningar som skjuts in ovanför det du läser.
• Typsnittsbyte där reserv- och slutligt typsnitt har olika storlek.

CLS är också det billigaste måttet att fixa. Att sätta width och height på alla bilder tar en eftermiddag och löser oftast större delen.

Två sorters mätning — och bara den ena räknas

Det här förklarar varför ditt verktyg säger 98 och Search Console säger rött.

	Labbdata	Fältdata
Var det kommer ifrån	En simulerad körning, till exempel Lighthouse	Riktiga besökares webbläsare, samlat av Google (CrUX)
Fördel	Går att köra när som helst, ger felsökning	Är sanningen
Nackdel	Speglar inte dina besökares verklighet	Släpar 28 dagar, kräver trafikvolym
Används för ranking	Nej	Ja

Använd labbdata för att hitta problem. Bedöm aldrig läget på den.

Hur mycket betyder det för rankingen?

Mindre än verktygen antyder. Google har varit tydlig med att Core Web Vitals är en liten rankingfaktor, och att relevant innehåll slår snabb sida — se Search Centrals sida om sidupplevelse. En långsam sida som svarar exakt på frågan rankar över en snabb sida som inte gör det.

Men två saker gör det ändå värt arbetet:

1. Som utslagsgivare mellan likvärdiga sidor. När två sidor är lika relevanta blir prestanda det som skiljer.
2. Effekten på besökaren, som är större än rankingeffekten. Folk som väntar lämnar. Det syns i din konverteringsgrad långt innan det syns i din position.

Så kollar du din egen sajt

1. Search Console → Core Web Vitals. Fältdata, gratis, grupperat per sidtyp. Börja alltid här.
2. PageSpeed Insights. Klistra in en URL — visar fältdata överst och labbdata under. Läs den övre delen.
3. Har sidan för lite trafik för fältdata får du bara labbdata. Då gäller: fixa det uppenbara (bildstorlekar, bildmått, onödiga skript) och mät igen när trafiken kommit.