Page weight and requests: do they matter?

Two numbers, two different costs

Page weight is the sum of the sizes of everything the page loads: the HTML, styles, scripts, images, fonts, video and files from other companies' servers. Requests are the count of those files.

Browsers show two sizes for each file, and mixing them up causes confusion. The transfer size is what crossed the network, after compression. The resource size is what the file measures once the browser has unpacked it. A script that is 100 KB unpacked may travel as 30 KB. Lighthouse counts the transfer size, and the bottom of the Network panel in Chrome DevTools shows both totals.

The 2025 Web Almanac splits the effect of weight into three stages. In storage, files take space on the server. In transmission, bytes cross the network, where slow connections and lost packets make a heavy page worse. In rendering, the device has to process what arrived. Rendering is the part people forget. A 100 KB image is pixels, but 100 KB of JavaScript is work: the processor must parse, compile and run it, and on a low-end phone that work can freeze the screen for seconds. An image that travels as 200 KB can also take several megabytes of memory once it is unpacked into pixels.

What a typical page weighs

These are the median figures from the 2025 Web Almanac, which measured pages in HTTP Archive. Half of all pages are heavier.

On desktop the median home page was 2.9 MB, and the median page made 77 requests. Inner pages were lighter, at about 1.8 MB on phones and 2 MB on desktop, mostly because they carry fewer images. The median home page grew by about 8% in a year. Images were the biggest share on both kinds of device, followed by JavaScript and fonts.

Use these numbers as a reality check, not a target. A typical page is not a good page.

Does weight matter for speed?

Yes, but how it matters depends on what is heavy and when it loads.

• On a slow connection, bytes are time. Lighthouse's mobile test uses a download speed of 1.6 megabits per second. At that speed one megabyte takes about five seconds to arrive on its own. For example, a 2.6 MB page needs about thirteen seconds of pure transfer time at that setting. Real visitors are often faster, but many are slower.
• Not all bytes are equal. Largest Contentful Paint and First Contentful Paint depend on the files the first screen needs, not on the total. A heavy page can show its main content fast when the heavy parts load later, for example images below the first screen. A light page can be slow when one file that blocks rendering is slow. See critical CSS and render-blocking files and lazy loading.
• JavaScript costs twice. It must be downloaded and then run. Cutting it also helps responsiveness. See unused code.
• Weight costs the visitor money. Lighthouse's own description of its page size check says that large network payloads cost users real money and are highly correlated with long load times.

Page weight is not a Core Web Vital. It is one of the causes behind the metrics that are.

Do requests matter?

It depends on the protocol.

With HTTP/1.1, a browser works on one request at a time per connection. To go faster it opens several connections to each host, commonly six at once, as MDN describes. More than six files for one host queue up. This is the reason for the old advice to merge files, to combine small images into one sheet and to spread files over several host names.

HTTP/2 and HTTP/3 changed that. They carry many requests at the same time over one connection. MDN now calls the spreading of files over several host names, known as domain sharding, deprecated, and says it can even hurt performance. The number of files therefore matters less than it did. In the Speed Lab test of many small files, 62 requests finished 21 ms after 40 with the same bytes over HTTP/2, and 518 ms after them over HTTP/1.1.

It still matters somewhat:

• Each request has its own headers and its own place in the queue for priority, and the web.dev CDN guide notes that merging files can still pay off in practice, because larger files compress better.
• A new host costs a connection. The first request to a host includes an address lookup, a connection and a secure handshake, as MDN explains. Several requests to one host usually cost less than the same number of requests to several hosts.
• The Almanac points out that a page with 50 small images can feel slower than a page with one large image of the same total size, because of the transmission overhead of 50 requests.

So count hosts, not only files. Every third-party script is another host. See third-party scripts and resource hints.

What Lighthouse says about weight

Lighthouse has a diagnostic called Avoid enormous network payloads. It adds up the transfer size of every network request, shows "Total size was X KiB", and lists the ten largest files. It is a diagnostic with a weight of zero, so it does not change the Performance score.

The check still gives itself a score from a curve. In Lighthouse 13.5 a total of 2,667 KiB scores 90 and a total of 4,000 KiB scores 50. In other words, the line for "enormous" sits at about 2.6 MiB. The code comments say the numbers come from a 2017 sample of web pages, so they are older than the current median, which is close to that line.

How to see your own page

1. Open the page in Chrome and press Ctrl+Shift+J (Cmd+Option+J on a Mac). Open the Network tab.
2. Tick Disable cache to see what a first-time visitor downloads, and reload.
3. Read the summary at the bottom. It shows the number of requests, the data transferred and the unpacked size of the resources.
4. Sort by Size to find the heaviest files, and use the filter buttons to see one type at a time: images, scripts, styles, fonts and media.
5. Add the Domain column (right-click the column headers) to count the hosts.

What to cut first

Start with the biggest share and the easiest win:

1. Images and video. The largest share on the median page, 911 KB of images on a phone. Resize to the size shown, use a modern format, and load below-the-fold images later. See image optimization, WebP and AVIF and responsive images. Video that starts by itself should be small, or wait until the visitor asks for it.
2. JavaScript. The median phone page loads 632 KB, and the Almanac measured about 251 KB of unused JavaScript on the median mobile page. See unused code.
3. Third-party scripts. Remove the ones that nobody uses, and load the rest late. See third-party scripts.
4. Fonts. Fewer families and weights, in WOFF2. See web fonts.
5. Make the rest cheaper. Turn on text compression, and set caching headers so repeat visitors download less.

Set a budget

A performance budget is a limit that prevents regressions. MDN says it can apply to one file, a type of file, everything on a page, or a metric. It recommends two levels: a warning, which lets you plan work without blocking releases, and an error, which is a hard upper bound.

Start by looking at the devices and connections of your own visitors, and set limits you can reach. For example, a small business site might set a warning for the home page at 1.5 MB and an error at 2.5 MB. Those numbers are only an illustration. Tools such as a bundler or a build step in your release process can check the limits automatically.

Mistakes to avoid

• Chasing the request count. Merging everything into one huge file can delay the first screen, and one changed line makes visitors download all of it again. Split by what the first screen needs.
• Treating weight as the goal. A smaller page that still blocks rendering is slow. Fix the order of loading as well as the bytes.
• Comparing the wrong sizes. Check whether a number is the transfer size or the unpacked size.
• Forgetting repeat visits. Files that can be cached cost nothing the second time. See HTTP caching headers.
• Ignoring mobile. The same page weighs a little less on a phone, but phones have much less power to process it.

Check your own page

Run the free audit and look at the total size and the list of the largest files. If one or two files make up most of the weight, start with them. Then look at how many different hosts the page contacts, because that number tells you more about request costs than the file count.

Sources

• Page Weight chapter, Web Almanac 2025: medians by file type, the number of requests, why weight matters.
• Performance budgets on MDN: what a budget is and how to set one.
• Connection management in HTTP/1.x on MDN: parallel connections and domain sharding.
• Content delivery networks (CDNs) on web.dev: HTTP/2 multiplexing and why merging files can still help.
• Network features reference in Chrome DevTools: the summary, the Size column and Disable cache.