Webpage Size Checker

What page size means here

The checker measures the response body of the HTML document. It does not measure the total weight of the page. Images, external stylesheets, fonts, videos, analytics scripts and lazy-loaded content are separate requests and are not included.

If the server reports a download size, the checker uses it. Otherwise it falls back to the length of the returned content. That fallback is still the document body, not the full page.

Bytes, kilobytes and megabytes

The table shows raw bytes and a formatted value. The formatter divides by 1,024, so 1 KB is 1,024 bytes and 1 MB is 1,048,576 bytes. That is the binary convention many developer tools use, not the decimal convention used by some storage vendors.

A 150,000-byte document is about 146 KB. A 2,000,000-byte document is about 1.9 MB. The exact figure matters less than the comparison between pages and the trend over time.

What is included and excluded

Included: the HTML markup, inline CSS and JavaScript, inline JSON, text content and any server-rendered data in the document. Excluded: external CSS and JavaScript files, images, fonts, video, iframes and requests made by scripts after load.

Transfer size can be smaller than the byte count because of gzip or Brotli compression. The checker reports the downloaded size it observes; a browser's network panel may show both transferred and uncompressed sizes, which is one reason the numbers can differ.

Batch total and comparison

With several URLs, the summary adds the individual sizes into a batch total. That is useful for comparing templates: a product page, a category page and a checkout page often have very different HTML weights even when they look similar.

Look for the outlier rather than the average. One 4 MB document among nine 100 KB pages is a concrete target; a slightly high average across all ten is harder to act on.

Why it differs from browser DevTools

DevTools measures the page you loaded, with your cookies, extensions, location and cache state. The checker measures a clean server request. Personalisation, A/B tests, ads and client-side rendering can make the browser document larger or smaller.

Compression, redirects and CDN behaviour also change the transferred size. If the checker reports the compressed body, it will be smaller than the uncompressed DOM size shown by some tools. Compare like with like.

Why HTML size matters

Every byte must be transferred and parsed before the page can become interactive. A large document costs more on mobile data, takes longer on a weak connection and gives the browser more work before it can render. It can also slow crawling when a site has many heavy pages.

HTML size is not the same as page weight and not the same as performance. A small document that loads twenty large images can still be slow. Use this check alongside a full performance audit, not instead of one.

Reducing HTML size

• Minify the markup and remove unused inline CSS or JavaScript.
• Stop shipping large JSON blobs or base64 images inside the document.
• Paginate long lists instead of rendering every row at once.
• Enable gzip or Brotli compression at the server or CDN.
• Move repeated inline styles and scripts to cached external files.
• Check that framework debug data or commented-out markup is not included in production.

Limits

The checker accepts up to ten public URLs per run, each up to 2,048 characters. It does not load assets, execute JavaScript, follow every redirect or measure the uncompressed DOM. It sends a simple request without your session.

Private addresses are rejected. A page behind a login may return a sign-in document, and a bot challenge may return a small block page, so the size will not reflect the real article.

Measuring over time

Page size tends to grow as features are added. Record the same template every month and compare it with the previous month, not with an unrelated page. A gradual increase is easier to fix than a sudden jump discovered during a redesign.

Keep a note of releases, new scripts and marketing tags. When the document grows, you can connect the change to a cause instead of guessing.

HTML size and Core Web Vitals

A large document takes longer to transfer and parse, which can delay the first render and affect metrics such as Largest Contentful Paint. Compression reduces transfer time but not the parsing work inside the browser.

HTML size is not a Core Web Vital itself, and a small document can still fail on images or client-side JavaScript. Use it as one diagnostic in a wider performance review.

Common causes of bloat

Page builders often ship nested wrappers and inline styles. Base64 images, inline SVG sprites, hydration state, duplicated menus and commented-out markup all add bytes. Tracking snippets and A/B testing libraries add more.

Open the source and search for repeated blocks, large JSON assignments and long inline style attributes. Moving repeated assets to cached files and removing unused sections usually cuts more than minifying a few spaces.

Single page or batch

Use a single URL when you are checking one template after a change. Use the batch when you want to compare several templates or find the heaviest page in a section. The batch total is the sum of the documents, not the weight of any one page.

Interpreting the number

A 200 KB HTML document is not automatically bad, and a 40 KB document is not automatically fast. Context matters: a long article with inline data may justify more bytes than a simple landing page. Compare the same template over time and against similar pages on the same site.

If the document is much larger than the visible content suggests, inspect the source for inline scripts, base64 data, duplicated markup or framework state before rewriting the page.

A gradual rise is a maintenance signal; a sudden jump is a regression until proven otherwise. Record the date and the release with every measurement.

Keep a copy of the source before a cleanup, then compare the same template after the change. Use the saved number as the baseline.

Frequently Asked Questions