Website Page Size Checker

A website page size checker measures the bytes in a page's HTML source and splits them by kind: markup, inline CSS, inline JavaScript, comments, and visible text. The HTML document is the first file a browser downloads for a page, and nothing else on the page is requested until the parser reaches the references inside it, so its weight sits directly in front of every other request. Search crawlers read it too: Google documents that Googlebot considers only the first 15 MB of an uncompressed HTML file and fetches referenced images, CSS, and JavaScript separately.

The input is source as a server sends it, the text that View Page Source shows, not the live document after scripts have run. For a page built in the browser by a JavaScript framework the two can differ by an order of magnitude, and the source is the honest measure of what travels first. Bytes are counted as UTF-8, so an accented letter counts 2 bytes and most emoji count 4. A page cannot fetch another site's source directly, because browsers block cross-site reads, which is why the source is pasted rather than looked up by address.

Inline CSS is the content between style tags, and inline JavaScript is the content of every script element without a src attribute, including JSON-LD structured data. Comments are counted only outside scripts and styles, so a comment-like string inside a script is not counted twice. Visible text is what remains once tags are removed, with whitespace runs collapsed to a single space. Markup is the remainder: total minus CSS, JavaScript, comments, and text, which leaves tags, attributes, entities, and indentation. Sizes switch to KB at 1,024 bytes. The gzip figure is measured, not estimated: the source is compressed with the browser's built-in gzip at its default level and the output counted, so a server using a different level, or Brotli, will send a somewhat different number.

Notes appear at fixed rules of thumb, not published standards: comments over 1 KB, inline CSS or JavaScript over 10 KB, a document over 100 KB, more than 30 referenced resources or 10 images, visible text under 10% of the total, and, for documents of at least 1 KB, gzip output above half the original size, which usually means embedded data such as base64 images. The resource list is read from link, script, img, video, audio, and source tags and from font files in CSS url() values; srcset candidates and CSS background images are not listed, and nothing on the list is downloaded or weighed.

The document <html><head><style>p{color:red}</style></head><body><!-- note --><p>Hello</p></body></html> is 91 bytes. The style content p{color:red} is 12 bytes, the comment is 13 bytes, the visible text Hello is 5 bytes, and markup is 91 - 12 - 13 - 5 = 61 bytes. Gzip makes it larger, 94 bytes, because the format adds an 18-byte header and trailer and text this short leaves little to compress.

Measuring page weight is a recurring task across development, content management, and search engine optimization. Knowing where the bytes accumulate in a document guides decisions about caching, code splitting, and what belongs inline.

• SEO Auditing: Landing pages can be held to a weight budget, for example 200 KB of uncompressed HTML, with the total and gzip size recorded for each page and the pages over budget queued for work before the next crawl.
• Front-End Development: The source of a server-rendered page before and after a refactor shows whether a template change reduced inline CSS by the expected amount without inflating markup elsewhere.
• Content Migration: Exported HTML from a legacy CMS often carries comment blocks, inline styles, and embedded scripts the old system injected; measuring them first sizes the clean-up the migration transform has to do.
• Performance Budgeting: A design system can set a per-page weight limit, and component pages checked during code review show when a new feature pushes a document past it.
• Competitive Analysis: The public source of another landing page aimed at the same search can be compared on total size, inline script weight, and referenced resource count against an existing page.
• Email Template Testing: Gmail clips a message whose HTML exceeds about 102 KB and hides the rest behind a link, so the raw size of a template matters before it is sent; inline CSS is usually the largest share in email.
• Structured Data Review: Large JSON-LD blocks count as inline JavaScript here, which shows when product or FAQ markup has grown to rival the visible content of the page.