Page weight

Page weight is the total number of bytes a browser has to download to show a page: the HTML, every stylesheet, script, font, image and video, plus whatever third-party tags pull in. It is the oldest performance metric on the web and still one of the most useful, because every byte costs time on the network, battery on the device and, for visitors on metered connections, money. It is not a Core Web Vital, and a heavy page can pass all three, but weight sets the floor under Largest Contentful Paint on slow connections and is the first thing to check when a page is slow everywhere.

From PerfDelta's measurements: In the mobile lab test the median home page transfers 4.3 MB, with the middle half between 2.5 MB and 7.4 MB. 84% of the 4,108 home pages are heavier than 2 MB and 45% heavier than 5 MB. More in the data section below.

How page weight is measured

Two numbers are easy to confuse. Transfer size is what crosses the network, after compression. Resource size is the uncompressed size the browser works with. Lighthouse and PageSpeed Insights report transfer size per resource type in the "resource summary"; Chrome DevTools shows both in the Network panel. PerfDelta's reports use transfer size, measured in the mobile lab run of the home page, which is also the basis of the figures in the data section below.

Weight also depends on when you stop counting. Lazy-loaded images and scripts that load on scroll or interaction are not part of the initial load. A page that transfers 2 MB on load and another 6 MB as the visitor scrolls is heavy in total but may feel fast, which is the point of lazy loading.

Where the bytes go

Across the web, images are usually the largest category by bytes and JavaScript the second, with JavaScript having grown steadily for years according to the HTTP Archive's annual Web Almanac. On the large brand websites in our measurements the order is often reversed: JavaScript is the biggest item on the median home page, ahead of images, because tag managers, frameworks, A/B testing and personalization add up faster than image optimization removes. Fonts, CSS and the HTML document itself are a small share by comparison, but they sit on the critical path, so their size matters more per byte than an image below the fold.

What a good page size is

There is no official threshold. A useful way to think about it is a budget derived from the connection you want to serve well. On a slow 4G connection with roughly 1.5 Mbit/s of effective throughput, every megabyte costs around five seconds of pure transfer time. If the LCP target is 2.5 seconds, the resources needed for the first paint, which are the HTML, critical CSS, above-the-fold fonts and the LCP image, have to fit into a few hundred kilobytes, and everything else has to come later. For the whole page, under 1 MB is lean, 1 to 3 MB is typical for content sites, and above 5 MB is heavy by any standard. The data section below shows where the measured home pages sit against those lines.

How to reduce page weight

1. Images first. Serve them at the displayed size (properly size images), in AVIF or WebP, and lazy-load everything below the fold. On most pages these three steps remove more bytes than everything else combined.
2. JavaScript second. Remove unused code, split bundles by route, and audit third-party tags, which are often the largest scripts and the least noticed.
3. Compress and minify text. Brotli or gzip for every text response, and minify CSS and JavaScript in the build. Cheap, universal, and easy to lose during a server migration.
4. Fonts. WOFF2 only, subset to the characters you use, variable fonts instead of several weights, and no more than two families.
5. Video. Never autoplay a video file as a hero background on mobile. Use a poster image and load the video on interaction, or use a short, heavily compressed clip with a preload of none.
6. Cache what repeats. Weight for returning visitors drops to near zero when static files carry long cache lifetimes (efficient cache policy).

Setting a performance budget

A budget turns page weight from a one-time cleanup into a rule. Decide a limit per page type, for example 1.5 MB on load for product pages and 1 MB for articles, split it by resource type, and fail the build or alert when a change exceeds it. Lighthouse CI supports budgets through a budget.json file, and PerfDelta's monitoring tracks the page weight of each URL over time so that a new app or a marketing tag shows up as a step in the chart rather than as a surprise months later.

Frequently asked questions

Does page weight affect Google rankings?

Not as a metric of its own. It affects Largest Contentful Paint, which is a Core Web Vital, especially for visitors on slow connections. A lighter page is the most reliable way to a fast LCP on mobile.

Which is more important: fewer requests or fewer bytes?

With HTTP/2 and HTTP/3, bytes matter more than request count. Many small requests are cheap; a few large files are not. Focus on size, then on what is on the critical path.

How do I measure page weight on my own site?

Run a PageSpeed Insights test and open the resource summary, or use the Network panel in Chrome DevTools with caching disabled. PerfDelta reports show transfer size by resource type for each tested page.

Why is my page heavier on mobile than on desktop?

Usually because the mobile layout loads the desktop images anyway, or because a mobile-specific script or app is added on top. Check the image sizes served to small viewports first.