Core Web Vitals Pass Rates: What Percent of the Web Actually Passes in 2026

Core Web Vitals are three field metrics that Google collects from real Chrome users. Largest Contentful Paint (LCP) measures loading, specifically when the largest piece of content finishes rendering. Interaction to Next Paint (INP) measures responsiveness across every interaction in a session. Cumulative Layout Shift (CLS) measures visual stability.

The "good" thresholds, defined by Google on web.dev, are 2,500 milliseconds or less for LCP, 200 milliseconds or less for INP, and 0.1 or less for CLS.

A site does not pass by being good on average. It passes a metric when at least 75 percent of real visits clear the threshold, measured at the 75th percentile over a rolling 28-day window. It passes overall only when LCP, INP, and CLS all clear at the same time.

CrUX publishes all of this monthly in BigQuery. We used the materialized.device_summary table, which holds one row per origin per device per month, and materialized.country_summary for the geographic cut. We graded only origins that had all three metrics present. That left 8,166,338 mobile origins and 5,586,936 desktop origins in the May 2026 release.

One technical detail is worth stating plainly, because it is where a naive query goes wrong. The bucket columns in CrUX (the share of traffic that is fast, average, or slow for each metric) are stored jointly with device share. The value sitting in a phone row is the share of the origin's entire traffic that is both on a phone and in that performance bucket, not the share of phone traffic in that bucket.

To get the pass rate for a device, you have to normalize each metric by that device's total density first, then apply the 75 percent test. Our first attempt skipped that step and produced a desktop pass rate near 9 percent, which is obviously wrong. After normalizing, the method reproduced the published July 2025 figures (roughly 56 percent desktop and 48 percent mobile, per the HTTP Archive Web Almanac) to within a point.

INP replaced First Input Delay (FID) as an official Core Web Vital on March 12, 2024. FID measured only the delay before the first interaction, which was an easier bar than INP, which captures every interaction. For our five-year trend we applied the current INP-based definition to every year, so the numbers read a little lower than older reports that used FID for the early years, but they compare cleanly across time. We omitted 2021 because INP coverage that far back was too sparse to grade fairly.

For the May 2026 dataset, the pass rate for all three Core Web Vitals was 58.0% on desktop and 49.1% on mobile. The nine-point gap between the two is the single most important piece of context for any pass-rate number you see quoted.

Mobile is the number that matters more for most businesses. It is the stricter bar, so it is the one more sites fail, and it is closer to how the web is actually experienced.

When we weight the two device populations together, the all-origin pass rate lands around 52.7%, closer to the mobile figure than the desktop one, because mobile has more measured origins pulling the average down.

If you take one figure away from this study, make it this: on the device most of your customers use, slightly less than half of the web passes. Clearing the bar is not table stakes that everyone has already met.

The web is getting faster, and the improvement is consistent rather than lumpy. On our INP-consistent definition, the mobile pass rate climbed from 28.6 percent in 2022 to 49.1 percent in 2026, a gain of more than 20 points.

Desktop rose from 42.6 percent to 58.0 percent over the same span. The gap between the two devices has narrowed from about 14 points in 2022 to about 9 points in 2026, which means mobile has been improving slightly faster than desktop.

Two forces are pushing these numbers up. Browsers and devices keep getting faster on their own, so a site that did nothing would still drift slowly upward. At the same time, the tooling has matured, with frameworks, content platforms, and hosts shipping better defaults for image handling, lazy loading, and caching.

There is a quieter consequence in that trend. The bar effectively rises as the median rises. A score that passes comfortably today can slide toward the threshold over the next year as the rest of the field improves around it, even if your own numbers hold flat. Passing Core Web Vitals is a position you hold against a moving median, not a box you tick once.

Averages hide the most useful part of the story. When a site fails the overall assessment, it usually fails on one specific metric, and that metric is different on mobile than it is on desktop.

On mobile, loading is the bottleneck. Only 64.4% of mobile origins have good LCP, well below the 78.7% that have good INP and the 80.9% that have good CLS.

If a mobile site is failing the overall assessment, LCP is the most likely culprit by a wide margin. The usual causes are heavy hero images, render-blocking resources, and slow server response, all of which hit hardest on a mid-range phone over a mobile network.

Desktop tells a different story, and it runs against conventional wisdom. Desktop CLS sits at 72.8% good, which is actually lower than mobile's 80.9%. Desktop layouts shift more, not less. The likely reasons are wide hero areas, larger ad slots, and late-loading sidebars and embeds that push content around once it appears.

Desktop responsiveness, meanwhile, is close to a solved problem at 97.3% good, because a laptop has the processing headroom to handle JavaScript that would choke a phone. So on desktop the weak link is visual stability, while on mobile it is loading.

