Do Core Web Vitals really affect your entire site or just your slow pages?

Does Google really evaluate page by page or site by site?

Google's statement attempts to clarify an ambiguity that has persisted since the launch of Core Web Vitals as a ranking signal. Technically, each URL receives an individual assessment based on its own performance metrics (LCP, INP, CLS). This is what Google measures via data from the Chrome User Experience Report.

But here's the catch: if a significant portion of your pages shows poor scores, Google considers that the site as a whole has a structural performance issue. It's not a straightforward mathematical calculation — it's a qualitative signal that reflects the overall technical quality of your platform. Google has not published the exact threshold that triggers this site-level devaluation, leaving SEOs in the dark.

Why does this nuance change the game for high-volume sites?

For a showcase site of 50 pages, the impact is limited — you can optimize each URL individually. But for an e-commerce site with 10,000 product listings or a media outlet that publishes daily, it's another story. You cannot technically guarantee perfect scores on 100% of the pages.

The pragmatic approach is to identify clusters of priority pages: those that generate organic traffic, those that convert, those that rank for strategic queries. If 20% of your pages capture 80% of the traffic (classic Pareto principle), focus your efforts there. But be careful — if 70% of your site is still red on PageSpeed Insights, you risk incurring a diffuse penalty that affects even your well-optimized pages.

What’s the difference between CrUX evaluation and ranking impact?

The Chrome User Experience Report collects real-user data on your pages actually visited by Chrome users. If a page has never been visited or does not reach the minimal data threshold, it simply does not appear in CrUX. Therefore, it is not strictly assessed for Core Web Vitals.

But Google also uses extrapolation mechanics: if the majority of your slow pages share the same technical structure (same template, same JavaScript stack), the algorithm can anticipate that the unmeasured pages likely exhibit the same weaknesses. This is where the evaluation shifts from a page level to a site level — not through an arithmetic average, but through a global technical quality inference.

• Core Web Vitals are measured page by page via CrUX data (real Chrome users)
• A significant volume of slow pages can lead to a domain-level devaluation, even if some isolated pages show good scores
• Google has never published the exact threshold (percentage of slow pages) that triggers this global penalty — it’s a deliberate gray area
• Pages without CrUX data (insufficient traffic) are not directly assessed, but can be extrapolated if they share technical characteristics with measured pages
• Tactical priority: optimize high traffic and high business value pages first, then gradually extend to secondary pages

Is this statement consistent with what we observe in the field?

Yes and no. On test sites that we monitor, it is indeed observed that the isolated optimization of a few landing pages is not enough to generate a visible boost if the rest of the site remains catastrophic. Google seems to have a global perception logic, even if it refuses to clearly admit it in its official communication.

But here's the nuance: on medium-sized sites (500-2000 pages), we have observed cases where 30-40% of red pages had no measurable impact on the rankings of well-optimized pages. The determining factor? These slow pages were either orphan pages (little or no internal linking) or pages with very low traffic volume. Google seems to weigh its site-wide evaluation based on the centrality of pages in your architecture.

What are the gray areas that Google does not clarify?

[To be verified] Google never specifies the threshold that shifts from a purely page-by-page evaluation to a global penalty. Is it 30% of slow pages? 50%? 70%? Total mystery. This opacity is likely intentional — it prevents SEOs from playing with the limit and gives Google a margin for algorithmic maneuvering.

[To be verified] Another unclear point: how does Google weigh the pages against each other? Does a slow page receiving 10,000 visits per month have the same weight as an orphan page visited 10 times? Logically no, but Google never explicitly states it. So we are working with reasonable hypotheses based on correlations, not certainties.

In what cases does this rule not really apply?

On high authority sites (national media, institutional sites, established brands), the impact of Core Web Vitals is clearly less decisive. We regularly see sites with catastrophic CrUX scores that maintain their positions — because other signals (backlinks, freshness, topical authority) compensate significantly.

Another case: queries with low competition or very specific intent. If you are the only one addressing a specific niche search intent, Google will rank you even if your Core Web Vitals are mediocre. The performance signal becomes discriminating only when multiple pages of equivalent quality are competing for the same SERP. It’s a tie-breaker, not an absolute filter.

How to audit the real impact of Core Web Vitals on your site?

The first step: extract CrUX data at the page level via the official API or tools like Screaming Frog + PageSpeed Insights. Identify the percentage of pages ranked as "Good" / "Needs Improvement" / "Poor" for each metric (LCP, INP, CLS). If more than 50% of your measured pages are red, you are probably in the risk zone.

Next, cross-reference this data with your organic traffic volumes. Use Google Search Console to identify pages that generate impressions and clicks. If your strategic pages (those capturing 80% of traffic) mostly show green or orange, you are relatively protected — even if the rest of the site is slow. But if your money pages are red, it’s an absolute priority.

What are the most common optimization mistakes?

Classic mistake: optimizing only the homepage and a few commercial landing pages while ignoring blog pages, secondary product listings, or category pages. If these pages represent 70% of your total volume, Google will consider your site has a structural problem — even if your 5 star pages are perfect.

Another trap: focusing on Lighthouse lab scores (simulated conditions) rather than on CrUX data (real users). Lighthouse might show 95/100, but if your actual visitors have a 3G connection or old devices, your real-world Core Web Vitals will be disastrous. Always prioritize field data in your diagnosis.

What progressive optimization strategy should be adopted?

Implement a prioritization matrix: traffic volume on the x-axis, current Core Web Vitals score on the y-axis. The pages at the top right (high traffic + poor score) are your priority 1. Address them first. Next, tackle pages with medium traffic but catastrophic scores — they can drag the entire site down.

For high-volume sites, consider template optimization rather than page-by-page. If 3000 product listings share the same HTML/CSS/JS structure, optimize the template once for all. This is the most effective approach in terms of ROI. But beware: if some pages have specificities (additional widgets, third-party content), they will require individual treatment.

These technical optimizations — especially at the scale of a complex site — require a high level of expertise and regular monitoring. Between CrUX audits, server bottleneck analyses, optimizing the critical rendering path, and post-deployment monitoring, internal resources are often insufficient. In this context, relying on a specialized SEO agency can drastically accelerate your results while avoiding costly missteps.

• Extract CrUX data at the page level (official API or tools like Screaming Frog + PSI) and identify the green/orange/red page ratio
• Cross-reference these scores with Google Search Console traffic data to prioritize high business impact pages
• Never rely solely on Lighthouse (lab) scores — always check field data (CrUX) reflecting the real user experience
• Implement a prioritization matrix (traffic × score) and first address high traffic + poor score pages
• For high-volume sites, optimize by template rather than page by page to maximize ROI
• Monitor CrUX scores monthly and adjust strategy based on traffic and performance variations