Hreflang Tag Generator
Build the hreflang set for a page, with return links checked.
Weigh a page's HTML and see what is taking up the room.
The Page Size Analyzer weighs a pasted HTML document and splits it into markup, inline CSS, inline script, comments and readable text, with element counts, nesting depth and the text-to-code ratio. It measures the document itself rather than the whole page load, because that is the part with its own specific cost.
Paste a page and the analyser weighs the HTML document itself, breaking it down into the markup, the inline styles, the inline scripts, the comments and the actual readable text. It counts the elements, measures the nesting depth and works out the text-to-code ratio.
This measures the HTML document, not the whole page load — images, stylesheets and scripts fetched from elsewhere are separate requests and are listed rather than weighed. That distinction matters because HTML bloat has its own specific cost: a huge document delays the first paint even on a fast connection, and Google's crawler has a budget of bytes as well as requests. The usual culprits are a page builder's nested wrapper divs, an inline critical-CSS block that grew, and base64 images pasted directly into the markup, all of which this shows you the size of.
Markup, inline CSS, inline JS, comments and text weighed separately rather than as one number.
The biggest inline style and script blocks are shown with their sizes, so you know what to move out.
Deep wrapper nesting is the usual cause of a bloated document, and the depth is measured.
Images pasted into the markup as data URIs are found and weighed, since they are often the whole problem.
An indication of what gzip would leave, because that is what actually crosses the wire.
The full HTML document, exactly as the server sends it.
Markup, inline CSS, inline JS, comments and text are weighed separately.
The text-to-code ratio tells you how much of the document is actually content.
The largest inline blocks and the deepest nesting are listed so you know where to cut.
Most well-built pages land between 30KB and 100KB before compression. Past a few hundred kilobytes you are usually looking at inline base64 images, a page builder's wrapper divs, or a critical-CSS block that stopped being critical.
No — only the HTML document. Images, stylesheets, fonts and scripts are separate requests, so they are listed but not weighed. For total page weight you need the page loaded in a browser with its network panel open.
It is the share of the document that is readable text rather than markup. It is not a ranking factor and never was, but a very low ratio is a reliable symptom of something worth looking at — usually deeply nested wrappers or a large inline block.
It helps a little, and gzip or brotli compression helps far more — most of what minification removes compresses to almost nothing anyway. Enable compression first; minify afterwards if you still need the bytes.
What people who use the Page Size Analyzer think of it. Reviews come from visitors and are posted as written.
No ratings yet
Yours would be the first.
0 reviews
Newest first
No reviews yet
Be the first to rate the Page Size Analyzer. It takes half a minute and no account.
Write the first reviewBuild the hreflang set for a page, with return links checked.
Cross three lists of words into every combination.
Compare two pages and find the passages they share.
Remove comments and whitespace without breaking your code.
Check where a keyword appears on a page, not just how often.
Check which URLs your robots.txt actually allows and blocks.
See the anchor text profile of a page, grouped and ranked.
Turn a list of old and new URLs into Apache redirect rules.