The mobile responsiveness number deserves a closer look too. INP good rate is 97.3% on desktop but only 78.7% on mobile, the widest device gap of any metric. That gap is a hardware story. Phones have weaker processors, and the JavaScript that a laptop shrugs off can leave a phone visibly slow to respond to a tap.

Popularity buys performance, but not in a straight line. We graded origins by their CrUX rank magnitude, which groups sites into popularity bands by traffic, and the pattern that emerged was a U-shape on mobile.

The most-visited sites pass best. The top 1,000 origins clear all three Core Web Vitals at 55.9% on mobile and 63.5% on desktop, both comfortably above the global averages. These sites have the budgets, the dedicated performance teams, and the content delivery networks to stay fast.

What is more interesting is the dip in the middle. Mobile pass rates bottom out at 41.7% for sites ranked between 10,000 and 100,000, the worst of any band. These are established sites with real traffic but typically without a performance specialist on staff.

Then the long tail recovers to 49.7% on mobile, because the smallest sites are often simple, lightweight pages that load quickly almost by accident.

Desktop, by contrast, stays remarkably flat across every band, ranging only from about 57.7 to 63.5%. With more processing power and bandwidth to absorb a heavy page, desktop performance is less sensitive to how much complexity a site carries. The popularity penalty is a mobile phenomenon.

Geography may be the most underappreciated factor in Core Web Vitals. The same code, shipped to two different countries, can pass in one and fail badly in the other, because the metrics measure the real experience of real users on the devices and networks they actually have.

Across markets with at least 30,000 graded origins, the spread between the best and worst country was roughly tenfold.

Top three markets, mobile, May 2026:

Bottom three markets, mobile, May 2026:

The top of the table is dominated by Northern Europe and East Asia. The bottom is a connectivity story, with Nigeria at just 7.1%. The full 40-country breakdown is in our companion website speed by country study.

We did not compute pass rates by platform in this study, because that breakdown requires joining CrUX to a technology-detection dataset rather than the straightforward grading we did everywhere else. For context, the published HTTP Archive CMS technology report (November 2025) is worth citing.

By that report, overall Core Web Vitals pass rates ranged from roughly 85 percent on Duda and 79 percent on Webflow down to about 46 percent on WordPress and 40 percent on Magento, with Shopify near 75 percent, Wix near 75 percent, Squarespace near 70 percent, Drupal near 63 percent, and Joomla near 57 percent.

That is close to a 40-point spread, driven mostly by defaults: theme weight, image handling, render-blocking scripts, and whether edge caching ships out of the box.

The WordPress figure is the one most people misread. An overall pass rate near 46 percent makes WordPress look slow across the board, but its INP good rate in that report is around 86 percent, comparable to Wix and Squarespace. WordPress is responsive. Where it falls short is loading, which lines up exactly with our finding that LCP is the web-wide mobile bottleneck.

The platform sets the floor. The build decides the ceiling. A disciplined WordPress site with a light theme and clean image handling can pass comfortably, and a Shopify or Duda site stuffed with third-party apps can still fail.

A recurring and expensive mistake sits underneath all of these numbers: comparing the wrong score.

Google assesses Core Web Vitals for ranking from CrUX field data, which is real Chrome users measured at the 75th percentile over a 28-day window. That is exactly the data we queried for this study. Lighthouse, by contrast, runs a single simulated load on one machine in a controlled environment. It is a useful diagnostic for catching regressions before they ship, but it is not the score Google ranks on.

A site can hold a perfect Lighthouse 100 while failing its CrUX assessment.

Two consequences follow. First, judge a site by its field data, not its lab score, when the question is whether it passes for ranking.

Second, remember that field data lags. CrUX reflects a fix roughly four weeks after it ships, as old sessions roll out of the 28-day window. A flat field score the day after a deploy is expected, not a failure, and the right move is to re-measure after the window has turned over rather than to conclude the fix did not work.

Pull these threads together and a clear set of priorities falls out.

Start by measuring the right thing. Pull your origin's field data from the CrUX dashboard or PageSpeed Insights, read it per device, and compare it to the benchmarks in this study. Above 58 percent puts you ahead of the desktop average. Below 49 percent puts you behind the mobile field.

Then fix by metric and by device, because the data shows they differ. On mobile, look at LCP first, since loading is where 36 percent of mobile origins fail. On desktop, check CLS, since visual stability is the desktop weak point that most teams never think to inspect. Reducing and deferring JavaScript helps mobile responsiveness specifically, where the device gap is widest. For a full walk-through of the fixes that move each metric, see how to pass all three Core Web Vitals.

Weigh your platform and your audience honestly. Your content platform sets a starting floor, and your users' countries set the difficulty. The mid-market sites in the 10,000 to 100,000 popularity band, which post the lowest mobile pass rates of any group, are exactly where focused optimization moves the number most.

