Skip to main content

Home / Tools / Page Weight Analyzer

Free page weight analyzer

See how many bytes a page really ships — HTML plus its scripts, stylesheets, images and fonts, with the heaviest assets ranked and third-party origins flagged.

Fetches the HTML and samples up to 30 of its assets — can take ~15 seconds.

What this tool checks

The analyzer fetches the page, measures the HTML itself, then reads every <script src>, <link rel="stylesheet">, <img> and preloaded font it references. Each asset is sized with a lightweight HEAD request — falling back to a GET whose body is immediately cancelled when a CDN refuses HEAD — so nothing large is actually downloaded. It asks servers for the uncompressed representation, so the figures are pre-gzip bytes — the weight the browser must decode, parse and execute rather than the weight on the wire. The whole run is capped at 30 outbound requests, the same budget the broken-link checker uses, which keeps it polite to your server and fast for you. Every asset URL is revalidated before it is fetched, and redirects are never followed automatically.

The output is deliberately honest about its own limits: assets beyond the sample are reported as a count rather than silently dropped, and anything that arrives without a content-length header is listed as unmeasured instead of being scored as zero.

Why page weight is still the thing to fix

Almost every slow page is slow for the same boring reason: it sends too much. Framework bundles that were never code-split, an icon font shipping thousands of glyphs to use six, a hero image exported at 4000px and displayed at 800, four analytics tags that each pull in their own library. None of it is a bug, and none of it shows up in a functional test — the page works perfectly, it just costs the visitor three seconds and a chunk of their data plan.

Weight maps onto Core Web Vitals directly. An oversized hero image is usually the LCP element, so its transfer time is your LCP. Render-blocking CSS in the head delays first paint for everyone. Large scripts monopolise the main thread, which is what turns a tap into a sluggish INP score. Fonts loaded without font-display hold text invisible or swap it late, contributing to layout shift.

How to fix what you find

Images: serve modern formats (AVIF/WebP), size them to their actual display width with srcset, and lazy-load anything below the fold — this is usually the single biggest win and needs no build-system changes. JavaScript: look for one dominant bundle in the list above and split it, or find the library you are using one function from. Defer anything not needed for first paint. CSS: if a single stylesheet is hundreds of kilobytes you are almost certainly shipping a whole framework to style one layout; purge unused rules. Fonts: subset to the characters you use, self-host to avoid an extra connection, and set font-display: swap. Third parties: audit them ruthlessly — every tag should have someone who can say what it is for. Once the obvious weight is gone, run a full audit to see what the change did to real Core Web Vitals rather than to byte counts alone.

Frequently asked questions

How accurate is the total?

Treat it as a floor, not a browser-accurate transfer size. The tool reads each asset’s content-length header rather than downloading it, and asks for the uncompressed representation — so the figures are pre-gzip bytes, which is what the browser actually has to parse. It samples the first 30 resources and cannot see anything a script injects after load. Anything served without a content-length is listed as "unknown" rather than counted as zero.

What is a reasonable page weight?

The pragmatic target is under 1 MB for a content page and under 300 KB of JavaScript, because that is roughly what a mid-range phone on a real mobile connection can parse and execute without visibly stalling. The median page on the web is several times that, which is why "it feels fine on my laptop" is such a misleading test.

Why does JavaScript matter more than images of the same size?

Bytes are not equal. An image downloads on a background thread and decodes off the main thread; a JavaScript bundle of the same size must be downloaded, parsed, compiled and executed on the one thread that also handles rendering and input. That is why script weight shows up in INP and blocking time while image weight mostly shows up in LCP.

It says some assets are third-party — is that bad?

Not automatically, but each extra origin costs a DNS lookup, a TCP connection and a TLS handshake before a single byte arrives, and you do not control when that origin gets slow. Third-party tags are the usual reason a page that is fast in the lab is slow in the field.

How is this different from a Lighthouse run?

This is a static measurement of what the HTML references, with no browser involved — fast, and enough to spot an obviously bloated page. Lighthouse actually renders the page, so it sees runtime-injected requests, execution cost and the resulting Core Web Vitals. Use this to triage, then run a full audit for the real numbers.

Want the full picture?

This tool checks one thing. A full RankVitals audit runs a Lighthouse speed test plus 50+ SEO and AI-readiness checks on your whole site — free, no signup.

Run a full site audit →