Core Web Vitals "Not Enough Usage Data": Meaning and Fix

What does Core Web Vitals not enough usage data mean?

Core Web Vitals not enough usage data means Search Console could not find enough real Chrome user measurements to build a meaningful summary for your pages. However, it does not mean your site is broken. Usually the site is new, traffic is low, or the selected URL group falls below the sample threshold.

The message you see is a similar notice in Google's interface (the English label is Not enough usage data). Menus and wording change over time, so we do not rely on exact button names. Check the current wording on the Search Console Help page for the Core Web Vitals report.

This article covers only this one situation. For the definition of the metrics, read our guide on what Core Web Vitals are. So we will not repeat it here.

In short, this guide is for anyone who opened the report, saw an empty state, and wants to know what to do next. We explain what the message means first, and then the path to follow. Our answers rely on Google's official documentation, and we do not invent numbers where the documentation gives none.

What should you check in the first 15 minutes?

Still, there is no need to panic. In most cases this message is a sign of missing data, not a fault. Work through these steps in order:

1. Confirm you picked the right property. A domain property and a URL prefix property can show different scopes.
2. Open the mobile and desktop tabs separately. One may show data while the other stays empty.
3. Check whether the site is new, and look at the number of visits over recent months in Analytics.
4. Test your home page and one important inner page in PageSpeed Insights. Then see whether the field data section appears.
5. Confirm the pages are public, need no login, and are not blocked with noindex.
6. Assume the data will not arrive soon, and plan lab testing and real user measurement in the meantime.

These six steps clarify the cause in most cases. After that, you can decide which path to take.

We suggest writing each step down as a short note. For example, record which property, which tab, and which page you checked. Then, when you reopen the report in a few weeks, you can see what changed at once.

If several people share the work, assign an owner to each step. That way the developer, the content owner, and the manager all move with the same information.

Where does the Core Web Vitals report get its data?

The report takes its data from the Chrome User Experience Report, known as CrUX. CrUX collects anonymous performance measurements from real Chrome users who have certain browser options turned on. Google calls this field data.

In other words, Google does not visit your site with a robot and give it a grade. It gathers the loading, interaction, and layout shift experience that real people have on their phones and computers. So if there are no visitors, there is no data.

First, you do not need to sign up or add code to appear in CrUX. However, the Chrome UX Report documentation says clearly that not every site and not every page is in the dataset. A page must be publicly discoverable, and it needs enough visitors to form a statistically meaningful sample.

The real question behind the message is therefore simple. Did enough real Chrome visitors browse these pages? We do not print the exact threshold here. Check the current value in the Chrome UX Report documentation.

One more detail matters. CrUX data builds up over time. A change you make today does not show up in full tomorrow. So read the results as a weekly trend, not as a daily number.

When does this message appear?

For example, the typical causes fall into a few groups. Finding yours helps you choose the right next step.

• You added the property recently, and not enough visits have come in yet.
• You launched the site recently or moved it to a new domain.
• Traffic is truly low, which is common for B2B and local sites.
• Most visitors use a browser other than Chrome.
• The pages sit behind a login wall and are not public.
• The selected device type, such as desktop, has very few visitors.

These causes can also appear together. For example, a new local business site may have low traffic and mostly mobile visitors. The desktop tab then stays empty for a long time.

This is normal, and therefore no reason to worry. Also, it does not point to a penalty or a technical fault by itself.

The most practical way to find the cause is to open Analytics and read three things together: recent sessions, device split, and browser split. Read side by side, these tables usually show which group you belong to. Then your to-do list gets much shorter.

Does Core Web Vitals not enough usage data hurt rankings?

No. The message itself does not lower your rankings. It describes a measurement gap, not a penalty. Likewise, missing data does not mean your page is poor.

Page experience is only one of many signals Google uses. Content relevance and quality, however, are often far more decisive. For that reason, we never present speed work as a ranking guarantee.

On the other hand, user experience affects conversions directly. A page that opens late or jumps around loses visitors. So missing data is no excuse to ignore performance.

For the broader link between speed and search, see our article on how site speed affects SEO. Here we focus only on reading the data gap correctly.

We avoid exaggerated promises on this topic. Speed work can make a measurable difference in some cases, and in others it does not. We recommend doing what helps users, without promising an outcome.

So the right question is not whether your rankings will fall. It is whether your visitor has a good experience on the page. If you cannot answer the first question, start by measuring the second.

What is the difference between a URL group and the origin level?

First, Search Console groups pages with a similar user experience into URL groups. If a group lacks enough data, the report leaves it out. In that case Search Console can build a higher level origin group, which covers the URLs that share the same protocol and host.

PageSpeed Insights follows a similar logic. When a specific page has no data, it falls back to the origin level. If the origin also lacks enough data, the tool shows no field data at all, and Google's documentation states this plainly.

As a result, the practical takeaway is this. Not seeing data for one page, for example, does not mean the whole site has none. Your home page may show origin level data while a new blog post shows nothing.

