Page too heavy

Images, almost always the largest share on a content or commerce page, and the one most often oversized rather than merely numerous.

JavaScript, second by bytes and first by cost per byte, because those bytes are parsed and executed rather than merely decoded.

Fonts, which are small individually and add up: four weights of two families is eight files before any text appears.

CSS, usually modest unless a framework is shipped whole.

Video, which dwarfs everything else when an autoplaying background video is present.

Third parties, which are not a resource type but a source, and frequently contribute more than the site's own code.

Connections are faster, so a heavy page on a good connection may load quickly. That is the reason weight alone is a poor single metric.

It still matters on a mobile network, on a congested connection, and anywhere data is metered — which describes a substantial share of the world's browsing.

It matters for parse and decode work regardless of connection speed, because that is CPU-bound and unaffected by bandwidth.

And it correlates with everything else: a heavy page usually has oversized images, unbundled scripts and unreviewed third parties, so the number is a symptom worth following even when it is not the disease.

The metrics Google publishes — Largest Contentful Paint, Interaction to Next Paint, Cumulative Layout Shift — measure experience rather than weight, and weight is one of the main things that moves them.

In the Network panel, disable the cache and reload. The transferred total at the bottom is the first-visit weight, which is the number that matters for a new visitor.

Then reload with the cache enabled for the repeat-visit number. The gap between the two is what your caching policy is worth.

Group by resource type to see the shares, and by domain to see how much is yours.

Measure the pages people actually land on — a product page, a search result, an article — rather than the home page, which is usually the most optimised page on the site.

Throttle to a slow connection and record the time to first paint. That converts the weight into the number a visitor experiences.

Images, by resizing rather than compressing. This is nearly always the largest available reduction and it changes nothing visually.

Unused JavaScript, by splitting per route. The second largest, and the one that also reduces CPU work.

Third-party tags nobody reads, which cost bytes, connections and main-thread time for no return.

Fonts, by shipping fewer weights and subsetting to the characters actually used.

Video, by not autoplaying it, or by replacing a background video with a still image and a play control.

What not to start with: minifying CSS, which is usually a rounding error next to any of the above.

A performance budget is a number the team agrees not to exceed, checked automatically rather than remembered. Without the automatic check it is an aspiration, and weight only moves in one direction.

Express it per resource type rather than as a single total. One number tells you a page grew; four tell you which change caused it, and by how much.

Measure it on a first visit with an empty cache, because that is the visitor whose experience the budget is protecting.

Put the check in the build so a change that exceeds the budget fails before it ships. A dashboard reviewed monthly finds a regression a month after it happened, by which point several other changes have landed on top of it.

Include third-party weight in the budget even though it arrives outside the build, or the one category that grows without a commit is the one nothing watches.

And set the initial number from where the site is now rather than from an ideal. A budget that is already exceeded on the day it is written is ignored by the second week.

`performance.page_weight` reports the total transferred bytes for each crawled page, broken down so the largest contributor is visible rather than inferred.

`performance.heavy_resources` names the individual files large enough to matter, and `performance.request_count` reports how many requests the page makes.

`images.weight`, `performance.javascript` and `performance.fonts` give the per-type totals that turn a number into a decision.

`performance.videos` reports embedded and background video, which is the contributor most likely to dominate a measurement when it is present.