Large HTML document: how it slows your page
An oversized HTML document slows loading and hurts Core Web Vitals. Find your heaviest pages and learn how to trim page weight for speed.
What it means
A page's HTML source is larger than expected, usually because the server sends too many characters, bytes, or kilobytes in the initial document. This can come from bloated inline styles, embedded SVGs, long text blocks, or excessive markup that doesn't need to be there.
Why it matters
Larger HTML increases the time to first meaningful paint and pushes the Largest Contentful Paint later, which directly affects Core Web Vitals. It also means more bytes to download and parse before Googlebot can render the page, and more data for AI agents to process when extracting structured content.
How to fix it
- Inline critical CSS and defer non-critical styles to reduce the initial HTML size.
- Replace large inline SVGs with external files or sprite sheets.
- Remove redundant whitespace, comments, and inline attributes from the markup.
- Use SSR or SSG to pre-render content instead of sending empty shells that JS fills in.
Example
<!-- 2.6 MiB of HTML: full product catalog inlined into every page -->
<body>
...12,000 product <div>s rendered server-side on the homepage...
</body><!-- 180 KiB: only above-the-fold markup; the rest is paginated/fetched -->
<body>
...first 24 products...
<a href="/products?page=2" rel="next">More products</a>
</body>Trim the document to what the page actually needs. Paginate long lists, move data-heavy tables behind their own URLs, and strip inlined base64 blobs.
When it's not a problem
If the content is genuinely dense and valuable — a long-form article with real text — a larger HTML document is acceptable. The issue only matters when the size comes from unnecessary markup, not from the content itself.
How Crawlinx detects it
We measure the transferred size of the HTML document body. When it exceeds 2 MiB the page is flagged; the finding reports the exact size. This is document weight only, not the total page weight including images and scripts.
How common is it?
1234 audited sites in our corpus currently show this issue. The breakdowns below show which platforms, gatekeepers, verticals and countries are most exposed.
FAQ
- How big is too big for an HTML document?
- There's no hard Google limit, but past ~2 MiB the parser and network cost start hurting LCP and INP noticeably. Most well-built pages sit well under 500 KiB of HTML.
- What usually bloats the HTML?
- Inlined base64 images or SVGs, giant server-rendered lists/tables, repeated boilerplate, and inline JSON state dumps. Move large data behind its own endpoint and lazy-load it.
- Does Google truncate large pages?
- Historically Googlebot indexed roughly the first several hundred KB to a couple of MB of a document. Content buried far down an oversized HTML file risks not being indexed at all.
Related guides
Audit your own site — free
157 checks, internal PageRank, render-diff. No signup, results in ~30s.