How to check how much a web page weighs

Last updated: September 7, 2026

Page weight is the number behind most slow sites. It is also easy to measure wrongly, because the figure your browser shows depends heavily on cache state and on whether you count compressed or uncompressed bytes.

Method 1: the Network tab

The authoritative source is already in your browser.

Open DevTools and go to the Network tab.
Tick Disable cache. Without this you are measuring your own repeat visit, not a first visit.
Reload, then read the summary at the bottom: requests, transferred, and resources.

Transferred is what came over the wire, compressed. Resources is the uncompressed size after decoding. Transferred is the one that costs your visitor time and data; resources is the one that costs them memory and parse time. Quoting one when you mean the other is the most common mistake in a performance conversation.

Sort by the Size column to find the worst offenders, and use the type filters to see how the total splits between scripts, images and fonts.

Method 2: total it from the console

The Resource Timing API has the same data the Network tab draws from, so you can total it directly:

const r = performance.getEntriesByType("resource");
const total = r.reduce((n, e) => n + e.transferSize, 0);
`${(total / 1024 / 1024).toFixed(2)} MB over ${r.length} requests`

To see where the weight is going, group it by type:

Object.entries(performance.getEntriesByType("resource").reduce((acc, e) => {
  acc[e.initiatorType] = (acc[e.initiatorType] || 0) + e.transferSize;
  return acc;
}, {})).sort((a, b) => b[1] - a[1])

Two caveats. transferSize reads 0 for cross-origin resources unless the server sends a Timing-Allow-Origin header, so third party scripts and fonts can be invisible here. And Resource Timing has no entry for the HTML document itself, so the page's own bytes never make it into the total. Between them, that is why a console figure comes in under the Network tab.

Method 3: a lab tool

PageSpeed Insights and WebPageTest give you weight alongside timing metrics, from a controlled location.

They test what a fresh visitor gets, which is more honest than your own browser, but they run against the public URL. For a staging site behind auth, or a page you have to log in to reach, they are no help.

Method 4: read it on the page

For a quick answer while you are already looking at the page, Screen Ruler reports the weight broken down by scripts, stylesheets, images and fonts, without opening DevTools or leaving the tab. It works on pages behind a login, since it measures what your browser actually loaded. It reads the same Resource Timing data as the snippet above, so it carries the same cross-origin blind spot and tells you how many resources it could not see. This one is a paid feature.

Useful when you want to answer "is this page heavy" in a few seconds rather than set up a measurement.

What the numbers mean

Images are usually the bulk and the easiest win. Modern formats and correct sizing routinely halve the total without touching code.
JavaScript costs more than its size suggests. A 300KB script and a 300KB image are not comparable: the script has to be parsed and executed, the image does not.
Fonts are worth auditing. Four weights of two families is eight files, and most sites use three of them.
Third parties hide in the total. Sort by domain and it is common to find that analytics, chat widgets and tag managers outweigh the site itself.

Common questions

What is a reasonable page weight?

There is no fixed threshold, but under 1MB transferred is a comfortable target for a content page, and anything over 3MB deserves a look. Context matters more than the number.

Why is my measurement smaller than a colleague's?

Cache, almost always. Without Disable cache ticked you are measuring a repeat visit.

Does lazy loading change the total?

Yes, and that is the point of it. Weight measured on load will not include images below the fold until you scroll, so scroll the page before reading the final figure.