Page Weight Checker

How to Use This Tool

1. 1

   Enter the URL

   This takes a few seconds on a heavy page, because it is making real requests rather than reading numbers out of the HTML.

2. 2

   Look at the breakdown bar

   It shows where the weight sits. On most pages one category dominates, and that is the one worth working on.

3. 3

   Read the largest resources

   Page weight is concentrated rather than spread. Fixing the top two files usually removes most of the excess.

4. 4

   Sort by size, then check what blocks rendering

   A large file that loads after the page has painted costs much less than a small one that holds up the first render.

Why Measuring Beats Estimating

Plenty of tools report page size by reading the HTML and adding up assumptions — so many scripts at a typical size, so many images at an average weight. The number looks precise and describes nothing.

The problem with that approach is that page weight is not evenly distributed. A typical page is a few small files and one very large one, and the large one is invisible to an estimate. A 4MB hero image that nobody resized is the single most common cause of a heavy page, and no amount of counting tags will find it.

So this downloads them. It is slower and it is the only way to get a figure that means anything.

One detail that matters: resources are requested with compression enabled, the way a browser does. A JavaScript bundle that is 900KB on disk and 240KB over the wire is a 240KB problem, and reporting the larger number would be misleading in the direction of alarm.

What Actually Makes Pages Heavy

• Images that were never resized. An image uploaded at camera resolution and displayed at 600px wide carries several megabytes for no visible benefit. This is the most common single cause by a wide margin.
• JavaScript bundles. Heavier than their size suggests, because unlike an image, a script has to be parsed and executed on the main thread — which is what stops a page responding to taps.
• Web fonts. Each weight and style is a separate file. Loading four weights of two families is eight downloads before any text renders in the right typeface.
• Third-party scripts. Analytics, chat widgets, tag managers, ad scripts. Individually small, collectively often the largest category, and the only lever you have is whether they load at all.
• Uncompressed text. Not a size problem so much as a configuration one — see below.

Compression Is the Cheapest Fix Available

JavaScript and CSS are text, and text compresses extremely well — typically to a quarter of its original size or less with gzip, and better with brotli.

When this tool reports a text resource served without compression, it means the server is sending several times more bytes than it needs to. There is no code change involved: it is a server or CDN setting, it applies to every file at once, and it is usually a single line of configuration.

That makes it the highest-value item on this list whenever it appears. Most modern hosting enables it by default, which is why it tends to show up on self-managed servers and on assets served from a misconfigured subdomain rather than on the main site.

Render-Blocking Resources

Total weight is not the only thing that matters. When a resource loads matters as much as how big it is.

A render-blocking resource has to be downloaded and parsed before the page can paint anything. A 50KB blocking script delays the first paint more than a 500KB image loaded further down the page, because the image does not stop anything happening.

Stylesheets block by design, and that is correct — it is what prevents a flash of unstyled content. The number to look at is scripts.

A script without `defer` or `async` stops HTML parsing while it downloads and runs. Adding `defer` to anything not needed for the first render is usually the single cheapest performance improvement available, and it is a one-attribute change. Scripts using `type="module"` are deferred automatically.

Third-Party Weight

The share of page weight coming from other origins is worth watching, because it is the part you control least.

You cannot optimise a third-party script. You cannot compress it, split it, or make its server faster. The only decision available is whether it loads at all, which makes each one a straight trade: what it does for you against what it costs everyone who visits.

That trade is often worth making and often never revisited. Tag managers accumulate tags, and a site can end up loading an A/B testing script for an experiment that ended two years ago, or three analytics tools where one would do.

Auditing them periodically is worth more than optimising your own code around them, because removing one is a bigger win than anything you can do to the rest.

What Weight Does and Does Not Predict

Bytes are one input to loading speed rather than the whole of it. A light page on a slow server still feels slow, because time to first byte puts a floor under everything that follows. A heavy page on a fast connection with good caching can feel fine.

Request count matters separately. Thirty small files can be slower than three larger ones on a high-latency connection, since each request carries its own round trip.

And JavaScript execution is its own cost, unrelated to size. A small script doing expensive work on the main thread hurts responsiveness more than a large one that does very little.

So treat this as a diagnostic rather than a verdict. It tells you what is on the page and how big it is, which is exactly what you need to decide what to remove. For measured loading performance, our Core Web Vitals Checker runs a real throttled audit through Google's own API — and this tool is the one to reach for when that audit says a page is too heavy and you need to know which file is responsible.

Where This Fits

Caching decides how much of this weight a returning visitor pays again. Our HTTP Header Checker shows the Cache-Control directives on any URL, and static assets with a hash in the filename can safely be cached for a year.

On the layout side, our Mobile-Friendly Checker flags images with no width and height, which cause layout shift as they load — a different problem from the same files, and one that is worse on the slow connections where weight already hurts most.

Frequently Asked Questions

Related Tools