Here is an example scenario. Suppose your shop has hundreds of product pages and each gets very few visits. No single page passes the threshold, yet together they can produce enough samples at the origin level. This is why the report sometimes shows only the origin level.

Keep in mind, however, that the origin level is an average picture. A single very slow page can get lost in that average. To find the problem page, you also need lab testing.

Why is there no field data in PageSpeed Insights?

First, PageSpeed Insights offers two kinds of data. One is field data from real Chrome users, and the second is lab data from a simulated page load. When the field section is empty, the lab section still works.

In particular, Google's PageSpeed Insights documentation says a page needs enough data to enter the CrUX dataset before the tool can show user experience data for it. If the page is brand new or has few real user samples, no field data appears.

As a result, this leaves two possibilities. Either the page has no data and the tool falls back to the origin level, or the origin has none either and the field section disappears completely.

When you see this screen, do not assume the tool is broken. Reloading it or trying another address will not change the result. Only more visitors will. So you need to build your measurement in another way.

Also check how you typed the address. If you test a URL that redirects, and the final page is different, the result may differ from what you expect. Whenever possible, test the final address after the redirect.

How do lab data and field data differ?

Put simply, lab data comes from a controlled environment with one device and a fixed network condition. Field data reflects the experience of real visitors on many devices, networks, and locations. The two can give different results, and that is normal.

Google's web.dev explains that lab data is useful for debugging and field data is useful for seeing the real experience. However, they do not replace each other. You use them together.

Lighthouse belongs on the lab side. For its details, read our article on testing performance with Lighthouse. We do not repeat it here.

This difference also explains why you should not panic when field data is missing. Lab testing helps you find problems early. When field data arrives, it confirms how much those problems affect real users.

How do you measure performance without field data?

Without field data, you therefore have three paths. They complement each other, and none is enough alone.

• Lab testing: Use Lighthouse or the lab section of PageSpeed Insights to find problem elements.
• Real user monitoring (RUM): Collect performance measurements from your own visitors on your own site.
• Manual review: Browse your site yourself on a real phone and a slow connection.

Lab testing is steady and repeatable, so it is valuable for comparing changes. However, it does not carry the variety of real users. A good lab score does not guarantee a good field result.

For that reason, we treat lab results as a first check. When you decide, the most reliable evidence is still the real user. If you do not have it, you start your own measurement.

Finally, do not underestimate manual review. Opening your site on a real phone, on a slow connection, and trying to fill in a form reveals friction that a test tool will not catch. For example, you will notice at once if a button jumps while the page loads.

What is real user monitoring and how do you start?

RUM means collecting the loading, interaction, and layout shift values that your visitors experience, from your own site. It is similar to what Chrome collects in CrUX. But it is under your control, and you can see it page by page even when the volume is small.

In practice, there are usually two ways to start. The first is to use the web-vitals library described on Google's web.dev and send the measurements to your own analytics tool. The second is to use a ready monitoring service that does this for you.

We do not give code details in this article, however. Your developer can follow the official documentation. What matters is that you summarize the values at the 75th percentile and track mobile and desktop separately.

However, RUM also needs traffic. If you have very few visitors, the values will swing. So watch the trend for several weeks, and do not decide from a single day.

Also, mind privacy. Do not collect personal data while measuring; performance values carry no personal identity. Before you set up a measurement service, check whether your cookie and privacy notices fit. This is not legal advice, so ask a specialist if needed.

Which diagnoses cannot explain this message?

Many people, unfortunately, look in the wrong place when they see the message. The problems below are not directly tied to missing data.

• Sitemap errors: A sitemap problem affects discovery, not the creation of field data.
• A robots.txt block: Look at crawling problems as a separate topic.
• One slow page: Slowness creates bad data, not a lack of data.
• A hosting change: It does not cause data loss by itself, but it can matter if traffic dropped.

Of course, your site may also have a real indexing or access problem. To tell the difference, read our guide on how to find unindexed pages in Search Console.

If you see a sitemap error, our article on the sitemap URL not allowed error covers that case as a separate topic. Above all, do not confuse the two problems.

In short, reading a data gap as a symptom of another problem wastes time. First understand the logic of the message. Then, if you truly suspect another problem, look at it separately.

What should a new or low traffic site do?

If your site is new, you first need patience and then a routine. In the first days after adding a property, an empty report is expected. We cover that case in our article on Search Console showing no data.

However, a low traffic site needs a different approach. Instead of adding pages or inventing visitors, focus on these three things:

1. Keep basic performance solid with lab testing. Compress images and reduce unneeded scripts.
2. Invest in content and channels that bring real visitor flow.
3. Wait patiently for origin level data, and check again after a few weeks.

For example, image optimization and script weight do affect page speed. For details, read our article on how JavaScript affects site speed.

On a low traffic site, content work and speed work are not rivals. They go together. A fast site with no visitors is as inefficient as a site that attracts visitors but opens slowly.

Why are mobile and desktop read separately?

Also, the Search Console report shows mobile and desktop data apart. The reason is that network, processor, and screen conditions differ between the two device types, and Google treats these as two separate experiences.

