The Web's 1,000 Most Popular Sites Pass Core Web Vitals 65% of the Time. The Long Tail Manages Just 39%.

The thousand most-visited websites on earth are run by the companies with the deepest engineering benches in the world. They have dedicated performance teams, global content-delivery networks and budgets that dwarf most companies' revenue. You would expect them to clear Google's Core Web Vitals every time. They do not. One in three of the world's 1,000 most popular sites still fails on mobile, and the most popular tier of all is far less responsive than the long tail.

Speed is not a vanity metric. Google's own research shows the chance a visitor gives up on a page climbs sharply as it slows; retail conversion rates rise measurably with every tenth of a second shaved off load time; and since 2021 Core Web Vitals has been a documented ranking signal in Google Search. A slow site loses users, sales, search visibility and the quiet trust a page earns when it reacts the instant you touch it. That the biggest names on the internet are among the ones falling short is exactly what makes the pattern worth reading.

None of this comes from a lab. Every figure here is drawn from the Chrome User Experience Report, Google's public record of what real Chrome users experienced on real devices and networks, and the same family of field signals Google's ranking systems use. Across 11.1 million measured origins, popularity and passing move together, and then, on mobile, they cross over.

The data is the Chrome User Experience Report, Google's public dataset of real-user field measurements collected from Chrome. We grouped every origin CrUX measures into five traffic-popularity tiers, the top 1,000, the top 10,000, the top 100,000, the top million, and everything beyond, and scored each on mobile at the 75th percentile. On mobile that is 11,123,248 measured origins in total, effectively the whole measurable web.

A site passes Core Web Vitals only when all three metrics land in the good range at the 75th percentile: Largest Contentful Paint under 2.5 seconds for loading, Interaction to Next Paint under 200 milliseconds for responsiveness, and Cumulative Layout Shift under 0.1 for visual stability. Each number below is a real reading in Google's public dataset, an achievable bar every site is measured against the same way, and one many sites already clear.

Overall, popularity and passing go together. The top 1,000 sites pass on 64.7% of mobile origins, while the long tail beyond the top million passes just 39.2%. Big, well-resourced sites are markedly more likely to pass, as you would expect from organizations with performance teams and budgets. But more likely is not reliably. A third of the world's 1,000 most-visited sites still fails Core Web Vitals on mobile. At the very top of the web, failing is common.

Break the pass rate into its parts and the advantage of the popular sites turns out to be entirely in loading. Good Largest Contentful Paint climbs steadily with popularity, from 65.0% in the long tail to 81.3% in the top 1,000 on mobile. Responsiveness runs the other way. Good Interaction to Next Paint is lowest for the most popular sites: 72.5% in the top 1,000 versus 84.0% in the long tail. The head of the web loads fast and responds slowly. The tail loads slowly and responds fast. They cross over.

The explanation is JavaScript. The most popular sites are disproportionately complex web applications, the social networks, dashboards, streaming platforms and large e-commerce brands people open every day, built as heavy single-page apps that run a great deal of code on the main thread. That investment buys fast loading through CDNs, optimized images and prioritized content, but it loads the main thread with exactly the work that INP punishes. The long tail is full of simple, mostly static sites that ship little JavaScript. They often load slowly on cheap hosting, yet once loaded they respond instantly, because there is almost nothing for the main thread to do.

The crossover is a mobile phenomenon. On a desktop CPU, even a heavy app's main-thread work clears fast enough that INP stays green across every tier, between 92% and 98% good. It is only on mid-range phone hardware, where main-thread time is scarce, that the popular sites' JavaScript weight becomes a responsiveness penalty. The full tier table shows the tug-of-war in one view: LCP rising with popularity, INP falling, and the pass rate landing wherever the two forces balance.

Mobile, 75th percentile. LCP rises with popularity, INP is far lower across the popular tiers and best in the tail. The pass rate is the tug-of-war between them.

The headline sites are a small, comparatively healthy slice. The 10 million-plus origins beyond the top million pass just 39.2% on mobile, and that is where the bulk of the web, and the bulk of its Core Web Vitals failures, sit. The long tail drags the web-wide average down not because those sites are uniquely broken but because there are so many of them. Fixing the web means fixing the tail, and the tail's problem is loading, not responsiveness.

The work is real at every tier, and it is specific. For the popular, JavaScript-heavy applications at the head of the web, loading is close to solved, 81.3% good LCP in the top 1,000, and responsiveness is the open problem, 72.5% good INP, far below the long tail. The fix is main-thread work: break up long tasks, trim hydration, and defer the scripts that are not needed for the first interaction. More CDN will not move it, because loading is the part these sites already won.

For the long tail the picture flips. Those 10 million-plus sites respond well, 84.0% good INP, the best on the web, and they fail on loading at scale, passing just 39.2% on mobile. Their fix is lighter pages: better hosting, smaller images, fewer render-blockers. One caution for everyone is that the crossover is mobile-only. On desktop every tier sits at 92% to 98% good INP, so a healthy desktop score can hide a responsiveness problem that shows up only on the phone hardware most visitors actually use. Read the mobile field number, find whichever of the two metrics is dragging, and fix that one.