pagesizechecker.com

Page Size Checker

Test any URL's rendered HTML size against Google's 2MB Googlebot indexing limit.

Check your page size in seconds

Paste a URL and we'll tell you if the page is under Googlebot's 2MB HTML limit.

How this Page Size Checker works

We load your URL in a real headless browser, wait for JavaScript to execute, then measure the size of the rendered DOM in uncompressed bytes. That number is what Googlebot reads for indexing, and it's usually 3 to 10 times larger than the raw HTML you see in view-source.

Paste a page URL.
We load the page with Cloudflare Browser Rendering and let JS run.
We count the rendered HTML bytes and compare to Google's 2MB limit.
You get a clear result: Pass, Warning, or Over Limit, with a recommendation.

What counts toward the 2MB limit

Google measures the rendered HTML (the DOM after JavaScript runs), not the raw HTML your server sends. Compressed transfer size doesn't matter; only the uncompressed byte count does.

Counts toward 2MB

HTML markup, attributes, and text
Inlined <style> and <script> blocks
Serialized state (e.g. __NEXT_DATA__)
Base64 data: URI images
Inlined SVG, JSON-LD, comments, whitespace
Hidden DOM (display:none still counts)

Doesn't count

External CSS files
External JavaScript files (their output counts once executed)
Images referenced via <img src>
External SVGs via <use href>
HTTP response headers
Resources blocked by robots.txt

Typical HTML sizes by page type

Use these as rough benchmarks for what's healthy. If you're well above the typical range for your site type, there's probably bloat to trim.

Page type	Typical rendered HTML	Notes
Marketing / landing page	50–200 KB	Mostly static content with hero imagery
Blog post	80–250 KB	Article body plus comments widget
News article	150–400 KB	Article + related stories + ads
E-commerce product page	200–500 KB	Product data, reviews, recommendations
E-commerce category page	300–800 KB	Many products + filters
Single Page App route	400 KB–1.2 MB	Watch for serialized state bloat
Anything over 2 MB	FAIL	Content past 2 MB won't be indexed

How to reduce HTML page size

The fastest wins on bloated pages, in roughly the order most teams should address them.

Trim serialized state

Frameworks like Next.js inline data as JSON in the HTML. Move large datasets to client-side fetches that don't appear in the initial render.

Replace base64 images

Inlined base64 images are ~33% larger than binary and live in your HTML stream. Use external <img> with lazy loading instead.

Defer non-critical CSS

Inline only the critical above-the-fold CSS (< 14 KB). Load the rest with normal <link rel="stylesheet">.

Minify HTML

Old WordPress sites and legacy templates ship tens of KB of comments and whitespace. Enable minification at the build or CDN layer.

Lazy-load third-party widgets

Live chat, A/B test scripts, and personalization tools can inject DOM at SSR time. Defer them until after first interaction.

Externalize repeated SVGs

Inlined SVG icons add up fast. Use a sprite sheet (<use href="/icons.svg#chevron">) for icons that appear more than once.

For the full breakdown, read the complete guide.

Why this matters for SEO

Anything past the 2MB cutoff is invisible to Google. Concretely, that means:

Content past 2MB isn't indexed. If your article body, product details, or pricing table sit below the cutoff, they can't appear in search results.
Schema markup may not parse. JSON-LD placed late in the HTML can fall past the cutoff, breaking rich result eligibility.
Internal links below the cutoff aren't followed. Pages linked only from your footer on a 2MB+ page may go undiscovered.
Heavy pages are usually slow pages. Page weight isn't a direct ranking signal, but it correlates strongly with Core Web Vitals, which are.

Google file-size references

Google Search Central: Googlebot crawls the first 2MB of supported web-search files and 64MB for PDFs. Official documentation
SERoundtable coverage of the clarified 2MB, 64MB, and 15MB documentation context. Industry summary
Breakline's practical SEO interpretation for site owners and audits. Commentary article

Frequently asked questions

What does this tool check?

It loads the page in Cloudflare Browser Rendering, gets the final HTML, and measures its uncompressed byte size. That's the same rendered HTML Googlebot reads for indexing.

Why do you use a 2MB limit?

Google's documentation states that Googlebot uses the first 2MB of supported web-search files. Anything past that cutoff is ignored for indexing, schema parsing, and link discovery.

What about the 64MB and 15MB limits?

Google also documents a 64MB limit for PDFs and 15MB as a broader crawler/fetcher default. This checker focuses specifically on the 2MB web-search HTML case, which is what affects indexable HTML pages.

Will this always match the raw server HTML size?

No. JavaScript can change the final HTML after page load. Rendered HTML is what we measure (and what Google uses), which is often 3 to 10 times larger than the raw HTML you see in view-source.

Does gzip or Brotli compression affect this limit?

No. Google measures uncompressed bytes after rendering. Transfer compression speeds up delivery but doesn't change how much HTML counts toward the 2MB cap.

How is this different from page speed or Core Web Vitals?

Page weight is an indexing signal. Content past 2MB won't get indexed. Page speed (LCP, INP, CLS) is a ranking signal that affects where indexed pages appear. They're independent: a 4MB page can be fast, a 200KB page can be slow.

What happens to content above the 2MB cutoff?

Google simply stops reading. The content isn't seen for indexing, internal links below the cutoff aren't followed, and JSON-LD schema placed past the cutoff won't trigger rich results.

Is page weight a Google ranking factor?

Not directly. Google has stated page weight isn't itself a ranking factor, but the 2MB limit affects indexing, which determines whether content can rank at all. Heavy pages also tend to be slow, which is a ranking factor via Core Web Vitals.