You're looking at a page that takes 6 seconds to load on mobile. You check the waterfall. The HTML document itself is 4.2MB. Not the images. Not the JavaScript. The raw HTML response.
How does HTML get that big? Inline SVGs duplicated 30 times. Base64-encoded images embedded in the markup. Server-side rendered component trees with 15 levels of nested divs. CMS plugins that inject 200KB of configuration JSON into every page. It adds up faster than you'd think, and nobody notices until mobile users on metered connections start bouncing.
What "page weight" actually means
Page weight is the total transfer size of all resources needed to render a page: HTML, CSS, JavaScript, images, fonts, media. But the HTML document itself matters more than most people realize because it's the first resource in the loading chain. Nothing else can start until the browser receives and parses enough HTML to discover the other resources.
A 4MB HTML document on a 4G connection (median throughput: ~15 Mbps) takes about 2.1 seconds just to download. Add parsing time, and you've spent 2.5+ seconds before a single CSS file or image starts loading. On 3G (median: ~1.5 Mbps), that same document takes 21 seconds to download.
The HTTP Archive's 2024 data shows the median HTML transfer size is about 30KB compressed. Pages at the 90th percentile hit 120KB. Pages at the 99th percentile exceed 1MB. If your HTML is over 200KB compressed, you're in the heaviest 5% of the web.
Where the bloat comes from
Inline SVG duplication. Every icon rendered as an inline SVG adds its full definition to the HTML. A 3KB icon used 40 times across the page adds 120KB of raw HTML. The fix: use an SVG sprite sheet with <use> references, or switch to an icon font.
Base64-encoded images. Embedding images as base64 data URIs inflates the HTML by ~33% versus the binary original (base64 encoding overhead). A 50KB image becomes 67KB of inline text. Multiply by the number of thumbnails on a product listing page.
Server-rendered component bloat. React, Vue, and Angular server-side rendering can produce deeply nested DOM structures with extensive data-* attributes for hydration. A component tree with 15 levels of wrapper divs, each with multiple class names and data attributes, generates far more HTML than the visual output justifies.
CMS plugin injection. WordPress plugins, Shopify apps, and similar CMS extensions inject configuration, tracking, and initialization data into the HTML. Five analytics plugins, three A/B testing tools, and a personalization engine can add 500KB+ of inline JSON before the page content even starts.
Unminified HTML. Comments, whitespace, and formatting in production HTML add 10-15% to the transfer size. Most build tools strip this automatically, but CMS-driven sites often ship unminified.
Setting a budget
A practical response size budget for HTML:
- Under 100KB compressed: Good. Most content pages should hit this.
- 100-250KB compressed: Acceptable for data-heavy pages (dashboards, catalogs).
- Over 250KB compressed: Investigate. Something is generating unnecessary bulk.
- Over 1MB compressed: Fix immediately. This is actively harming mobile users.
These are compressed sizes (after gzip or Brotli). The uncompressed size matters for parsing time, but the compressed size determines download duration, which usually dominates on slow connections.
What the tool checks
The Response Size Budget Audit fetches your page and reports:
- HTML transfer size (compressed) and document size (uncompressed)
- Total page weight across all resource types
- Resource breakdown: HTML, CSS, JS, images, fonts, other
- Which resources exceed their type-specific budget
- Inline content analysis: base64 images, inline SVGs, inline scripts/styles by size
The tool flags specific bloat sources and generates a remediation prompt with actionable steps for the largest contributors.
Quick wins
Move base64 images to external files. Convert data URIs back to regular <img> tags pointing to optimized WebP files. Saves ~33% per image on HTML size, and the images become independently cacheable.
Deduplicate inline SVGs. Extract repeated SVGs into a sprite sheet. Reference with <svg><use href="#icon-name"/></svg>. Reduces HTML by the duplicate count minus one.
Enable HTML minification. Most build tools (Eleventy, Next.js, Hugo) have an HTML minification option. For WordPress, plugins like Autoptimize handle it.
Audit CMS plugin output. Disable plugins one at a time and measure HTML size. You'll find the offenders quickly. The typical pattern: a plugin that was "just trying out" six months ago is still injecting 80KB of JavaScript configuration into every page.
For small business owners who need their sites to work on every device and every connection speed, The $20 Dollar Agency ($9.99 on Kindle) covers the lean infrastructure approach that keeps pages fast without a large engineering team.
Fact-check notes and sources
- HTTP Archive median HTML size: HTTP Archive, State of the Web
- 4G median throughput: OpenSignal, The State of Mobile Network Experience
- Base64 encoding overhead (~33%): RFC 4648, Section 6
- HTML parsing performance: web.dev, Critical rendering path
Related reading
- Compression codec audit — Brotli vs gzip transfer savings
- CrUX field data — real-user load time metrics
- Critical CSS audit — reducing render-blocking CSS weight
- Remote dependency audit — third-party resource weight
- Edge cache audit — caching for repeat visitors
This post is informational, not performance-consulting advice. Tool mentions are descriptive. No affiliation with browser vendors or CMS platforms is implied.
