Core Web Vitals: not enough data in Search Console
Search Console says "Not enough usage data" when Google has too few Chrome visits to your pages. You can measure your real visitors without waiting for Google.
Trusted by market leaders · Client results
What "Not enough usage data" means
The Core Web Vitals report in Search Console shows how real Chrome users experienced your pages. Every time someone on Chrome with the right settings loads one of your pages, the LCP, INP and CLS of that visit gets sent to Google and ends up in a public dataset called the Chrome User Experience Report, CrUX for short. Search Console reads from that dataset and shows it to you. So contrary to what most people believe the Search Console does not measure your site by visiting it, it just collects real user data.
When there are not enough of those visits for your pages there is nothing to show. That is when you get "Not enough usage data in the last 90 days for this device type" for mobile or desktop, sometimes both.
Some people read that as a bad sign but no data says nothing about how fast or slow your site is. Google has not seen enough of your visitors to say anything about it.
Why CrUX has no data for your site
The main reason is traffic. CrUX only reports a page or an origin (protocol plus domain, so https://www.example.com) when it is "sufficiently popular". What that means exactly Google does not say, the methodology page only says the threshold is high enough to be confident in the distribution.
And only a small part of your visitors count towards that threshold to begin with. CrUX collects from people on Chrome who have usage statistics turned on, sync their browsing history and have no sync passphrase. That is Chrome on desktop and Chrome on Android. Chrome on the iPhone is not counted (it is WebKit underneath, same as Safari), and Safari itself, Firefox, Edge and the browser inside the Instagram app are not counted either. On a site with a lot of iPhone traffic most visitors never make it into the dataset. Mobile and desktop are also counted separately, so you can have data on desktop and no data on mobile, or the other way around. Whichever device has the least Chrome traffic goes empty first.
Then the page itself has to qualify. Anything that returns something other than a 200 after redirects is skipped. Pages with a noindex meta tag or an X-Robots-Tag: noindex header are skipped as well. Search Console adds a rule of its own on top of that, only URLs that are actually indexed show up in the report.
And if you only just added the property to Search Console it shows nothing for a while anyway, that one sorts itself out once Google has processed it.
Pages without data get the origin's score
Search Console also does not report on single pages, it groups URLs that look alike. When a group does not have enough data of its own Search Console falls back to the origin, meaning every URL on the same protocol, host and port. So a page CrUX has never seen can still show up as Good or Poor in your report because it borrows the number from the rest of your site.
In practice the homepage and the blog get most of the traffic, so they decide that origin number. Your product pages or your checkout can be much slower and you would never see it in Search Console. This is also why I never use the sitewide CrUX number as a target, it is weighted by traffic so your busiest pages decide it and those are not necessarily the pages you care about.
Lighthouse does not help here
The advice you find everywhere is to run PageSpeed Insights or Lighthouse until the CrUX data shows up. I understand why people say it but it does not get you what you need. A Lighthouse run loads your page one time on a simulated phone with a throttled connection and an empty cache. Fine for finding problems in the page itself, it says nothing about what your visitors get.
INP for example needs real people clicking and tapping on real devices, Lighthouse does not click on anything. For CLS Lighthouse stops looking once the page has loaded, so a late ad pushing the content down or something that jumps when the visitor scrolls never ends up in the report. And LCP depends on the phone, the connection and how far the visitor is from your CDN, a single test run has one of each.
Waiting only works if your traffic is growing. CrUX looks at the last 28 days of visits (the delay is a lot shorter than people think by the way, see why the 28 day delay is a myth). If you did not have enough qualifying Chrome visits this month you probably won't have them next month either.
Measure your own visitors with RUM
The alternative is to measure it yourself. Real user monitoring, RUM, runs a small script in the browser of every visitor, measures the Core Web Vitals of that visit and sends the numbers to you instead of to Google. Same kind of field data as CrUX, only now there is no threshold to reach and you are not limited to Chrome users.
A page with 50 visits a month has data. So do your iPhone visitors, Safari measures LCP and INP since Safari 26.2 (December 2025) so they show up in RUM while CrUX still leaves them out. You also see which element caused a bad number, the image that was the LCP, the button that was slow to respond. After a deploy you see the effect within minutes instead of somewhere in a 28 day average.
Core/Dash is the RUM tool I built for this. One script tag, or the WordPress plugin, and data starts coming in with the first pageview. It sets no cookies and collects no personal data so there is no consent banner needed. On a small site that matters, a RUM script behind a consent banner only measures the people who click accept and then you are back to a fraction of your visitors. Plans start at $16 a month billed annually and the 14 day trial needs no credit card.
Keep it running after CrUX picks up your site. Search Console only shows URL groups, it will never tell you which page or element made a group slow.
Check what CrUX has on you right now
Before you change anything, check if CrUX has your origin at all. The CrUX History tool on corewebvitals.io shows the CrUX history for any site. If mobile is empty there it will be empty in Search Console too.
See also: installing Core/Dash, the browser dimension for the visitors CrUX leaves out, and the device type dimension for splitting mobile and desktop.
Sources: Search Console Help: Core Web Vitals report, CrUX methodology, Safari 26.2 adds LCP and INP.
