Here’s the number that should bother you more than it probably does: as of the May 2026 Chrome UX Report, only 55.9% of measured origins pass all three Core Web Vitals at once. Not 55.9% of small, neglected sites — 55.9% of everything Google tracks, across 18.4 million origins. Flip that around and it means that roughly 2 in 5 websites on the entire internet are currently failing a ranking signal that’s been public, documented, and free to test since 2021.

That statistic is the whole article in miniature. It’s not that people don’t know page speed matters — every marketing team on earth has seen the slide with the bouncing-stick-figure-loses-patience graphic. It’s that almost everyone is optimizing the wrong layer, fixing the metric that’s easiest to move instead of the one that’s actually broken, and trusting a lab score that has nothing to do with what their real visitors experience.

I’m going to walk through this the way I wish someone had walked it through for me: not metric-by-metric in the order Google introduced them, but tax-by-tax, in the order your users actually pay them. Along the way there’s a framework I haven’t seen written up anywhere else, three small calculators you can run on your own numbers, one mistake I made that cost a client a week of engineering time for zero LCP improvement, and an opinion about Lighthouse scores that will annoy some of you.

Section 1 — The core problemWhy your dashboard is lying to you (politely)

Picture two version of the same product page. One was tested five minutes ago in Lighthouse on a fiber connection with an empty cache, and it scored a 98. The other is what 75% of your actual mobile visitors experienced last month, on mid-tier Android phones, over patchy 4G, with three tracking scripts and a chat widget fighting for the main thread. Those two pages can report wildly different numbers — and only one of them is what Google uses to rank you, and only one of them is what your customer actually lived through.

I call the distance between those two numbers the Honesty Gap. It isn’t a Google term — I haven’t seen it named anywhere else, but once you start measuring it, you’ll see it everywhere. Lighthouse, PageSpeed Insights’ “lab data” tab, and your local dev machine all produce synthetic results: a single simulated page load under controlled, usually favorable, conditions. The Chrome UX Report (CrUX) — the dataset that actually determines whether you pass or fail Core Web Vitals — is field data: real measurements from real Chrome users who opted in, aggregated at the 75th percentile over a rolling 28-day window.

Here’s why the gap exists, and it’s not really Lighthouse’s fault: a lab run can’t simulate the thing that breaks most real pages, which is contention. Your test run doesn’t have a half-loaded ad network competing for bandwidth, a returning visitor’s stale service worker serving outdated assets, or a user on a three-year-old Android phone with four other tabs open. Google’s own LCP documentation is explicit that field data is what counts for ranking — lab tools exist for debugging, not grading.

The practical move: stop treating your Lighthouse score as a report card and start treating it as a hypothesis. Every time you ship a performance fix, check it against your Search Console Core Web Vitals report four to six weeks later — that’s roughly how long it takes the rolling CrUX window to fully reflect a change, since Google blends a 28-day rolling average. If your lab score jumped but your field p75 didn’t move, you optimized the test, not the experience.

Section 2 — The math nobody explainsWhat “75th percentile” actually means for your site

This is the part most explainers skip, and it’s the part that explains why a site that “feels fast” in your own browsing can still fail. Core Web Vitals don’t use an average. They use the 75th percentile — meaning 75% of your real visits have to individually clear the good threshold for the page to pass. Not the median visit. Not “most” visits in a loose sense. Three out of every four, measured separately for each metric, every rolling 28 days.

Try this with ten imaginary LCP measurements from one page, sorted low to high, in seconds: 1.1, 1.3, 1.4, 1.6, 1.8, 1.9, 2.1, 2.4, 3.1, 4.8. The average is a perfectly respectable 2.15 seconds — looks like a pass. But the 75th percentile (the value at the 7.5th position, which Google’s methodology effectively rounds to the higher of the two middle-ranking candidates) lands around 2.4 to 2.5 seconds — right on the edge, and one bad CDN day from failing. That one outlier at 4.8 seconds barely moves the average, but it’s exactly the kind of long tail that p75 is designed to punish: the slow connections, the low-end devices, the visitors furthest from your server. Google’s own research on how these thresholds were defined explains the choice directly — p75 captures “the experience of most users” without letting a handful of extreme outliers fail an otherwise-good page, while still being strict enough that you can’t hide a real problem behind a fast median.

