Page weight is not a ranking factor. It is something better and worse than that: it is the input to several things that are. Largest Contentful Paint, Interaction to Next Paint and the bounce behaviour Google observes are all downstream of how many bytes have to arrive before your page becomes useful.
The median web page has roughly quadrupled in weight over the last decade while typical mobile connection speeds have not. This piece is about what to measure, what the numbers mean, and what to do about them. The Page Size Checker gives you the figures.
What weight actually costs you
Three separate costs, and they compound.
- Rendering speed. Largest Contentful Paint measures when the main content appears. On a heavy page that is gated behind downloading and parsing a large amount of CSS and JavaScript first, no amount of server tuning rescues it.
- Abandonment. Every additional second before the page appears increases the share of visitors who leave. Those visitors never enter your funnel, never read the article and never see the offer.
- Crawl efficiency. Slow responses cause Google to lower its own crawl rate to avoid overloading your server, which means fewer pages fetched per visit. This ties directly into crawl waste.
It is worth being precise about the mechanism, because “Google penalises slow sites” is a slogan that leads people to optimise the wrong thing. Nothing is deducted. Slow pages simply perform worse on the metrics that are measured, and lose visitors before those metrics matter.
Benchmarks worth measuring against
There is no universal threshold, but these bands hold up across most content sites.
- Under 500 KB. Light. Loads comfortably on a mid-range phone over a normal mobile connection. A text-led article has no excuse to exceed this.
- 500 KB to 1.5 MB. Typical for a modern content page with images. Workable, and almost always containing a few hundred kilobytes you could remove without anyone noticing.
- 1.5 MB to 3 MB. Heavy. You are measurably losing visitors on slower connections, and your Core Web Vitals are unlikely to be in the green.
- Above 3 MB. Something is wrong rather than merely unoptimised — usually one unresized image, or a third-party script loading an entire second application.
The more useful comparison is not against a band but against the pages you compete with. Measure three competitors ranking for your target query. If they are all half your weight, that is a concrete gap; if they are all heavier, weight is not what is holding you back.
Where the bytes always hide
Images, first and by a distance
A single unoptimised hero photograph routinely outweighs every other asset on the page combined. Three fixes, in order of payoff: size images to the width they actually display at rather than shipping a 4,000-pixel original, serve a modern format such as WebP or AVIF, and lazy-load everything below the fold. Together these commonly halve total page weight without any visible change.
Third-party scripts, second
Analytics, chat widgets, consent managers, A/B testing, ad tags. Each looks small in the network panel and each loads more code of its own once it runs. They are also the assets over which you have the least control, since a vendor can triple their bundle without telling you. Audit the list annually and remove anything nobody has looked at in six months.
Your own CSS and JavaScript, third
Most sites ship one stylesheet containing every rule the site could ever need on every page, and a JavaScript bundle containing framework code that particular page never calls. Splitting by route is real work, but it is work with a predictable return.
Reading the checker output honestly
Our checker fetches the page server-side, because browsers refuse to read pages on other domains, and then asks each referenced asset how large it is. Three limits are worth knowing, because they all push the number down rather than up.
- It measures assets referenced in the initial HTML. Anything injected later by JavaScript — which on script-heavy sites is a great deal — is not counted.
- It samples very asset-heavy pages to keep the check fast, and tells you when it has done so.
- It reports the size the server declares. Assets served without a content-length header are skipped rather than guessed at.
So treat the total as a solid floor, not an exact figure. If the floor is already above 1.5 MB, you have your answer and do not need a more precise measurement to start work. For a full waterfall with compression and timing, use WebPageTest or your browser’s network panel.
The response headers shown alongside are often the quicker win. A missing content-encoding means text assets are not being compressed, which is usually a one-line server change worth 60 to 80 per cent of their size. A missing or very short cache-control means repeat visitors re-download everything.
A short order of work
- Measure your three heaviest template types — home, an article, a product or category page. Do not average; find the worst.
- Fix the largest single asset first. It is nearly always an image, and it is nearly always faster to fix than everything else combined.
- Turn on compression and set sensible cache headers if the response headers say they are missing.
- Audit third-party scripts and remove the ones nobody can name an owner for.
- Re-measure, and check Core Web Vitals in Search Console four weeks later, since that data is collected from real visitors over a rolling window.
One thing not to do: block heavy pages in robots.txt as a shortcut. Blocking changes what gets crawled, not what your visitors download, and it has its own consequences — Robots.txt Generator: Writing Rules Crawlers Actually Follow covers why that trade rarely works out.