The fix, in one snippet
curl -s https://example.com/ | wc -c
curl -s https://example.com/ | grep -o 'data:image[^"]\{0,40\}' | wc -lIllustrative values. Change the paths, hostnames and options to match your own site before using it.
The sections below explain what is tested, why it matters and the alternatives.
What we test
We measure the size of the HTML document alone, before images, scripts or stylesheets, and report pages over 2.5 MB. The figure is the transferred body as received.
Large HTML is unusual and almost always accidental: an entire catalogue inlined into a listing page, a base64 image embedded in the markup, or a server-rendered application state blob attached to the document.
Why it matters
HTML is render-blocking by definition: nothing appears until enough of it has arrived and been parsed. A multi-megabyte document on a mobile connection delays first paint by seconds, and Core Web Vitals measure exactly that delay.
Crawlers also have limits. Google has historically truncated very large documents, which means content near the end of an oversized page may never be indexed at all, and links there may never be discovered.
Because the size is in the HTML rather than in assets, the usual optimisations, lazy loading and CDNs, do not touch it. A CDN serves the same oversized document faster; it does not make it smaller, and the parse cost on a low-end phone remains.
The parse itself is the part most often forgotten. A browser has to build a DOM node for every element in the document before it can lay anything out, and on a mid-range Android device that work is measured in seconds for documents of this size.
How to fix it
Find what is actually in the document before changing anything:
curl -s https://example.com/page | wc -c
curl -s https://example.com/page | grep -o 'data:image[^"]\{0,60\}' | wc -lMove base64 images out to real files. Paginate listings that render thousands of rows. Trim server-rendered state to what the client actually needs rather than serialising the whole model. Enable compression so what is left transfers as a fraction of its size.
Where this fits
Oversized HTML documents is check 2 of 3 that the seo & site health audit runs under images and page weight, ordered the way they are worth fixing. That ordering is the point: Fixing this one while the check above it still fails buys less than it looks like.
Fix this one first
Above it in the same category sits Images without alt text (medium), where alt text is what a screen reader announces and what an image search engine reads. An attacker who has that does not need this, so it is the better use of the same hour.
What fixing this still leaves open
Oversized HTML documents closes one route in. The next one down is Images not lazy-loaded, where images below the fold that load immediately compete for bandwidth with the content the reader can actually see.
Found in the same scan
The seo & site health audit reports this alongside checks from other categories that are at least as serious, including Broken internal links, where an internal link that returns an error is a dead end for the reader and a wasted request for the crawler, and Crawl errors (4xx / 5xx), where uRLs reached during the crawl that returned a client or server error. A single run of seo & site health audit answers all of them at once.
The first few lines
You are a senior web engineer. I ran a security and SEO scanner against my site and it reported the finding below. Fix it properly rather than suppressing the symptom.
Finding: Oversized HTML documents (medium severity)
Scanner check id: seo-page-weightThe rest of this prompt names the pages and line numbers we found the problem on, the configuration to change, and the constraints a good answer has to respect. It is free, it just needs an account so the work is not scraped wholesale.
Sign in with GoogleSigning in is free and takes one click. We store your email address and nothing else.