HTML Page Size Test

What is it?

The raw HTML document is the first response your server returns, before any images, CSS, JavaScript, or other linked resources are counted. A bloated HTML response increases time to first byte, slows parsing, and stalls rendering on mobile networks and lower-powered devices, all of which feed directly into Core Web Vitals scores and search rankings. This test measures the size of the HTML response for the page being checked so you can decide whether trimming the markup is worth the effort.

Why HTML size still matters

Most performance optimization advice focuses on images and JavaScript, which are usually the biggest assets, but HTML itself is the request that has to complete before anything else can begin. A 500 KB HTML response on a slow connection can delay first paint by seconds even if every other asset is perfectly optimized. Keeping the HTML lean is therefore an under-appreciated lever for improving overall page speed.

Bloated HTML usually traces to a few common culprits: large inline base64 images or fonts, oversized JSON or state blobs serialized into the page on first render, repeating boilerplate that should be extracted to a shared template, or CMS plugins that emit verbose configuration into the markup. Each of these can be addressed independently, often without any user-visible change to the page.

Common causes of HTML bloat

Inline base64 images or fonts that should live in external files so they can cache.
Large server-side JSON or state payloads serialized on every request, where streaming or lazy-fetching would do the job.
Repeating boilerplate: the same script tags, structured data, or layout markup duplicated across templates.
Excessive inline CSS or JavaScript, where only the truly critical CSS belongs inline.
HTML compression disabled, missing the easy 60 to 80 percent reduction Brotli or Gzip would provide on text content.

This test reports the size of your HTML response so you can decide whether trimming is worthwhile. The fix guide below walks through identifying the heaviest sections of the markup, common refactoring patterns, and confirming that compression is enabled at the server or CDN.

Pass rate:

Top 100 websites: 23%
This value indicates the percent of top 100 most visited websites in the US that pass this test (in the past 12 months).
All websites: 56%
This value indicates the percent of all websites analyzed in SEO Site Checkup (500,000+) in the past 12 months.

Pass rates of Top 100 US websites
2021	34%
2022	17%
2023	21%
2024	23%

100

How do I fix it?

This test fails when the raw HTML document weighs significantly more than necessary, even before counting images, CSS, or JavaScript. Bloated HTML increases time to first byte, slows parsing, and stalls rendering on mobile networks and lower-powered devices. Fixing this issue means trimming inline data, removing legacy markup, and keeping the document focused on what the user needs.

Where to make the change

Application code or templates: identify which sections produce the most bytes (often a large inline JSON blob, an inline base64 image, or a giant comment block) and refactor them to load externally or be removed.
WordPress: check for plugins or page builders that emit large inline configurations. Disable unused plugins and prefer themes that ship clean markup.
Shopify: theme code may inline large product or section JSON. Move heavy data to a fetch-on-demand endpoint when possible.
Headless or framework sites: review the rendered output for serialized state (for example __NEXT_DATA__ in Next.js) and trim what is sent on first paint by streaming or lazy-loading non-critical chunks.

Common causes and how to resolve them

Inline base64 images or fonts: move them to external files so the browser can cache them across requests.
Excessive inline CSS or JavaScript: link to external stylesheets and scripts so they cache. Inline only the truly critical CSS for above-the-fold content.
Large server-side JSON payloads: ship only the data needed for first render. Fetch the rest on demand.
Repeating boilerplate or commented-out code: strip comments and dead code in the production build.
HTML compression disabled: Gzip or Brotli compression often shrinks the response by half or more. Confirm the server sends the appropriate Content-Encoding header.

Best practices

Aim for under 100 KB of HTML: most pages can comfortably stay under this. Anything beyond a few hundred KB usually indicates structural bloat worth refactoring.
Enable compression: Gzip is the safe minimum, Brotli is even better for HTML and other text formats.
Defer non-critical content: rendering only what is needed for the initial viewport keeps both bytes and parse time down.
Audit periodically: add HTML size to your performance budget so regressions get caught in CI.