Core Web Vitals: ikke nok data i Search Console

Hva «Ikke nok bruksdata» betyr

Core Web Vitals-rapporten i Search Console viser hvordan reelle Chrome-brukere opplevde sidene dine. Hver gang noen i Chrome med de rette innstillingene laster en av sidene dine, blir LCP, INP og CLS for besøket sendt til Google og havner i et offentlig datasett kalt Chrome User Experience Report, forkortet til CrUX. Search Console henter data fra dette datasettet og viser dem til deg. I motsetning til hva mange tror, måler altså ikke Search Console nettstedet ditt ved å besøke det. Verktøyet samler bare inn reelle brukerdata.

Når det ikke finnes nok slike besøk for sidene dine, er det ingenting å vise. Det er da du får «Ikke nok bruksdata de siste 90 dagene for denne enhetstypen» for mobil eller desktop, noen ganger begge.

Noen tolker det som et dårlig tegn, men manglende data sier ingenting om hvor raskt eller tregt nettstedet ditt er. Google har bare ikke sett nok av de besøkende dine til å si noe om det.

Hvorfor CrUX ikke har data for nettstedet ditt

Hovedårsaken er trafikk. CrUX rapporterer bare en side eller et origin (protokoll pluss domene, altså https://www.example.com) når den er «tilstrekkelig populær». Nøyaktig hva det betyr, sier ikke Google. Metodologisiden nevner bare at terskelen er høy nok til å gi en pålitelig fordeling.

I utgangspunktet teller bare en liten del av de besøkende dine med mot denne terskelen. CrUX samler inn data fra personer på Chrome som har slått på bruksstatistikk, synkroniserer nettleserloggen og ikke har passordfrase for synkronisering. Det vil si Chrome på desktop og Chrome på Android. Chrome på iPhone telles ikke (den bruker WebKit i bunnen, akkurat som Safari), og verken Safari selv, Firefox, Edge eller nettleseren i Instagram-appen telles. På et nettsted med mye iPhone-trafikk havner de fleste besøkende aldri i datasettet. Mobil og desktop telles også hver for seg, så du kan ha data på desktop og ingen data på mobil, eller omvendt. Enheten med minst Chrome-trafikk går tom først.

I tillegg må selve siden kvalifisere seg. Alt som returnerer noe annet enn 200 etter omdirigeringer, hoppes over. Sider med en noindex-metatagg eller en X-Robots-Tag: noindex-header hoppes også over. Search Console legger til en egen regel på toppen av dette: Bare URL-er som faktisk er indeksert, dukker opp i rapporten.

Har du nettopp lagt til området i Search Console, vises det uansett ingenting den første tiden. Det ordner seg så snart Google har prosessert det.

Sider uten data får origin-scoren

Search Console rapporterer heller ikke på enkeltsider, men grupperer URL-er som ligner på hverandre. Når en gruppe ikke har nok egne data, faller Search Console tilbake på origin – altså alle URL-er på samme protokoll, host og port. En side CrUX aldri har sett, kan likevel dukke opp som «God» eller «Dårlig» i rapporten din, fordi den låner tallet fra resten av nettstedet ditt.

I praksis får forsiden og bloggen mesteparten av trafikken, så de bestemmer origin-tallet. Produktsidene dine eller kassen kan være mye tregere uten at du noen gang ser det i Search Console. Derfor bruker jeg aldri CrUX-tallet for hele nettstedet som mål: Det er vektet etter trafikk, så de travleste sidene dine avgjør det – og det er ikke nødvendigvis de sidene du bryr deg mest om.

Lighthouse hjelper ikke her

Rådet du finner overalt, er å kjøre PageSpeed Insights eller Lighthouse frem til CrUX-dataene dukker opp. Jeg forstår hvorfor folk sier det, men det gir deg ikke det du trenger. En Lighthouse-kjøring laster siden din én gang på en simulert telefon med strupet tilkobling og tom cache. Fint for å finne problemer på selve siden, men det sier ingenting om hva de besøkende dine opplever.

INP krever for eksempel at ekte mennesker klikker og trykker på ekte enheter – Lighthouse klikker ikke på noe som helst. For CLS slutter Lighthouse å følge med så snart siden er lastet. En treg annonse som forskyver innholdet, eller et element som hopper når den besøkende scroller, havner aldri i rapporten. Og LCP avhenger av telefonen, tilkoblingen og hvor langt unna CDN-et ditt den besøkende er. En enkelt testkjøring har bare én av hver.

Å vente fungerer bare hvis trafikken din vokser. CrUX ser på de siste 28 dagene med besøk (forsinkelsen er for øvrig mye kortere enn folk tror, se hvorfor forsinkelsen på 28 dager er en myte). Hadde du ikke nok kvalifiserende Chrome-besøk denne måneden, har du det sannsynligvis ikke neste måned heller.

Mål dine egne besøkende med RUM

Alternativet er å måle det selv. Real user monitoring, RUM, kjører et lite skript i nettleseren til hver besøkende, måler Core Web Vitals for besøket og sender tallene til deg i stedet for til Google. Samme type field data som CrUX, bare at du her ikke har noen terskel å nå, og du er ikke begrenset til Chrome-brukere.

En side med 50 besøk i måneden har data. Det samme gjelder de besøkende dine på iPhone. Safari måler LCP og INP fra og med Safari 26.2 (desember 2025), så de dukker opp i RUM mens CrUX fremdeles utelater dem. Du ser også hvilket element som forårsaket et dårlig tall: bildet som var LCP, knappen som svarte tregt. Etter en deploy ser du effekten i løpet av minutter, i stedet for et sted i et gjennomsnitt over 28 dager.

Core/Dash er RUM-verktøyet jeg bygde for dette. Én script-tagg, eller WordPress-pluginen, og dataene begynner å komme inn med første sidevisning. Det setter ingen cookies og samler ikke inn persondata, så du trenger ikke noe samtykkebanner. På et lite nettsted betyr dette mye: Et RUM-skript bak et samtykkebanner måler bare dem som klikker godkjenn, og da sitter du igjen med bare en brøkdel av de besøkende dine. Prisene starter på $16 i måneden fakturert årlig, og prøveperioden på 14 dager krever ikke kredittkort.

La det kjøre videre også etter at CrUX fanger opp nettstedet ditt. Search Console viser bare URL-grupper, og forteller deg aldri hvilken side eller hvilket element som gjorde en gruppe treg.

Sjekk hva CrUX har om nettstedet ditt akkurat nå

Før du endrer noe, sjekk om CrUX har origin-et ditt i det hele tatt. CrUX History-verktøyet på corewebvitals.io viser CrUX-historikken for ethvert nettsted. Er mobil tom der, er den tom i Search Console også.

Se også: installere Core/Dash, nettleserdimensjonen for de besøkende CrUX utelater, og enhetstypedimensjonen for å skille mellom mobil og desktop.

Kilder: Search Console Hjelp: Core Web Vitals-rapporten, CrUX-metodologi, Safari 26.2 legger til LCP og INP.