A Page's Total Weight Barely Predicts Whether It Passes Core Web Vitals

The median web page weighs 2.6MB and makes 71 separate requests to load. You would expect the heaviest pages to fail Core Web Vitals far more often than the lightest. They barely do.

Page weight is where the intuition about speed and the reality of speed part ways, and the gap costs site owners real effort in the wrong place. Teams chase a kilobyte target believing it will move their scores, while the metrics that decide conversions and Google rankings reward something else entirely: how fast the main content paints and how quickly the page responds to a tap. Getting that distinction right is the difference between optimization that works and optimization that just feels productive.

We measured 15.7 million web pages by joining the HTTP Archive, the open dataset that crawls millions of real homepages and records every byte they load, to Google's Chrome User Experience Report, the real-user field data that tracks how those pages actually perform. Here is what the typical page is made of, why its weight barely predicts whether it passes, and how far the extremes really go.

The figures come from the HTTP Archive's June 2026 mobile crawl joined to the Chrome User Experience Report, Google's record of real-user experience, from the May 2026 release. Medians and percentiles come from 15,695,088 pages with a recorded size. Pass rates come from the 9.58 million pages that also have a mobile CrUX reading, where a page passes Core Web Vitals only when its 75th-percentile loading (LCP) is 2.5 seconds or less, responsiveness (INP) is 200 ms or less, and visual stability (CLS) is 0.10 or less, all present.

Every year the web gets heavier, and 2026 continues the trend. Across nearly 16 million pages, the median weighs 2.6MB and makes 71 individual requests to load. The average sits higher at 5.2MB, because a long tail of enormous pages pulls the mean above the typical site, and the heaviest 10% of pages weigh more than 11MB and fire over 200 requests each.

Break the median page into parts and images lead. The typical page carries 895 KB of imagery, more than its JavaScript (677 KB), fonts (129 KB), and HTML (33 KB) put together. It loads 17 separate images and 21 separate scripts. If you want one sentence for where the bytes go, it is pictures first, scripts second, which is why modern image formats are the cheapest lever on the weight that matters.

Here is what the data does not show. You would expect a straight line where heavier pages fail and lighter pages pass. That line is almost flat. Pages under 1MB pass Core Web Vitals 42.2% of the time. Pages over 10MB, more than ten times heavier, pass 40.6% of the time. The entire spread across the full weight range is under 4 points, and it is not even a straight decline. The band that passes most often is 1 to 3MB, at 43.9%.

The reason weight and Core Web Vitals have come apart is that the metrics measure experience, not bytes. Largest Contentful Paint cares how fast the main content paints, so a 10MB page that lazy-loads its below-the-fold images, prioritizes its hero, and defers non-critical scripts can paint quickly despite its size. Interaction to Next Paint cares about main-thread JavaScript, not download size. A heavy page can be well built, and a light page can be badly built.

The 1 to 3MB sweet spot tells the same story from the other side. The sub-1MB group is not full of highly optimized sites. It skews toward thin, parked, or low-effort pages, many on cheap hosting with mediocre real-user metrics. The 1 to 3MB band is where competent, normal websites live: enough content to be real, built with enough care to load well. Weight on its own is a proxy for nothing. What matters is how the bytes are loaded.

Loading a modern web page is not one download. It is dozens. The median page in our data makes 71 separate HTTP requests, and the composition is revealing: 21 of those are JavaScript files and 17 are images, with the remainder split across CSS, fonts, the HTML document itself, and third-party calls. JavaScript, not imagery, is the most-requested resource type on the typical page. That is a sign of how much of the modern web is assembled from many small script modules and third-party tags.

For years, "reduce the number of requests" earned its place near the top of every performance checklist, because each request once carried a real cost: a separate round-trip, connection setup, and head-of-line blocking under HTTP/1.1. That world is mostly gone. HTTP/2 and HTTP/3 multiplex many requests over a single connection, so firing 70 requests instead of 30 no longer means 70 sequential trips. Sort pages by how many requests they make and the Core Web Vitals pass rate hardly budges.

Medians are across 15,695,088 pages; pass rates are among the 9.58 million pages with a mobile CrUX reading.

That does not make request count meaningless. It means it is no longer a headline metric on its own. What each request does still matters enormously. Twenty-one JavaScript files that block the main thread will wreck Interaction to Next Paint regardless of how efficiently they were delivered. The lesson of the modern protocols is that the delivery cost of many requests has collapsed, while the main-thread cost of your JavaScript has not.

Averages hide a dramatic tail. A minority of homepages fire off enormous numbers of requests, some over 2,000 on a single page load. When we looked at the worst offenders, they fell into two camps: giant image galleries loading hundreds of individual photos, and pages carrying heavy advertising and tag-manager stacks that each pull in dozens of third-party calls. Request count also climbs steeply with page weight, from about 28 requests on pages under 1 MB to roughly 161 on pages over 10 MB, so the two travel together, yet neither reliably predicts whether a page passes. These extreme pages are genuinely slow for users, but they are outliers, not the norm. The median experience is a far more modest 71 requests.

Do not chase a page-weight number as your Core Web Vitals strategy. The pass rate moves less than 4 points across a tenfold range of weight, from 42.2% under 1MB to 40.6% over 10MB, and the band that passes most sits in the middle at 43.9% for 1 to 3MB. A kilobyte target will not reliably move your scores, because Largest Contentful Paint rewards a fast content paint and Interaction to Next Paint rewards a free main thread, neither of which is total transfer size.

Do the work the metrics reward, and the weight that matters falls away as a by-product. Sizing your largest image correctly and lazy-loading everything below the fold moves loading and responsiveness directly, which is the same basic hygiene that cuts an image-heavy page by most of its weight. Keep total weight in perspective: it bites mainly at the extremes, on metered connections where a very heavy page costs real users real data, and even there the fix is ordinary image discipline.