Are Core Web Vitals really measured on users or bots?

Where do Core Web Vitals data really come from?

Core Web Vitals are not calculated during Googlebot's crawl. They rely on the Chrome UX Report (CrUX), a public dataset that aggregates performance metrics collected from real users browsing with Chrome.

This means that Google measures LCP, FID (which has become INP), and CLS directly in the browsers of your site's visitors. No simulation, no headless Chrome on the server side: these are ground-level, anonymized, and aggregated data over a rolling 28-day period.

Why does dynamic rendering change nothing for CWV?

Dynamic rendering involves serving a pre-rendered HTML version to bots and a classic JavaScript version to users. This technique improves the indexing of JavaScript content without penalizing user experience.

However, since CWV are measured on the client side, among actual visitors, the content served to Googlebot has no impact. If your site serves heavy JavaScript to users, your CWV scores will be poor even if the bot receives ultra-fast static HTML.

What is the difference between bot rendering and user experience?

Googlebot can crawl and index a site with an optimized server-side JavaScript rendering, making content discovery easier. But this optimized version is never what the end user sees.

The user downloads the HTML, executes the JavaScript, triggers network requests, and waits for the components to render. It's this experience that Chrome measures and reports in CrUX. Google doesn't cheat: it measures what your audience really experiences.

• Core Web Vitals come from the Chrome UX Report (real user data over 28 days)
• Dynamic rendering does not change CWV metrics since they are measured client-side
• Optimizing rendering for Googlebot improves indexing, not the performance perceived by visitors
• To improve CWV, you need to work on the real user experience, not the version served to bots
• CrUX data is public and accessible via PageSpeed Insights or the Search Console

Is this statement consistent with ground observations?

Yes, and it's actually reassuring. Across thousands of audits, it is observed that sites that cheat by serving ultra-optimized content to bots while providing bulky JavaScript to users have no advantage in CWV. PageSpeed Insights scores accurately reflect real user experience, not a server-side imagined version.

However, some clients still believe that optimizing rendering for Googlebot will magically improve their scores. This is a common misunderstanding between crawlability (what the bot sees) and user performance (what CrUX measures). This statement by Splitt cuts off this widespread misconception.

What nuances should be added to this claim?

CrUX does not cover all sites. To appear in the report, there must be a sufficient volume of Chrome traffic over 28 days. Low-traffic sites lack ground data, and Google then uses estimates or aggregated data by origin (whole domain rather than page by page). [To verify]: the exact traffic threshold required is not public, but it's estimated to require thousands of sessions per month.

Another point: Chrome users only represent a fraction of your total audience. If 40% of your visitors are on Safari or Firefox, their metrics do not show up in CrUX. This can create bias, especially on mobile where Safari dominates iOS. But Google only has access to Chrome data, so that's what it uses for ranking.

In what cases does this rule not apply?

If your site has no CrUX data (too low traffic, new site), Google cannot use Core Web Vitals as a ranking signal. In this case, CWV simply do not count in the algorithm — neither positively nor negatively.

Also, beware of Lighthouse lab tests (PageSpeed Insights in simulated mode). These tests do not necessarily reflect CrUX: they run in a controlled environment, without cache, and with calibrated connections. They provide optimization suggestions, but only ground data (CrUX) counts for ranking.

What concrete steps should be taken to optimize CWV?

The first step: measure real data. Check the Search Console (Core Web Vitals section) and PageSpeed Insights with the CrUX tab enabled. These ground data show what your users experience, not what a lab test simulates.

Then, focus on the real user experience: reduce JavaScript weight, optimize critical rendering, eliminate layout shifts. Dynamic rendering may assist with indexing, but it will never replace true client-side optimization. If you serve heavy content to visitors, your CWV will be poor, period.

What mistakes should be avoided in optimizing Core Web Vitals?

Don't waste time optimizing the bot version if your goal is to improve CWV. Serving ultra-fast static HTML to Googlebot while sending bulky JavaScript to users won't help at all. Google measures what the end user sees, not what the bot crawls.

Another classic mistake: relying solely on Lighthouse tests. These tests provide helpful recommendations, but only CrUX data counts for ranking. A perfect Lighthouse score with a catastrophic CrUX means your real users are suffering — and that’s what Google penalizes.

How can I verify that my site adheres to this logic?

Compare your CrUX data (Search Console, PageSpeed Insights) with your real analytics. If you see a huge gap between lab tests and ground data, it often indicates third-party resources (ads, tracking) that weigh heavily in production but are absent in testing environments.

Also, test on real connections: mid-range 4G, congested WiFi, old devices. Lab tests rarely simulate these conditions, but these are what your users experience — and what CrUX measures. If your site is smooth in lab tests but laggy in real-world conditions, your CWV scores will reflect that.

• Consult CrUX data in the Search Console and PageSpeed Insights (ground data over 28 days)
• Optimize the real user experience: JavaScript, critical rendering, layout shifts
• Do not confuse dynamic rendering (indexing) with CWV optimization (client performance)
• Compare Lighthouse tests (lab) with CrUX metrics (ground) to identify gaps
• Test on real connections (4G, old devices) to validate user experience
• Monitor third-party resources (ads, tracking) that may degrade CWV in production