how-to
How to reduce HTML page size (and why it matters for SEO)
A practical guide to shrinking your page's rendered HTML below Google's 2MB Googlebot limit. What to cut first, what's safe to leave, and how to verify the result.
When Google crawls your site, of supported web-search files. Anything after that cutoff might as well not exist, at least for indexing, ranking, or rich result eligibility. We covered the full mechanics in .
Most pages aren't anywhere near 2MB of HTML. But a surprising number of JS-heavy sites are, and they don't know it because (what Google measures) is usually 3 to 10 times larger than the raw HTML you see in view-source. This is the short version of what actually works.
Measure rendered HTML, not source HTML
The single biggest mistake is testing your raw HTML size instead of rendered HTML. They're often wildly different.
Raw HTML is what your server sends. It's what curl or view-source shows. Rendered HTML is what's in the DOM after JavaScript runs, and it's what Googlebot indexes.
If you're a Single Page App or you use client-side hydration, your rendered HTML can balloon from 30KB raw into 800KB rendered. Frameworks like Next.js, Nuxt, and SvelteKit inline serialized state (__NEXT_DATA__, __NUXT__, and friends) directly into the HTML, and that data is part of what Google indexes. The covers where each one hides its bloat.
To see the real number, use or copy the outerHTML of the <html> element from Chrome DevTools and paste it into a character counter.
What's bloating the page (in order of frequency)
Serialized state and hydration payloads
The biggest culprit on modern sites. If your framework serializes the entire page's data into a JSON blob inlined in the HTML, that's HTML weight Google has to read before it sees your actual content.
The fix is to use streaming SSR (Next.js App Router, Remix), partial hydration, or move large datasets to client-side fetches that don't appear in the initial HTML.
Inlined base64 images
Base64-encoded images expand the file by roughly 33% versus the binary equivalent, and they live inside your HTML stream. A handful of base64 thumbnails can add 200KB.
Serve images as external <img> references with loading="lazy". Reserve base64 for tiny critical icons (favicon-sized).
Inlined CSS
Critical CSS inlining is good. All CSS inlined is not. Some build tools ship every utility class straight into the HTML, especially older Tailwind setups without purge configured properly.
Inline only the above-the-fold critical CSS (under about 14KB). Defer the rest with <link rel="stylesheet">.
Comment cruft and whitespace
WordPress sites with multiple plugins routinely ship 50KB of HTML comments. Old e-commerce platforms ship templates indented with tabs at 8 spaces deep.
Enable HTML minification at the build or CDN layer. Cloudflare's Auto Minify or Vercel's edge minification handles this.
Embedded SVGs that should be external
A single complex SVG icon can be 5 to 15KB inlined. Multiply by every icon on the page and the cost adds up.
Use an external sprite sheet (<use href="/icons.svg#chevron">) or icon font for repeated icons. Inline only one-off custom illustrations.
Third-party widget HTML
Live chat, A/B test variants, and personalization tools sometimes inject their own DOM trees at server-side render time. Each injection adds bytes.
Lazy-load third-party widgets after first interaction, or move them to JS-only injection so they don't appear in the initial HTML Googlebot reads.
What's not worth optimizing for size alone
Don't strip Schema.org JSON-LD: the SEO benefit far outweighs the few KB. Open Graph and meta tags are tiny and irrelevant to this conversation. Server-rendered actual page content is the thing you want Google to see, so don't cut it just because it adds weight.
Verify the fix
After each change, re-test the rendered HTML size. A few targets to aim for:
Anything pushing past 1MB is a yellow flag. You're eating into Googlebot's budget and risking content past the cutoff getting ignored. 2MB is a hard stop.
When to stop optimizing
If you're at 400KB of rendered HTML on a content-rich page, you're already in great shape. Going from 400KB to 200KB has almost no SEO impact. Going from 1.8MB to 800KB is critical: that's the difference between "fully indexed" and "Google never saw the bottom of your page."
Test your most important pages first. The homepage and your top organic landing pages are where this matters most.
Check your page size now
Test any URL against Google's 2MB Googlebot HTML limit in seconds.
Run a check
