Every page has a real, addable-up cost before a visitor sees anything on it: the HTML, plus every stylesheet, script, image and font it loads. That total — page weight — is what a slow connection actually has to move before the page finishes loading. The checker above fetches a page the way a browser would and adds up exactly what it asked for.

Where the thresholds come from

Lighthouse — the auditing engine behind Chrome DevTools and Google’s PageSpeed Insights — has a specific audit called “Avoid enormous network payloads” that fails a page outright past 5MB, and calls out anything over roughly 1.6MB as worth trimming. Those are the two thresholds this checker grades against — not arbitrary numbers, the same ones a Lighthouse report itself would flag.

What almost always turns out to be the problem

• Images, nearly every time. A single unoptimized photo can outweigh every script and stylesheet on the page combined — see the Broken Image Checker for a per-image view, including which ones are already over 500KB.
• Web fonts loaded in every weight and style when only two or three are actually used on the page.
• A script bundle that grew as features were added, without anyone revisiting whether all of it is still needed on every page that loads it.
• Third-party embeds — a chat widget, an analytics script, a font from an external host — each one a full additional request this page didn’t control the size of.

Why this matters beyond just speed

Page weight and load time aren’t the same measurement, but they’re closely linked — more bytes generally means more time before the page is usable, especially on mobile connections. Google has used page experience signals in ranking since 2021, and a visitor decides whether to stay within seconds regardless of what any algorithm rewards. A lighter page is a page more people actually finish loading.

Frequently asked

Does this measure the same thing as Google PageSpeed Insights?

It measures total transferred bytes, which PageSpeed Insights also reports — but PSI additionally measures real rendering timing (First Contentful Paint, Largest Contentful Paint) using a headless browser, which this tool doesn’t attempt. Page weight is one input to load time, not the whole picture.

Why doesn’t the total match what I see in Chrome DevTools?

DevTools’ Network tab counts every request a full browser session makes, including ones added by JavaScript after the page loads, XHR/fetch calls, and anything a service worker intercepts. This checker reads only what the initial HTML directly references — a close approximation for most pages, not a byte-for-byte match for heavily dynamic ones.

What counts as “too many requests”?

Past roughly 80 requests, the connection and round-trip overhead itself becomes a meaningful part of load time, independent of the total bytes — bundling and combining resources helps here even when the total weight doesn’t change much.