Half the Mobile Web Still Fails — But the Headline Lies a Little

Roughly half the mobile web is failing Google’s Core Web Vitals bar in 2026, and that gap is not shrinking as fast as the progress reports suggest. According to the HTTP Archive 2025 Web Almanac — drawing on CrUX field data from July 2025, spanning millions of real Chrome users — 48% of mobile sites now pass all three metrics. Up from 44% in 2024. Desktop sits at 56%.

That sounds like momentum. Here’s what it obscures: the 48% figure masks which metric is dragging the overall rate down. Break it out by metric and the picture sharpens fast.

LCP. That’s the culprit. CLS is the strongest metric at 81% — which is frankly impressive given how many ad-heavy and CMS-dependent sites exist. INP has stabilized at 77%. But LCP at 62% is what’s dragging the overall rate to 48%, because a site needs all three to pass. Fix your LCP and your overall pass rate follows. Ignore it and no amount of CLS precision matters.

The reason progress has slowed is structural, not technical. The easy wins — compress images, enable caching, switch to a CDN — have been harvested by most serious sites. What remains is harder: LCP images that PageSpeed scores green in lab conditions but fail at the 75th-percentile field threshold, INP failures buried inside tag stacks nobody has contractual power to remove, and CLS regressions introduced by ad networks that reload every 30 seconds. The tools to diagnose all of this exist and are genuinely excellent. The gap between teams that use them and teams that don’t has never been wider.

Why Your CrUX Score Is Misleading You

The single most common mistake is treating PageSpeed Insights lab data as the number Google ranks against. It isn’t. Full stop.

Google’s ranking signal uses field data from the Chrome User Experience Report — real Chrome users, throttled 4G conditions on mobile, assessed at the 75th percentile of all page loads in a 28-day rolling window. That means 25% of your visitors can experience terrible performance and you still pass. It also means 75% of visitors need a good experience to clear the threshold — not just most of them. The distinction matters more than most teams realize.

Here’s the diagnostic sequence that actually matters. Open PageSpeed Insights for your highest-traffic template — not your homepage, which is almost certainly your most-optimized page and the least representative of user experience at scale. A blog post template or product listing page is what actually serves your 75th-percentile user. Focus on the Field Data box at the top, not the “Diagnose performance issues” section below it.

This creates an attribution gap that trips up even experienced teams. You can run a Lighthouse audit, see nothing alarming, and still have 30% of your mobile users experiencing 400ms+ interaction delays on every tap. The fix requires a Real User Monitoring (RUM) tool — DebugBear, SpeedCurve, RUMvision, or the open-source web-vitals JavaScript library — collecting actual interaction data from real visitors. Without RUM, you’re navigating INP with the lights off.

One more thing CrUX doesn’t tell you: the 2025 Web Almanac shows that among the top 1,000 websites, only 51% of mobile sites pass all three CWV — lower than the 48% overall average. The biggest and most trafficked sites are actually performing below average on mobile. If your site is growing in popularity, your CrUX score may decline even if you haven’t changed anything — because your audience is getting larger and more diverse across device types and connection speeds.

LCP: The Fix Nobody Is Actually Implementing

Per the Chrome team’s analysis of real-user data, 73% of mobile pages have an image as their LCP element. Among those with poor LCP, the image resource load is delayed by 1,290 milliseconds at the 75th percentile. Here’s the thing that surprises most developers when they first see this number: that delay is almost never caused by image file size. It’s caused by the image URL being undiscoverable in the initial HTML.

When the browser parses your HTML and can’t find an <img src=""> — because your image is lazy-loaded via JavaScript, or tucked behind a data-src attribute waiting for a scroll event — it can’t start fetching it. It has to wait for JavaScript to execute, inject the element, and only then begins the download. By then, your LCP window is already half gone.

The two highest-impact LCP fixes (in order)

1. Add fetchpriority="high" to your LCP image element. This tells the browser to give that image maximum bandwidth priority during the critical loading window. Single attribute. On a static or server-rendered site it takes minutes to add. The Chrome team documented a Google Flights test where this change alone improved LCP from 2.6s to 1.9s. And yet — per the same Web Almanac data — 85% of eligible pages still aren’t using it. If your LCP image is already in the initial HTML (no JavaScript injection), this is your fastest win.
2. Cache your HTML at the CDN edge. Chrome team data shows only 33% of HTML document requests are served from a CDN. Two-thirds of sites are sending users to origin servers on every page load, paying 200–800ms in Time to First Byte before any content begins loading. For dynamic sites (WordPress with plugins, personalization layers, Shopify with dynamic pricing), edge HTML caching requires thoughtful cache-key design — but the LCP payoff is often larger than any image optimization effort. This is the fix people reach for last because it feels complicated. Do it first.