And critically: all three metrics have to pass simultaneously for the page-level “Good” rating. Flawless CLS and INP with a borderline LCP still fails the overall assessment. This is exactly why a site with a “B+” on every metric can read as an outright failure in Search Console — the dashboard isn’t grading on a curve.

Section 3 — State of the web, 2026The numbers that put your site in context

A few honest caveats before you screenshot that chart and panic or celebrate. First, these are origin-level numbers blended across desktop and mobile — and the device split matters enormously. Separate 2026 analyses focused on mobile-only traffic put the INP failure rate closer to 43% of sites, since mobile CPUs choke on long JavaScript tasks in a way desktop machines rarely do. CoreWebVitals.io’s INP guide and independent agency audits converge on roughly the same figure from different datasets, which is the kind of agreement across independent sources I actually trust more than any single precise decimal.

Second, LCP remains the laggard of the three by a wide margin, and that’s structural, not incidental. CLS is “fix once, mostly stays fixed” — set explicit dimensions on your images and ad slots and you’re most of the way there. INP has improved sharply since 2024 as developers adapted their JavaScript. LCP, by contrast, depends on hosting, network distance, rendering architecture, and image pipeline all compounding on top of each other — which is exactly why it gets its own framework in the next section.

“For at least half of the origins with poor LCP, the p75 TTFB alone — over 2.2 seconds — nearly guarantees the page can’t hit the 2.5 second threshold, no matter what happens afterward.”— paraphrased from web.dev’s “Common misconceptions about how to optimize LCP,” 2024

Section 4 — An original frameworkThe Four Taxes: a better way to diagnose a slow LCP

Google’s own breakdown splits LCP into four technical sub-parts — Time to First Byte, Resource Load Delay, Resource Load Duration, and Element Render Delay — and that’s the correct engineering decomposition. But I’ve sat in enough stakeholder meetings to know that “Resource Load Delay” doesn’t tell a product manager who owns the fix or why it’s worth their sprint. So here’s the reframe I actually use, which maps the same four sub-parts onto who’s responsible and how hard the fix is.

The Physics Tax

This is the tax you owe before your code has done anything at all — the time it takes for a request to physically leave the browser, reach your server (or its nearest edge node), and return the first byte. A good TTFB target is under 600 milliseconds; HTTP Archive’s 2024 performance chapter found that just 42% of mobile websites hit a “good” TTFB rating, with another 40% in the “needs improvement” band. If you’re self-hosting on a single regional server and your customers are continents away, you are paying this tax on every single visit regardless of how well-optimized your front-end code is. An edge CDN with cached HTML, HTTP/2 or HTTP/3 multiplexing, and removing unnecessary redirect chains are the standard fixes — none of them touch a line of your application code, which is exactly why this tax gets ignored by front-end teams and exactly why it’s often the highest-leverage fix available.

The Discovery Tax

This one is almost entirely self-inflicted, and it’s the single most common mistake I see on otherwise well-built sites. The browser has a “preload scanner” that races ahead of the main parser, scanning raw HTML for resources to start fetching immediately — before CSS, before JavaScript, before layout. If your LCP image’s URL is sitting in plain src attribute in the HTML, the scanner finds it instantly. If it’s lazy-loaded with loading="lazy", injected via JavaScript after a framework hydrates, or set as a CSS background-image without a preload hint, the scanner can’t see it — and your LCP image doesn’t start downloading until much later in the page lifecycle, sometimes seconds later.