If most of your visitors use mobile, the desktop tab may stay empty for a long time. Still, that is not a problem. What matters is whether there is data for the device type most of your visitors use.

Look at the device split in Analytics. If not even one in ten visitors comes from desktop, an empty desktop tab is no surprise. On such sites, we first strengthen the mobile experience.

Remember that the same page can be good on mobile and poor on desktop. So read the two tabs separately, and never use one in place of the other.

Your visitor split decides which device to prioritize. If your visitors come from desktop during work hours, as on a B2B site, the desktop tab may matter more to you.

Is it right to send artificial traffic to collect data?

No. Bot traffic, purchased visitors, or repeated visits you make yourself turn into an attempt to mislead systems, and they do not work anyway. CrUX measures only real Chrome users who meet its conditions.

Moreover, artificial traffic also corrupts your analytics data and can cause trouble in an ad account. Do not try to fill a report with methods that break the rules.

On the other hand, the legitimate paths are clear. Create content, use your email list and social channels, and run ads to attract real visitors if needed. If you run ads, our UTM builder helps you tag campaign links correctly.

Until data arrives, therefore, the safest path is lab testing plus RUM.

The honest way is slower, but it is solid. Real visitor growth also means real conversions, and the report fills up as a side effect.

How do you read the report once data arrives?

When the report starts to show data, it groups pages into statuses such as poor, needs improvement, and good. The thresholds are in Google's documentation. For example, it lists 2.5 seconds for LCP, 200 milliseconds for INP, and 0.1 for CLS as the good limits.

Thresholds can change, therefore verify them again on the Search Console Help page for the Core Web Vitals report. We do not treat these values as fixed.

When you read the report, open the problem URL groups first. Next, test one sample address from that group in PageSpeed Insights, and read the lab tips.

After a fix, however, allow some waiting time. Field data builds up with real visitors over a time window, so do not expect instant results.

Also, track the same group for several weeks after an improvement. If it does not improve at once, do not assume you did something wrong. Field data works with a window that looks back in time.

Which tool shows what?

Different tools answer different questions. The table below sums up what each tool does when data is missing.

In short, the takeaway is this. On a site with no field data, lab testing and RUM work together. You need to plan both.

Which pages should you test first?

Because you have no field data, you therefore do not need to test the whole site with the same care. Choose the pages with the most business value first, since that is where limited time makes the biggest difference.

• Home page: Most visitors enter here.
• Service or product category pages: Conversion starts on these pages.
• Blog posts with the most organic traffic: Search visitors meet these first.
• The contact or quote form page: A delay here causes direct loss.
• One sample page per template: Pages that share a template give similar results.

Also, the template logic saves time. If a hundred posts share one template, testing one or two of them usually gives a good idea.

Run the test for mobile, since most visitors usually come from phones. Write the results in a table and compare again after each change.

Can Core Web Vitals not enough usage data stay for good?

Yes, on some sites this message can stay for a long time. Very niche sites, sites with very few visitors, or sites that serve mostly non Chrome users may never reach the threshold.

Put simply, this is not a flaw. You only need to change the habit of deciding from field data alone. On such a site, lab testing and your own RUM become your main sources.

You also do not have to wait for the report to fill in order to improve user experience on a small site. Image sizes, font loading, third party scripts, and page layout are well known good practices anyway.

In short, the general rule is this. When there is no measurement, replace guesses with an evidence based method, and run that method on a schedule.

What are the most common mistakes?

These are the mistakes we see most often in teams facing this situation.

• Treating the message as a penalty and changing the site in a hurry.
• Presenting a lab score as if it were a field result.
• Spreading one page's data across the whole site.
• Mixing up the mobile and desktop tabs.
• Trying to send artificial traffic to get data.
• Writing menu names and thresholds from memory instead of checking the current documentation.

Most of these, in fact, come from impatience. The right reflex is to find the cause first and then build a measurement plan.

To be honest, we do not promise a ranking effect from performance work. What we do is make the user experience measurable and improve it.

What order do we follow as a team?

When a site comes to us with this situation, our team usually follows this order. This is an example scenario, and it carries no guarantee.

1. First, we check the property and the device tabs.
2. Then we read the traffic volume and the device split in Analytics.
3. Next, we measure the home page and a few critical templates with lab testing.
4. After that, we decide whether to set up real user measurement.
5. Finally, we recheck the report at regular intervals until data builds up.

In addition, this work is usually part of a technical SEO effort. If you would like to review the overall technical health of your site with us, see our SEO consulting service.

For a quick first look, our SEO checker is handy. However, it cannot replace field data.

What is the bottom line when there is no data?

In short, this message is a data threshold issue, not an error. It does not lower your rankings directly. But it does not change the fact that you need to measure performance.

First separate the cause: a new site, low traffic, a device type, or an access problem. Then close the gap with lab testing and real user measurement. When data arrives, read the report again.

Above all, Google's official documentation is the most reliable source. Menu names and thresholds can change, so always check the current page.