The business case for doing the work does not rest on the ranking question alone. Portent found conversion rates fall from 3.05% at a one-second load to 0.41% at five seconds. Google has reported roughly a 7% conversion loss for every additional second of delay. Deloitte found that a 100-millisecond improvement can lift conversions by about 1%.

As of the May 2026 Chrome User Experience Report, 49.1% of the mobile web and 58.0% of the desktop web passed all three Core Web Vitals, computed across 13.75 million origins.

Mobile is improving faster than desktop but still trails it by nine points. LCP is the metric that fails mobile sites, CLS is the surprise weak point on desktop, the mid-market struggles most on phones, and a site's country can swing its odds tenfold.

Source and date. The public chrome-ux-report BigQuery dataset, May 2026 release (yyyymm 202605), the latest available at the time of writing. Every pass-rate figure in this study was computed by us against that dataset. The only third-party figures are the platform pass rates in the platform section (HTTP Archive CMS technology report, November 2025), the threshold definitions (web.dev), and the business-impact statistics in the closing section (Portent, Google, and Deloitte, as cited).

Definition of pass. Origin-level field data. An origin passes when LCP, INP, and CLS are all good at the 75th percentile of real Chrome-user visits, per device, over CrUX's 28-day window. We restricted the analysis to CWV-eligible origins, meaning those with all three metrics present: 8,166,338 on mobile and 5,586,936 on desktop.

The key computation. CrUX's device_summary table stores bucket densities jointly with device share, so we normalized each metric by its device total (for example, fast_lcp / (fast_lcp + avg_lcp + slow_lcp)) before applying the 75 percent test. We validated the method against the July 2025 release, where it reproduced the published 56 percent desktop and 48 percent mobile figures to within a point.

INP-consistent trend. INP replaced FID as a Core Web Vital on March 12, 2024. Our trend applies the INP-based definition to every year, so the figures read lower than FID-era reports but compare cleanly across time. 2021 is omitted because INP coverage was too sparse to grade reliably.

Refresh cadence. Re-run the queries against each new monthly release to keep the numbers current. For an annual headline, take a fixed month each year for a clean comparison.

How to cite. PageSpeed Matters, "Core Web Vitals Pass Rates: What Percent of the Web Actually Passes in 2026," computed from the Chrome User Experience Report, May 2026 release.

The headline query, run against chrome-ux-report.materialized.device_summary for yyyymm 202605:

```sql WITH s AS ( SELECT device, SAFE_DIVIDE(fast_lcp, fast_lcp + avg_lcp + slow_lcp) AS lcp_good, SAFE_DIVIDE(fast_inp, fast_inp + avg_inp + slow_inp) AS inp_good, SAFE_DIVIDE(small_cls, small_cls + medium_cls + large_cls) AS cls_good FROM `chrome-ux-report.materialized.device_summary` WHERE yyyymm = 202605 AND device IN ('phone', 'desktop') ) SELECT device, COUNT() AS origins, ROUND(100 COUNTIF(lcp_good>=0.75 AND inp_good>=0.75 AND cls_good>=0.75)/COUNT(), 1) AS pct_pass_all, ROUND(100 COUNTIF(lcp_good>=0.75)/COUNT(), 1) AS good_lcp, ROUND(100 COUNTIF(inp_good>=0.75)/COUNT(), 1) AS good_inp, ROUND(100 COUNTIF(cls_good>=0.75)/COUNT(*), 1) AS good_cls FROM s WHERE lcp_good IS NOT NULL AND inp_good IS NOT NULL AND cls_good IS NOT NULL GROUP BY device ORDER BY device;

The trend, popularity, and country queries follow the same normalize-then-test pattern, grouping by month, rank band, or country code respectively. The complete query set ships alongside this study.

1. Chrome User Experience Report (CrUX), BigQuery dataset, chrome-ux-report.materialized.device_summary and country_summary, May 2026 release. Primary source for all computed figures. https://developer.chrome.com/docs/crux/bigquery

1. Google Chrome for Developers, Rank Magnitude in the CrUX Report. https://developer.chrome.com/blog/crux-rank-magnitude

1. web.dev, How the Core Web Vitals thresholds were defined. https://web.dev/articles/defining-core-web-vitals-thresholds

1. HTTP Archive, 2025 Web Almanac, Performance chapter (used to validate our method). https://almanac.httparchive.org/en/2025/performance

1. HTTP Archive, CMS technology report (platform pass rates). https://httparchive.org/reports/techreport/category?category=CMS

1. Portent, Site speed and conversion research. https://www.portent.com/blog/analytics/research-site-speed-hurting-everyones-revenue.htm

1. Google Search Central, Core Web Vitals and page experience. https://developers.google.com/search/docs/appearance/core-web-vitals