HTML Page Size Test
The HTML Page Size Test measures the raw and compressed bytes of the HTML document returned by any URL — separate from the images, scripts and stylesheets it pulls in.
- Results in seconds
- Pass / fail + fix guidance
- No account required
The HTML Page Size Test measures the raw and compressed bytes of the HTML document returned by any URL — separate from the images, scripts and stylesheets it pulls in. Bloated HTML is a hidden performance cost: large initial HTML increases Time to First Byte and First Contentful Paint, and on JavaScript-rendered pages it often signals huge inline JSON payloads from server-side data hydration.
What This Tool Checks
- Raw HTML bytes (uncompressed)
- Compressed HTML bytes (gzip / Brotli)
- Compression ratio achieved
- Inline data / JSON payload size
- Inline CSS and JavaScript bytes
- Comments and whitespace overhead
Why It Matters for SEO
Every byte of HTML is on the critical render path. Large HTML pushes back TTFB, FCP, LCP and Speed Index simultaneously. JavaScript-rendered apps frequently inline 100+ KB of JSON for client hydration — invisible to most page-weight tools but very visible to Lighthouse and to user load times. Trimming inline data, splitting hydration payloads and removing comments / whitespace are usually low-effort, high-impact fixes.
How to Fix It
Enable Brotli compression at the origin. Split inline JSON payloads — only ship what is needed for above-the-fold render and lazy-load the rest. Move inline CSS / JS to external files where they can be cached across pages. Strip comments and whitespace in production builds. Aim for under 50 KB compressed HTML on most page templates.
How It Works
We fetch the URL's HTML, measure the raw and on-the-wire compressed bytes, then break the payload into structural HTML, inline CSS, inline JavaScript, inline JSON / data and comments. Each category is reported with reduction recommendations.
Common Mistakes to Avoid
- Inlining the entire dataset on first request when most is below the fold
- Server-side rendering pages with no compression at the origin
- Leaving dev-mode comments and whitespace in production HTML
- Inlining large CSS / JS that should be external and cacheable
- Returning the same large HTML for every paginated URL variant
Quick Checklist
- Compressed HTML under 50 KB on most templates
- Brotli or gzip enabled at origin
- No huge inline JSON payloads
- Inline CSS / JS minimised
- Comments and whitespace stripped in production
Put your whole site on autopilot — SEO and AI search
PositionMySite monitors every signal on this page across your entire website 24/7 — plus keyword rankings, competitor moves and AI-search readiness (llms.txt, schema, ChatGPT & Gemini visibility). When something breaks, you know before Google does.
Every feature unlocked · No commitment · Cancel anytimeFrequently Asked Questions
Compressed HTML under 50 KB is a healthy target for most templates. Above 100 KB signals bloat — usually inline data, unminified inline scripts, or missing compression.
Not inherently — most SSR frameworks rely on it for hydration. The mistake is inlining more than the page needs above the fold. Split the payload and lazy-load the rest.
Indirectly but consistently. Larger HTML increases TTFB, FCP, LCP and Speed Index. All four feed Lighthouse scoring and Core Web Vitals; smaller HTML almost always means faster paint metrics.
Yes, in production builds. Minification removes comments and unnecessary whitespace and typically saves 5-15% bytes. Combine with gzip / Brotli compression for the biggest impact.
Audit what is actually used above the fold. Move below-the-fold data to a lazy fetch. For React / Next.js pages, route-based code splitting and React Server Components can dramatically cut hydration payload.