Page Size Too Large: How to Fix It

HTML page size too large: finding what bloats your WordPress markup

A page size warning here means the HTML document itself is very large, over 3 MB, before counting the images, scripts and stylesheets it loads separately. Typical HTML for a content page is a small fraction of that, so a page this heavy almost always has something embedded in the markup that should not be there: inline images, huge blocks of inline data, or thousands of nested elements from a page builder.

Large HTML slows every visit, because the browser must download and parse it before it can show much, and it is costly on mobile connections. Google only processes the first 15 MB of an HTML file, so extreme cases can even cut off content. The audit reports over 2 MB as an optimization, over 3 MB as a warning and over 5 MB as critical.

Updated September 30, 2026By the Hydrogen SEO team

What it looks like in the HTML

Before

html

<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAB4AAAAQ4CAYAAADo08FDAAAgAElEQVR4nOzd... (2 MB of text)">

After

html

<img src="/wp-content/uploads/cold-brew-hero.webp" width="1200" height="630"
     alt="Cold brew in a glass jar" loading="lazy">

Why it matters

The HTML is the first thing the browser needs, and nothing else starts until enough of it has arrived. Images and scripts referenced by URL can be cached, compressed separately and loaded in parallel. Anything embedded directly in the HTML cannot be cached on its own and has to be downloaded again on every page view.

Very large documents also take longer to parse and produce a huge DOM, which makes the page slower to respond to taps and clicks. This hurts Largest Contentful Paint and Interaction to Next Paint, and it hurts most on the phones where most visitors are.

What bloats WordPress HTML

Base64 images. Images pasted directly into the editor from another app, or embedded by some plugins, can end up as data: URIs inside the HTML, each one far larger than the original file.
Inline SVG and icon sprites. A theme that inlines a full icon library on every page, or large SVG illustrations in the markup.
Inline data blobs. WooCommerce variable products with many variations embed variation data in the page; so do some sliders, maps, filters and analytics tools that print large JSON objects.
Page builder markup. Deeply nested sections, columns and wrappers, repeated for each device breakpoint, can multiply the element count.
Everything on one page. Archive or shop pages that show hundreds of items without pagination, or long pages with many embedded galleries.
Inline CSS. Critical CSS or builder styles printed in full into every page.

How to fix it in WordPress

Find what is big. Save the page's HTML (view source, then save) and open it in a text editor, or look at the document request's size in the developer tools Network tab. Search for data:image, <svg and long <script> blocks. The largest blocks usually give away the plugin or block responsible.
Replace inline images with uploads. Upload images to the Media Library and insert them normally, so they load as files that can be cached, resized and lazy-loaded.
Paginate long lists. Set a sensible number of posts per page under Settings → Reading, and a products-per-page limit in your shop settings.
Tame product variation data. For WooCommerce products with many variations, WooCommerce loads variations with AJAX above a threshold; lowering it with the woocommerce_ajax_variation_threshold filter keeps the data out of the HTML.
Simplify builder layouts. Remove empty sections and redundant wrappers, and avoid duplicating whole sections for mobile and desktop.
Check plugins that print inline data. Deactivate suspects on a staging copy and compare the HTML size.
Make sure compression is on. Gzip or Brotli compression shrinks HTML a lot on the wire. It does not fix the underlying bloat, but it cuts transfer size. Hydrogen SEO's site health score checks compression under Performance.

Hydrogen SEO itself adds only its meta tags and JSON-LD to the page, and no front-end JavaScript.

How to check the fix

Reload the page with the developer tools Network tab open and read the size of the document request, both transferred (compressed) and resource (uncompressed) size. Run Lighthouse to see whether DOM size is flagged. Rerun the free SEO audit, which reports the HTML size in KB.

Common questions

Does this include images and scripts?

No. This check measures the HTML document only. Images, CSS and JavaScript loaded by URL are separate files, so a large result means something heavy is embedded in the markup itself.

What is a normal HTML size?

It varies, but most content pages are well under a few hundred KB of HTML. Anything in the megabytes is unusual and worth investigating.

Is there a size limit for Google?

Googlebot processes the first 15 MB of an HTML file. Pages rarely reach that, but content past the limit would not be considered.