Are Core Web Vitals really measured from Google bots or from your actual users?

Where exactly does the data for Core Web Vitals come from?

Core Web Vitals rely on the Chrome UX Report (CrUX), a public database that aggregates real performance metrics collected from Chrome users who have enabled syncing and usage statistics sharing. No Googlebot in the equation: we're talking about real browsers, real connections, real devices.

Specifically, every time a Chrome user loads your page, their browser measures the LCP (Largest Contentful Paint), FID (First Input Delay), or the INP (Interaction to Next Paint) that replaced it, as well as the CLS (Cumulative Layout Shift). These data are anonymized, aggregated by origin (domain), and then made available via CrUX with a delay of about 28 days.

It is this aggregated dataset that Google uses to assess the real user experience of your site as part of the Page Experience ranking signal. The bots do not measure any of this — they crawl, render HTML/JS if necessary, index, but generate no exploitable CWV metrics for ranking.

• Core Web Vitals are field metrics, not lab: they reflect the actual user experience, not a controlled environment.
• CrUX collects data only from Chrome desktop and mobile, with a globally representative but limited panel of users who have consented to share statistics.
• Google bots (Googlebot, Googlebot Smartphone) never contribute at any time to CrUX: their requests are excluded from any CWV measurement.
• The CrUX publication delay (28 days) means your technical optimizations will only reflect in scores a month later.
• CrUX data is public and accessible via BigQuery, the CrUX API, PageSpeed Insights, or the Search Console.

Is this statement consistent with what we observe on the ground?

Yes, and it’s actually one of the few points on which Google has always been clear and consistent. Since the launch of Core Web Vitals in 2020, all signals have aligned: CrUX = field data only. Field tests confirm that a site crawled by Googlebot but lacking real Chrome traffic will never have CWV data in the Search Console. Conversely, a site with Chrome traffic but blocked from crawling may very well appear in CrUX.

This consistency is reassuring, but it masks a blind spot: Google never specifies the minimum traffic threshold required for a site to appear in CrUX. Sites with low volumes of Chrome visitors — typically niche B2B sites, partially open intranets, or sites heavily using Firefox/Safari — may simply have no exploitable CWV data. In this case, Google resorts to origin data (entire domain) or, if nothing is available, likely ignores the CWV signal for those URLs.

Does dynamic rendering really skew Core Web Vitals?

No, it doesn't skew them — it dissociates them from what bots see, which is different. If you serve a server-side rendered (SSR) or statically prerendered version to Googlebot via dynamic rendering, but your real users receive a heavy JavaScript SPA with client-side hydration, it’s the performance of the JS version that counts for your CWV. Googlebot has no influence on these scores.

In practice, this can create a troubling gap: your bot version is fast, well indexed, but your real users suffer from poor LCP and chaotic CLS. The result? Perfect indexing, but ranking penalized by poor CWV. The opposite is rarer but possible: a slow bot version (for example, with unoptimized blocking JS) but a smooth client version due to aggressive lazy-loading — in this case, your CWV will be good even if the bot rendering is laborious. [To be verified]: Google has never published data correlating dynamic rendering and large-scale CWV impact, so all this remains anecdotal from real-world experience.

What are the limitations of this field-only approach?

The main issue is that CrUX is not exhaustive. Only Chrome users contribute, which excludes Safari (dominant on iOS), Firefox, non-Chromium Edge, and all niche browsers. If your audience is 60% Safari, your CWV only reflect 40% Chrome — potentially a bias if the two populations behave differently (e.g., mobile vs desktop, 4G vs fiber).

Another limitation: the 28-day delay makes any reactive optimization difficult. You fix a critical CLS bug today, you won’t see the effect in the Search Console for a month. In the meantime, your ranking may have suffered. Finally, sites with very low Chrome traffic simply have no URL-level CWV data, depriving them of a differentiation lever against better-resourced competitors.

Should we abandon dynamic rendering if we want good Core Web Vitals?

Not necessarily. Dynamic rendering remains a pragmatic solution for complex SPA architectures where migrating to SSR or Isomorphic Rendering would take months of development. But if you use it, acknowledge that your CWV will reflect the client version, so imperatively optimize that version: code-splitting, image lazy-loading, reducing blocking JavaScript, preloading critical resources, using Service Workers for caching.

The classic mistake is to only focus on the version served to bots thinking it will suffice for ranking. False. Bots do not vote for your CWV. It’s your Chrome users, on 3G mobile in suburban Paris or on fiber optic desktop in Bordeaux, who determine whether your LCP is below 2.5 seconds or beyond.

How can I check that my Core Web Vitals are accurately measured from real users?

Check the Search Console (Core Web Vitals section): if data appears, it means you have sufficient Chrome traffic to feed CrUX. You can also query the CrUX API or PageSpeed Insights in field data mode. If no data appears, either your Chrome traffic is too low or your site is too new (CrUX requires a minimum 28-day history).

To continuously monitor, deploy Google's web-vitals.js (open-source JavaScript library) that sends real metrics to your analytics system (Google Analytics 4, Matomo, or a custom endpoint). This allows you to cross your own field data with CrUX and detect regressions in real-time, without waiting for the monthly CrUX publication.

What concrete actions can I take to align bots and users on performance?

The ideal is to serve the same version to bots and users, eliminating any divergence. If you are using dynamic rendering, gradually migrate to SSR (Next.js, Nuxt, SvelteKit) or Static Site Generation (SSG) with partial hydration. If full-stack migration is out of budget, at least prioritize strategic pages (home, categories, top product sheets).

In the meantime, optimize the client version as if your ranking depended on it — because it does. Use a CDN to reduce latency, compress your assets (WebP, AVIF for images; Brotli for text), defer loading non-critical scripts, and eliminate layout shifts by reserving space for images/ads from the initial render.

• Check for CrUX data for your domain in PageSpeed Insights or Search Console.
• Deploy web-vitals.js to monitor CWV in real-time from the user perspective and catch regressions before CrUX publication.
• If you use dynamic rendering, audit the client version (the one that users receive) with Lighthouse and WebPageTest, not just the bot version.
• Prioritize mobile: CrUX mobile weighs more in ranking, and it’s often where scores are most degraded (slow networks, low CPUs).
• Plan a gradual migration to SSR or SSG if your current SPA architecture generates mediocre CWV despite optimizations.
• Document the gap between lab data (Lighthouse) and field data (CrUX) to explain to stakeholders why a good Lighthouse score doesn’t guarantee good ranking.