INP: When the Problem Isn’t Your Code

INP replaced First Input Delay as a Core Web Vital in March 2024. The 2025 Web Almanac confirms the resulting landscape: 77% of mobile sites now pass INP — but that hides a meaningful desktop/mobile split. Desktop INP sits at 97%. Mobile at 77%. The responsiveness gap between device types grows wider on JavaScript-heavy pages because mobile CPUs have less headroom to process long tasks before an interaction handler fires.

What causes poor INP? Specifically: INP breaks into three phases — input delay (background tasks blocking the main thread when the user acts), processing time (your event handler doing work), and presentation delay (the browser painting the result). Most sites with poor INP are failing on input delay, not processing time. The culprit is almost always third-party scripts. Not your code. Theirs.

The Long Animation Frames API (LoAF) — shipped in Chrome 123 in January 2024 — changes the diagnostic picture completely. Where the older Long Tasks API could tell you that something was blocking the main thread, LoAF tells you which script caused a specific frame to miss its render deadline, and links that frame to the exact INP interaction. It’s the difference between “your page is slow” and “your live chat widget is stealing 340ms from every tap.”

Taboola documented using LoAF during its origin trial to attribute INP delays to specific rendering tasks, ultimately improving INP by up to 36% for publisher partner sites. The war story the implementation blog posts leave out: LoAF gave Taboola a precise diagnosis — but not every problem LoAF surfaces is solvable with code. Some are contractual. The live chat SDK that’s causing 280ms of input delay is maintained by a vendor you’re paying $3,000/month for. You can’t rewrite it. You can’t remove it without a business conversation.

INP is not a problem you solve with a faster event handler. It’s a problem you solve by knowing which of your 40 loaded scripts is stealing 300ms from your users’ taps — and then having the organizational authority to do something about it. The sites that solve hard INP first won’t do it by being better developers. They’ll do it by building governance processes that treat third-party script approvals the same way security teams treat dependency audits.

The Speculation Rules Problem Your Competitors Don’t Know They Have

Here’s something nobody is saying directly: your competitors’ CWV scores may be improving this year without their developers doing anything. Not because of some mysterious algorithm change. Because two major platforms shipped Speculation Rules support to their entire install bases, and those LCP improvements are landing in CrUX right now.

Shopify deployed the Speculation Rules API platform-wide in June 2025, documenting — via A/B test on real visitor traffic, not synthetic lab data — an average 130ms improvement on desktop and 180ms improvement on mobile across all loading metrics in supported browser sessions. WordPress shipped native speculative loading in version 6.8 (released March 2025), enabling prefetch with conservative eagerness by default on all sites with pretty permalinks enabled.

How it works: the Speculation Rules API instructs the browser to prefetch or fully prerender likely next-page URLs before the user clicks. Conservative eagerness — the WordPress and Shopify default — fires on mousedown or touchstart, typically 50–200ms before the navigation event. That’s enough to serve the first byte of the next page from cache rather than from origin, compressing Time to First Byte to near zero on warm navigations. For CrUX purposes, these navigations show up as navigate_cache or prerender in page navigation types, and they improve the 75th-percentile LCP figures that Google reports.

The implication for sites not on those platforms: competing sites are receiving passive improvements on same-origin navigations. If your stack hasn’t implemented Speculation Rules, your competitors’ field scores are drifting upward while yours stay static. Shopify has been live since June 2025. WordPress 6.8 since March 2025. The CrUX window collecting that improvement data has been running for months.

One genuine failure case the platform announcements gloss over: prerendering executes all page scripts, including analytics. A speculated page the user never visits still fires a pageview event in Google Analytics. Shopify’s engineering blog explicitly acknowledged this complication — it couldn’t draw conclusive business impact numbers because it couldn’t isolate conversion rate changes from the performance improvement, partly due to analytics interference. If you implement prerender without configuring your analytics to handle activation events correctly, you’ll see inflated pageview counts and unreliable conversion attribution before you ever see the LCP improvement in CrUX.

