More than half of all mobile websites are failing Google's performance standards right now. Not some of them. Not the ones on ancient servers running abandoned WordPress installations. More than half. And as of 8 April 2026, Google changed the rules so that those failures no longer stay contained to the pages where they happen.

The March 2026 core update finished rolling out two days ago ^[1]. The headline change that most business owners missed: Google now evaluates Core Web Vitals at the site level, not the page level. A handful of slow pages, a bloated contact form, an unoptimised image gallery, a WooCommerce checkout loaded with third-party scripts, can now suppress rankings across your entire domain. Even the pages that pass on their own.

What Site-Wide Scoring Actually Means

Until this update, Google assessed each page independently for its three Core Web Vitals metrics: Largest Contentful Paint (how quickly main content appears), Interaction to Next Paint (how responsive the page is to clicks and taps), and Cumulative Layout Shift (how much the layout jumps around while loading). If your homepage loaded fast but your blog archive crawled, that was the blog's problem. Your homepage kept its ranking benefit.

That is no longer how it works.

Google now aggregates performance data across your domain ^[2]. Your highest-traffic pages carry more weight, but poor performers anywhere on the site contribute to the overall assessment. According to early tracking data reported by SEOteric and corroborated by Ahrefs and Semrush monitoring, somewhere north of 55% of tracked sites registered measurable ranking shifts during the rollout ^[3]. Affected domains saw traffic declines in the region of 20% to 35%, with some losing considerably more on their worst-performing sections.

Under site-wide scoring, slow pages no longer fail in isolation. They pull down the whole domain.

The Numbers Behind the Failure Rate

The Chrome User Experience Report, which Google uses as its primary CWV data source, paints a stark picture. According to CrUX data reported through the Web Almanac, fewer than half of mobile websites currently pass all three Core Web Vitals metrics ^[4]. Desktop fares slightly better at roughly 57%, but mobile is where most business searches happen.

The bottleneck is LCP. Around 62% of mobile sites pass it on its own, while roughly 77% pass INP and 81% pass CLS. That single metric, how fast your main content becomes visible, is what drags the overall mobile pass rate below 50%.

For a Kilkenny craft brewery whose customers are searching on their phones during a Saturday market, failing LCP means the product page has not finished rendering before the visitor gives up. Google's own research indicates that sites meeting Core Web Vitals thresholds see abandonment rates drop by somewhere around 24% ^[5]. Flip that around: failing these thresholds means losing roughly a quarter more visitors before they even see what you sell.

Why Hosting Is Now the Deciding Factor

Here is where this gets operational. LCP, INP, and CLS are all heavily influenced by server response time, caching configuration, and how resources get delivered to the browser. In practical terms, that means your hosting stack.

A WordPress site on a properly configured managed environment, with Nginx, Redis object caching, and FastCGI page caching, will typically deliver sub-second server response times. The same site on a crowded shared server, competing with dozens of other sites for CPU and memory, routinely takes three to five seconds under any kind of load. That is not a marginal difference. That is the gap between passing and failing. And under site-wide scoring, it is the gap between your good pages ranking well and your good pages being pulled down by the slow ones.

One honest caveat: CWV scores reflect real-user data collected over 28 days, so a single bad afternoon on a shared server will not tank your scores overnight. But consistent underperformance will. And shared hosting delivers consistent underperformance by design, because you are sharing resources with every other site on that machine.

During our morning operations review this week, we looked at how sites on Web60's enterprise-grade Irish infrastructure performed through the rollout. Sites running on our WordOps stack, with Nginx, Redis, and FastCGI caching as standard, saw no measurable ranking disruption. That is what a properly optimised WordPress performance stack delivers when Google raises the bar.

If you are running a serious business site and want to understand exactly how each caching layer contributes to your Core Web Vitals scores, our complete WordPress performance guide breaks down the full picture.

The Concession Worth Making

If you run a simple five-page brochure site with no dynamic content, no eCommerce, and minimal JavaScript, shared hosting might still deliver acceptable CWV scores. A static site with lightweight pages does not need Redis or advanced caching to pass Google's thresholds. That is a fair assessment.

But the moment you add WooCommerce, a booking form, an image gallery, a live chat widget, or any plugin that loads external scripts, your hosting environment becomes the single biggest variable in whether Google penalises your entire domain or rewards it. Most business websites crossed that threshold a long time ago.

What Happens Next

Google does not typically reverse course on core update changes. Site-wide CWV scoring is the new baseline. The sites that were already running on optimised infrastructure absorbed this update without disruption. The sites that were not are watching their rankings slip across pages that performed well a fortnight ago.

The hosting choice that used to sit quietly in the background, something you set up once and forgot about, is now a direct input to how Google ranks every page on your domain. That is not a hosting consideration any more. That is a business visibility decision, and it needs to be treated as one.