<!-- Wrong: invisible to the preload scanner --><div style="background-image:url('/hero.jpg')"></div><!-- Right: discoverable immediately, prioritized correctly --><img src="/hero.avif" fetchpriority="high"     width="1200" height="630" alt="...">

The fix costs nothing in engineering time and nothing in design: never lazy-load the element that’s visible on first paint, put it in raw HTML, and add fetchpriority="high" to tell the browser this is the resource worth racing for.

The Bytes Tax

Once the browser knows what to fetch, it still has to download every byte of it — and the web has gotten heavier, fast. HTTP Archive’s 2025 Web Almanac found the median mobile home page now weighs 2,362 KB, up from a comparatively svelte 845 KB a decade ago — a 202.8% increase, with JavaScript alone running roughly 690-700 KB of that median page.

Images remain the heaviest single category on most pages, and the cheapest lever you have is also the most underused one: format. MDN’s image format guide puts AVIF at roughly half the file size of a visually-equivalent JPEG, with WebP landing 25–35% smaller than JPEG per Google’s own compression research.

A worked example using the real HTTP Archive number above. If a typical hero image on a mobile page runs 180 KB as JPEG (a conservative, common real-world size for a full-width hero), switching to WebP at a 30% average reduction saves roughly 54 KB; AVIF at a 50% reduction saves roughly 90 KB. On a throttled “Fast 4G” profile (roughly 1.6 Mbps effective, the profile Lighthouse itself uses for mobile testing), 90 KB of avoided download is worth somewhere in the neighborhood of 450 milliseconds of pure transfer time — before you even account for the parsing and decoding savings smaller files bring. That’s not a guaranteed LCP improvement (see the Vanity Tax below for why), but it’s a real, physics-bound floor on how much faster the bytes alone can arrive.

The Vanity Tax — and the mistake I made

This is the tax most teams misdiagnose, and it’s the one behind the confession I promised earlier. A few years into doing this work, I spent the better part of a week on a client site doing exactly what every page speed checklist tells you to do: I compressed the hero image, switched it to WebP, cut it from 240 KB to about 95 KB, and felt very pleased with myself. I reran Lighthouse expecting a meaningful LCP drop.

The actual fix had nothing to do with the image. It was server-side rendering the hero markup so it existed in the initial HTML response, deferring the script that had been gating the reveal, and letting the (now also-compressed) image load in parallel instead of in sequence. LCP dropped by 1.3 seconds the day that shipped — and the image compression, which I’d treated as the headline fix, turned out to be a minor supporting contributor to a problem that was 90% JavaScript architecture.

The general pattern: anything that keeps already-downloaded content invisible — a loading spinner gating a fully-hydrated component, a CSS animation fading content in after JS runs, a framework that doesn’t render anything server-side and waits for full client hydration before showing a pixel — is paying the Vanity Tax. The fix is almost always some flavor of “render the above-the-fold content on the server, and let JavaScript enhance it after, not gate it before.”

Section 5 — ResponsivenessINP and the main-thread auction

If LCP is about how fast content arrives, INP is about whether the page is listening once it has. Interaction to Next Paint measures the full lifecycle of every click, tap, and keypress during a page’s life — input delay, processing time, and presentation delay — and reports back the worst one at the 75th percentile. It replaced First Input Delay on March 12, 2024, and the change exposed a problem FID had been quietly hiding: sites that scored a perfect FID because their first interaction was fast often had every interaction after that one blocked by long JavaScript tasks. Independent analyses found that roughly 38% of origins that passed FID failed INP outright once the stricter metric arrived, with the failure rate climbing to 47% on mobile specifically.

The mental model that actually helped this click for me: think of the browser’s main thread as a single-lane road with one auctioneer deciding what runs next. JavaScript executes in a “run-to-completion” model — once a task starts, it runs until it’s done, full stop, regardless of how badly the browser wants to paint a response to a click that happened mid-task. A “long task” is officially anything over 50 milliseconds, and the fix isn’t doing less work; it’s doing the same work in smaller pieces, with checkpoints where the browser can win the auction back.

