Core Web Vitals: onvoldoende data in Search Console

Wat "Onvoldoende gebruiksgegevens" betekent

Het Core Web Vitals-rapport in Search Console laat zien hoe echte Chrome-gebruikers je pagina's hebben ervaren. Elke keer dat iemand met de juiste instellingen in Chrome een van je pagina's laadt, worden de LCP, INP en CLS van dat bezoek naar Google gestuurd. Die data komt terecht in een openbare dataset: het Chrome User Experience Report, kortweg CrUX. Search Console leest die dataset uit en toont de cijfers aan jou. In tegenstelling tot wat de meeste mensen denken meet Search Console je site dus niet door hem zelf te bezoeken; het verzamelt alleen data van echte gebruikers.

Zijn er voor je pagina's niet genoeg van die bezoeken, dan valt er niets te tonen. Dan krijg je de melding "Onvoldoende gebruiksgegevens in de afgelopen 90 dagen voor dit apparaattype" te zien voor mobiel of desktop, soms allebei.

Sommige mensen zien dat als een slecht teken, maar geen data zegt niets over hoe snel of traag je site is. Google heeft simpelweg niet genoeg van je bezoekers gezien om er iets over te kunnen zeggen.

Waarom CrUX geen data heeft over je site

De belangrijkste reden is verkeer. CrUX rapporteert een pagina of origin (protocol plus domein, dus https://www.example.com) pas als die "voldoende populair" is. Wat dat precies betekent zegt Google niet; de pagina over de methodologie meldt alleen dat de drempel hoog genoeg is om zeker te zijn van de verdeling.

En om te beginnen telt maar een klein deel van je bezoekers mee voor die drempel. CrUX verzamelt alleen gegevens van Chrome-gebruikers die gebruiksstatistieken hebben ingeschakeld, hun browsegeschiedenis synchroniseren en geen synchronisatiewachtwoord hebben. Dat betekent Chrome op desktop en Chrome op Android. Chrome op de iPhone telt niet mee (onder de motorkap is dat WebKit, net als Safari), en Safari zelf, Firefox, Edge en de browser in de Instagram-app tellen ook niet mee. Op een site met veel iPhone-verkeer belanden de meeste bezoekers dus nooit in de dataset. Mobiel en desktop worden bovendien apart geteld. Je kunt dus data hebben op desktop en niets op mobiel, of andersom. Het apparaat met het minste Chrome-verkeer blijft als eerste leeg.

Daarnaast moet de pagina zelf aan de voorwaarden voldoen. Alles wat na redirects iets anders dan een 200 teruggeeft, wordt overgeslagen. Pagina's met een noindex-metatag of een X-Robots-Tag: noindex-header worden ook overgeslagen. Search Console voegt daar nog een eigen regel aan toe: alleen URL's die echt zijn geïndexeerd komen in het rapport.

Heb je de property pas net toegevoegd aan Search Console, dan zie je in het begin sowieso niets. Dat lost zichzelf op zodra Google alles heeft verwerkt.

Pagina's zonder data krijgen de score van de origin

Search Console rapporteert ook niet over losse pagina's, maar groepeert URL's die op elkaar lijken. Heeft een groep zelf niet genoeg data, dan valt Search Console terug op de origin: elke URL op hetzelfde protocol, dezelfde host en dezelfde poort. Zo kan een pagina die CrUX nog nooit heeft gezien toch als Goed of Slecht in je rapport verschijnen, omdat die het cijfer leent van de rest van je site.

In de praktijk trekken de homepage en het blog het meeste verkeer, dus die bepalen dat origin-cijfer. Je productpagina's of je checkout kunnen veel trager zijn zonder dat je dat ooit in Search Console ziet. Daarom gebruik ik het CrUX-cijfer voor de hele site nooit als doel. Het wordt gewogen op basis van verkeer, waardoor je drukste pagina's het bepalen. En dat zijn niet per se de pagina's waar het jou om gaat.

Lighthouse helpt hier niet

Het advies dat je overal tegenkomt, is om PageSpeed Insights of Lighthouse te draaien totdat de CrUX-data verschijnt. Ik begrijp waarom men dat zegt, maar het levert je niet op wat je nodig hebt. Een Lighthouse-run laadt je pagina één keer op een gesimuleerde telefoon met een gethrottlede verbinding en een lege cache. Prima om problemen in de pagina zelf te vinden, maar het zegt niets over wat je bezoekers ervaren.

Voor INP heb je bijvoorbeeld echte mensen nodig die klikken en tikken op echte apparaten; Lighthouse klikt nergens op. Bij CLS stopt Lighthouse met kijken zodra de pagina is geladen. Een late advertentie die de content omlaag drukt, of iets dat verspringt zodra de bezoeker scrollt, komt dus nooit in het rapport terecht. En de LCP hangt af van de telefoon, de verbinding en hoe ver de bezoeker van je CDN zit. Een enkele testrun test er van elk maar één.

Afwachten werkt alleen als je verkeer groeit. CrUX kijkt naar de bezoeken van de afgelopen 28 dagen (die vertraging is trouwens een stuk korter dan men denkt, zie waarom de vertraging van 28 dagen een mythe is). Had je deze maand niet genoeg geldige Chrome-bezoeken, dan heb je die volgende maand waarschijnlijk ook niet.

Meet je eigen bezoekers met RUM

Het alternatief is om het zelf te meten. Real user monitoring, RUM, draait een klein script in de browser van elke bezoeker, meet de Core Web Vitals van dat bezoek en stuurt de cijfers naar jou in plaats van naar Google. Hetzelfde type field data als CrUX, alleen hoef je nu geen drempel te halen en zit je niet vast aan Chrome-gebruikers.

Een pagina met 50 bezoeken per maand heeft al data. Net als je iPhone-bezoekers: Safari meet LCP en INP sinds Safari 26.2 (december 2025), dus die verschijnen in RUM terwijl CrUX ze nog altijd weglaat. Je ziet ook welk element voor een slechte score zorgde: de afbeelding die de LCP was, of de knop die traag reageerde. Na een deploy zie je het effect binnen enkele minuten, in plaats van ergens in een gemiddelde over 28 dagen.

Core/Dash is de RUM-tool die ik hiervoor heb gebouwd. Eén script-tag, of de WordPress-plugin, en de data komt binnen vanaf de eerste pageview. Het plaatst geen cookies en verzamelt geen persoonsgegevens, dus er is geen cookiebanner nodig. Op een kleine site maakt dat veel uit: een RUM-script achter een cookiebanner meet alleen de mensen die op akkoord klikken, waardoor je weer terug bent bij een fractie van je bezoekers. Pakketten beginnen bij $16 per maand bij jaarlijkse betaling, en voor de proefperiode van 14 dagen is geen creditcard nodig.

Laat het actief als CrUX je site eenmaal oppikt. Search Console toont alleen URL-groepen en vertelt je nooit welke pagina of welk element een groep traag maakte.

Controleer direct wat CrUX over je heeft

Controleer voordat je iets aanpast eerst of CrUX je origin überhaupt heeft. De CrUX History-tool op corewebvitals.io toont de CrUX-historie voor elke site. Is mobiel daar leeg, dan is dat in Search Console net zo.

Zie ook: Core/Dash installeren, de browser-dimensie voor de bezoekers die CrUX weglaat, en de apparaattype-dimensie voor het splitsen van mobiel en desktop.

Bronnen: Search Console Help: rapport Core Web Vitals, CrUX-methodologie, Safari 26.2 voegt LCP en INP toe.