CLS: The Problem That Keeps Sneaking Back

CLS is the strongest individual metric at 81% mobile pass rate. It’s also the only Core Web Vital that’s harder to pass on desktop than on mobile — an observation DebugBear documented in its CrUX analysis — because desktop pages carry more ad slots, richer embeds, and heavier JavaScript that injects layout-affecting content asynchronously. Mobile viewports are narrower, which actually constrains layout shift ranges.

The CLS problems that are genuinely hard to fix in 2026 are not unset image dimensions or missing aspect-ratio declarations — those are solvable in an afternoon. The hard problems are: late-loading ad slots that shift page content after the above-the-fold render, consent management platforms that inject banners and push content down on first load, and font-swap layout shifts where the web font and fallback font have materially different metrics.

For ad-heavy sites, the most reliable CLS fix is reserving explicit height for every ad slot in your layout, even before the ad loads — not a min-height that the ad can overflow, but a fixed container sized to the largest expected creative. Sounds obvious. Look at your page in a slow-connection profile with ad blockers off and count how many slots shift. For consent banners: the only layout-stable option is a fixed-position overlay that doesn’t shift document flow. If your CMP vendor’s default implementation pushes content down, that’s a configuration problem, not a limitation of the web.

Platform Reality: WordPress 6.8 Passes CWV at 45% on Mobile

One data point from the 2025 Web Almanac that deserves more attention than it’s getting: WordPress sits at 45% mobile CWV pass rate — among the lowest of any major CMS, despite being the platform that just shipped Speculation Rules in version 6.8. Wix, by contrast, jumped from 55% to 74% year-over-year. Duda leads at 85%.

Table: Mobile CWV pass rates by major CMS platform, 2024 vs. 2025 (HTTP Archive, July 2025 CrUX)

What this table shows isn’t a ranking of “good” vs. “bad” platforms. It shows the structural effect of customization latitude. WordPress’s 45% pass rate isn’t a platform failure — it’s the cost of infinite extensibility. Every Elementor slider, every heavyweight page builder, every third-party theme running 400KB of unoptimized JavaScript drags the aggregate down. Duda’s 85% reflects a tightly controlled environment where the platform, not the user, owns the rendering stack. Wix’s 19-point jump shows what happens when a platform invests heavily in infrastructure-level optimizations that propagate to every site simultaneously.

The Forward Picture: What’s About to Get Harder

Two cross-source patterns in the 2025 data will shape the next 12 months of competitive performance dynamics.

The first: platform-level CWV improvements are compounding in ways that benefit some sites and leave others behind. As WordPress 6.8, Shopify, and Cloudflare extend Speculation Rules and image optimization defaults to their entire install bases, the aggregate mobile pass rate will continue climbing — but the gains will accrue disproportionately to sites on supported platforms. Sites on custom stacks, older CMSes, or JavaScript-heavy SPAs — which Speculation Rules doesn’t help at all, since the API targets multi-page applications — will see the competitive gap widen without writing a single line of bad code. Passive improvement is becoming a competitive advantage.

The second: INP is becoming the new long-tail problem. LCP and CLS solutions are well-documented and largely within developer control. INP solutions for sites with complex third-party tag stacks are often not. As the 23% of mobile sites still failing INP attempt remediation, a significant fraction will discover — as Taboola did — that LoAF surfaces a contract problem, not a code problem. A live chat widget, consent manager, or ad SDK they cannot remove or rewrite without renegotiating a vendor relationship. The teams that solve hard INP failures first won’t do it by being better engineers. They’ll do it by building governance processes: marketing and product teams owning tag hygiene decisions, with developers holding veto power on scripts that breach an agreed INP budget.

For developers specifically: the 28-day CrUX aggregation window means a fix deployed today won’t fully reflect in Google Search Console’s Core Web Vitals report — or in ranking signals — until approximately four weeks later. If you’re planning a CMS upgrade, a Speculation Rules rollout, or a CDN migration, that deployment clock is longer than most sprint timelines account for. The time between “we shipped the fix” and “we see it in CrUX” is a month, minimum. Plan interventions accordingly — and manage stakeholder expectations for that lag explicitly.

The sites that pull ahead in the next year won’t be the ones that read the most blog posts about Core Web Vitals. They’ll be the ones that treat performance as a governance problem, not a developer problem — and start owning the organizational decisions that determine whether third-party scripts get added to production in the first place.