Page weight checker

Transfer weight, not uncompressed size. What matters is the bytes that crossed the network, which is what a visitor waits for.

The HTML document and every resource the served markup references, fetched and measured individually.

The heaviest resources of any type, ranked, so the finding is a short list rather than a total.

The number of resources the HTML references. This is a count of referenced files, not of browser requests, which differ once caching and connection reuse are involved.

Resources answering with an error status, which are weight-free and break layout or functionality outright.

Weight is not evenly distributed. A typical page has a few files responsible for most of the bytes and a long tail responsible for very little.

Working from the total encourages broad optimisation across everything, which is a lot of effort spread across the part that does not matter.

Working from the ranking is usually three or four decisions: one image at the wrong size, one script that could be loaded later, one font file in a format nobody needs any more.

The same logic applies to the request count. Many small resources cost scheduling rather than bandwidth, and on a modern connection that cost is far smaller than it used to be — which is why the count is reported as context rather than as a target.

A referenced resource answering with an error status transfers almost nothing and breaks something for every visitor.

A missing stylesheet produces an unstyled page. A missing script disables whatever it implemented, often silently. A missing image leaves a gap.

These do not show up as weight, which is exactly why a weight-focused audit can miss them, and why they are reported alongside.

The usual cause is a deployment where an asset path changed and one reference was not updated — which means it breaks for everyone at once and is easy to fix once seen.

A scan has a budget. Not every resource on a heavy page can be fetched, and the ones that could not be are reported as unmeasured.

Which means the total is a floor rather than an exact figure: the real page is at least this heavy.

An audit that presented a partial measurement as a complete one would understate weight on exactly the pages where weight is the problem.

So the coverage figure should be read first. A total measured over most of the inventory is a number to act on; a total measured over a fraction of it is a starting point.

`performance.page_weight` reports the total transfer weight really observed. `performance.heavy_resources` ranks the largest measured resources of any type.

`performance.request_count` reports how many resources the served HTML references. `performance.resource_errors` reports referenced resources answering with an error status.

`performance.scan_limits` states how much of the inventory could really be measured under the scan budget, which is what keeps every figure above honest.

Measured from one network path at one moment. A visitor on a different edge node or a different negotiated encoding transfers a different number of bytes.

Resources fetched by script after the page renders may not be in the inventory, since the inventory is built from what the served HTML references.

The total is a floor, bounded by the scan budget, and the coverage statement says by how much.

Weight predicts load time; it does not measure it. What a visitor experiences also depends on ordering, on rendering and on their connection.