Core Web Vitals: för lite data i Search Console

Vad ”För lite användningsdata” betyder

Core Web Vitals-rapporten i Search Console visar hur verkliga Chrome-användare upplevde dina sidor. Varje gång någon med rätt inställningar i Chrome läser in en av dina sidor skickas besökets LCP, INP och CLS till Google och hamnar i ett offentligt dataset som kallas Chrome User Experience Report, eller CrUX. Search Console läser från det datasetet och visar siffrorna för dig. Tvärtemot vad de flesta tror besöker Search Console alltså inte din webbplats för att mäta den – den samlar bara in data från riktiga användare.

Finns det inte tillräckligt många sådana besök till dina sidor finns det inget att visa. Det är då du får ”För lite användningsdata under de senaste 90 dagarna för den här enhetstypen” för mobil eller dator, ibland båda.

Vissa ser det som ett dåligt tecken, men att data saknas säger ingenting om hur snabb eller långsam din webbplats är. Google har helt enkelt inte sett tillräckligt många av dina besökare för att kunna uttala sig.

Varför CrUX saknar data för din webbplats

Huvudorsaken är trafik. CrUX rapporterar bara en sida eller ett origin (protokoll plus domän, alltså https://www.example.com) när det är ”tillräckligt populärt”. Exakt vad det betyder säger Google inte – metodiksidan anger bara att tröskeln är tillräckligt hög för att fördelningen ska vara tillförlitlig.

Dessutom räknas bara en liten del av dina besökare mot den tröskeln till att börja med. CrUX samlar in data från personer i Chrome som har användningsstatistik påslagen, synkar sin webbhistorik och inte har någon lösenordsfras för synkning. Det gäller Chrome på dator och Chrome på Android. Chrome på iPhone räknas inte (under huven är det WebKit, precis som Safari), och varken Safari, Firefox, Edge eller webbläsaren i Instagram-appen räknas heller. På en webbplats med mycket iPhone-trafik hamnar de flesta besökare aldrig i datasetet. Mobil och dator räknas dessutom separat, så du kan ha data på dator men sakna data på mobil, eller tvärtom. Den enhet som har minst Chrome-trafik blir tom först.

Sedan måste själva sidan kvalificera sig. Allt som returnerar något annat än 200 efter omdirigeringar hoppas över. Sidor med en noindex-metatagg eller en X-Robots-Tag: noindex-header hoppas också över. Dessutom lägger Search Console till en egen regel: bara URL:er som faktiskt är indexerade visas i rapporten.

Har du precis lagt till egendomen i Search Console visas ändå ingenting till en början. Det löser sig av sig självt när Google väl har behandlat den.

Sidor utan data får originets poäng

Search Console rapporterar inte heller enskilda sidor, utan grupperar URL:er som liknar varandra. När en grupp saknar tillräckligt med egen data gör Search Console en fallback till originet – alltså alla URL:er med samma protokoll, värd och port. En sida som CrUX aldrig har sett kan därför ändå visas som Bra eller Dålig i din rapport, eftersom den lånar siffran från resten av webbplatsen.

I praktiken får startsidan och bloggen merparten av trafiken, så de avgör det där origin-värdet. Dina produktsidor eller kassan kan vara mycket långsammare utan att du någonsin ser det i Search Console. Det är också därför jag aldrig använder det övergripande CrUX-värdet som mål. Det är viktat efter trafik, så sidorna med flest besökare avgör siffran – och det är inte nödvändigtvis de sidorna du bryr dig om.

Lighthouse hjälper inte här

Rådet man ser överallt är att köra PageSpeed Insights eller Lighthouse tills CrUX-datan dyker upp. Jag förstår varför folk säger det, men det ger dig inte vad du behöver. En körning i Lighthouse laddar din sida en enda gång på en simulerad telefon med strypt anslutning och tom cache. Det fungerar bra för att hitta problem i själva sidan, men säger ingenting om vad dina besökare upplever.

INP kräver till exempel riktiga människor som klickar och trycker på riktiga enheter. Lighthouse klickar inte på någonting. För CLS slutar Lighthouse mäta så fort sidan har laddats klart. En sen annons som trycker ner innehållet, eller något som hoppar när besökaren skrollar, hamnar alltså aldrig i rapporten. Och LCP beror på telefonen, anslutningen och hur långt besökaren befinner sig från ditt CDN. En enskild testkörning har bara en av varje.

Att vänta fungerar bara om din trafik växer. CrUX tittar på besöken under de senaste 28 dagarna (fördröjningen är för övrigt betydligt kortare än folk tror, se varför fördröjningen på 28 dagar är en myt). Hade du inte tillräckligt många kvalificerade Chrome-besök den här månaden har du det förmodligen inte nästa månad heller.

Mät dina egna besökare med RUM

Alternativet är att mäta själv. Real user monitoring, RUM, kör ett litet skript i webbläsaren hos varje besökare, mäter besökets Core Web Vitals och skickar siffrorna till dig i stället för till Google. Samma typ av field data som CrUX, fast här finns ingen tröskel att nå och du är inte begränsad till Chrome-användare.

En sida med 50 besök i månaden får data. Detsamma gäller dina iPhone-besökare. Safari mäter LCP och INP sedan Safari 26.2 (december 2025), så de syns i RUM medan CrUX fortfarande utesluter dem. Du ser också vilket element som orsakade ett dåligt värde: bilden som var LCP, knappen som svarade långsamt. Efter en deploy ser du effekten inom några minuter i stället för någonstans i ett genomsnitt över 28 dagar.

Core/Dash är RUM-verktyget jag byggde för detta. En script-tagg, eller WordPress-pluginet, så börjar data komma in från första sidvisningen. Verktyget sätter inga kakor och samlar inte in några personuppgifter, så det behövs ingen samtyckesbanner. På en liten webbplats spelar det stor roll. Ett RUM-skript bakom en samtyckesbanner mäter bara dem som klickar på godkänn, och då är du tillbaka på en bråkdel av dina besökare. Priserna börjar på $16 i månaden vid årlig fakturering och provperioden på 14 dagar kräver inget kreditkort.

Låt det fortsätta köra även efter att CrUX har plockat upp din webbplats. Search Console visar bara URL-grupper och talar aldrig om vilken sida eller vilket element som gjorde en grupp långsam.

Kolla vad CrUX har om dig just nu

Innan du ändrar något, kontrollera om CrUX har ditt origin över huvud taget. Verktyget CrUX History på corewebvitals.io visar CrUX-historiken för vilken webbplats som helst. Är mobil tomt där är det tomt i Search Console också.

Se även: installera Core/Dash, webbläsardimensionen för besökarna som CrUX utesluter och enhetstypdimensionen för att dela upp mobil och dator.

Källor: Search Console Hjälp: Core Web Vitals-rapporten, CrUX-metodik, Safari 26.2 lägger till LCP och INP.