That checkpoint mechanism has a name now: scheduler.yield(), part of the Prioritized Task Scheduling API. Unlike the older setTimeout() trick for yielding (which sends your continuation to the back of an unrelated queue), scheduler.yield() puts your function’s continuation in a slightly higher-priority lane than brand-new tasks, so your work still gets done promptly while letting the browser interleave a response to user input in between chunks.

async function processLargeDataset(items) {  for (const item of items) {    doExpensiveWork(item);    // Hand control back so a pending click can be painted    await scheduler.yield?.() ?? new Promise(r => setTimeout(r, 0));  }}

The optional-chaining fallback in that snippet matters: scheduler.yield() is currently available in Chromium-based browsers (Chrome and Edge, stable since version 129, September 2024), so feature-detecting and falling back to a microtask delay keeps the same code safe everywhere else. The single most effective first move, before you touch any scheduling API at all, is simply auditing what’s running on your main thread in the first place — which is where the next framework comes in.

An original quantitative model: the Third-Party Trust Budget

Every third-party script on your page — analytics, a chat widget, an ad network, a heatmap tool — has a measurable cost in main-thread milliseconds and an attributable benefit, usually in revenue or insight. Most teams audit neither rigorously, which is how a site ends up shipping eleven scripts nobody can explain. Here’s a simple methodology, illustrated with invented-but-realistic numbers so you can run the real version on your own stack:

The methodology, not the numbers, is the point: pull your real per-script main-thread time from Chrome DevTools’ Performance panel (filter by source), or from a RUM tool with attribution data, then sit each one next to whatever you can credibly attribute to it — a conversion lift you’ve actually A/B tested, not a vague “it’s good to have.” A script with high cost and no defensible attribution is the highest-leverage INP fix on most marketing-heavy sites, and it requires zero engineering — just removing a tag.

Section 6 — The quiet oneCLS: still the easiest, still worth doing properly

Cumulative Layout Shift has the highest pass rate of the three Core Web Vitals for a structural reason: most causes are simple, mechanical, and permanent once fixed. The two biggest sources, by a wide margin, are images and embeds without explicit dimensions (the browser doesn’t know how much space to reserve, so content jumps when they load) and web fonts that swap in late without a reserved-space strategy.

The fix list is short and doesn’t require a framework: set explicit width and height attributes on every <img>, <video>, and <iframe> (the browser computes aspect ratio from these even if your CSS overrides the rendered size); reserve space for ad slots before they load rather than letting them push content down on arrival; and use font-display: swap paired with matched fallback font metrics so text doesn’t visibly reflow when your web font finishes loading. None of this requires architectural change — it’s the single highest ratio of effort to pass-rate improvement in the entire Core Web Vitals set, which is exactly why I’m not spending three more sections on it.

Section 7 — The instant-navigation layerSpeculation Rules: making the next page already exist

Everything above optimizes a single page load. The Speculation Rules API does something stranger and, in late 2025 and 2026, increasingly standard: it lets the browser load and render a page the user hasn’t clicked yet, based on rules you define, so that by the time they do click, the navigation is essentially instant.

<script type="speculationrules">{  "prerender": [{    "source": "document",    "where": { "selector_matches": ".product-card a" },    "eagerness": "moderate"  }]}</script>

The eagerness setting is the dial that matters: conservative waits for a pointer-down (essentially the moment of commitment to click), moderate fires after roughly 200ms of hover intent, and eager speculates almost immediately, trading bandwidth for lead time. MDN’s Speculation Rules documentation and Chrome’s own implementation guide are both worth reading before shipping this, because there’s a real failure mode: prerendering a logout link, or any URL with a side effect, will silently trigger that side effect in the background. Don’t speculate on anything you wouldn’t be comfortable happening without the user’s explicit click.

The honest caveat here matters more than the impressive number: this is Chromium-only (Chrome and Edge), Safari has it disabled by default even where technically supported, and Firefox doesn’t support it at all. Because unsupported browsers simply ignore the <script type="speculationrules"> tag rather than erroring, it’s a genuinely safe progressive enhancement — your INP and LCP numbers don’t get worse anywhere, they just don’t get this particular boost everywhere yet.

Section 8 — Context most guides skipThe Platform Tax: where you build it starts the race

Two sites with identical content, identical images, identical marketing copy can have wildly different baseline Core Web Vitals purely because of what they’re built on — before a single optimization is applied.

This chart is genuinely instructive about where to spend effort, not just a platform-shaming exercise. Notice that WordPress’s INP-only pass rate (85.9%) is nearly identical to Duda’s overall pass rate — the responsiveness story is fine. The 38-point overall gap is concentrated almost entirely in LCP, which tracks with everything covered in the Physics and Bytes Tax sections: shared hosting, render-via-PHP-on-every-request architectures, and plugin-stacked image pipelines without modern CDN delivery. If you’re running WordPress, the highest-leverage moves aren’t usually “switch platforms” — they’re a proper page cache (object cache plus full-page cache, not just browser caching headers), an image CDN that auto-serves AVIF/WebP, and an audit of every plugin enqueueing render-blocking JavaScript in your ``. None of that requires leaving WordPress; all of it requires actually doing it, which most installs never have.

Section 9 — The take that’ll annoy some of youStop chasing a Lighthouse 100

Section 10 — Why any of this is worth doingWhat page speed is actually worth, with sources

Skepticism about performance work usually isn’t skepticism about the metrics — it’s skepticism about whether fixing them moves any number a CFO cares about. Google maintains a public page of its own customers’ case studies, and four of them are worth knowing because they’re independently verifiable, not marketing copy summarized secondhand.

The Renault study is the most methodologically rigorous of the four and the most useful for building your own internal business case, because it’s a regression across 10 million visits in 33 countries over four months, not a single before/after snapshot. Their finding: each 1 second of LCP improvement correlated with roughly a 14 percentage point drop in bounce rate and a 13% increase in conversion, with marginal gains continuing to grow even below 1.6 seconds of LCP — Renault never found a point of diminishing returns within a normal range of values.

An illustrative model built on that real elasticity — with the caveat, stated as plainly as I can, that this is one company’s regression on automotive lead-gen traffic, not a universal law, and your own elasticity could easily be half or double this depending on your category, price point, and traffic mix. If a hypothetical store doing $40,000 in monthly online revenue, converting at a typical ecommerce 2.5%, shaved 1 second off its LCP and saw even half of Renault’s documented conversion lift (6.5% relative, not 13%, to stay conservative), that’s a conversion rate move from 2.5% to roughly 2.66% — worth around $2,600 a month, or roughly $31,000 a year, before accounting for the bounce-rate improvement compounding on top of it. Build the real version with your own analytics, your own AOV, and your own honest discount on Renault’s number — but the structure of the calculation, gains-on-conversion times average order value times traffic, is the one worth stealing.

Section 11 — Where to actually startThe beginner-to-pro roadmap

Everything above is diagnosis. Here’s the order I’d actually work through it, tiered by how much technical depth each step requires.

FAQCommon questions, answered directly

ClosingThe thing worth remembering

If you take one idea from all of this, take the Honesty Gap, not the Four Taxes — frameworks are useful but replaceable, and the gap between what your tools tell you and what your users feel is the actual root of almost every performance team’s wasted effort. Measure field data first. Diagnose with lab tools second. Fix the tax that’s actually being charged, not the one that’s easiest to screenshot improving. The 55.9% of the web currently passing Core Web Vitals didn’t get there by chasing a perfect score — they got there by finding the specific, boring, structural thing that was actually slow, and fixing that thing.