Submit a URL and this checker measures the weight of the returned HTML document in kilobytes and tallies how many scripts, stylesheets, images, and iframes that markup references.
Pro tip: HTML over ~140KB or many stylesheets slows first paint; consolidate inline payloads and CSS files.
The headline number is the byte size of the HTML document the server sent back, shown both as raw bytes and as kilobytes. If the response carries a Content-Length header, that transferred size is reported alongside it so you can see the compressed-on-the-wire figure where the host provides one.
Underneath, the checker scans the markup and counts how many times it references a script tag, a stylesheet link, an image tag, and an iframe. It also reports the total number of src and href attributes as a rough sense of how many external resources the document points at overall.
These tallies are reference counts, not downloaded file sizes. A page that lists eight script tags will signal more request overhead than one with two, even if you do not yet know how large each script is. The same logic applies to stylesheets, where consolidating several files can shorten the path to first paint, and to iframes, which tend to pull in their own heavy payloads.
Thresholds drive the colour cues: an HTML body past roughly 140 KB is flagged as heavy, and a page referencing many scripts or several stylesheets earns a suggestion to trim or consolidate.
This is the most important caveat. The kilobyte figure describes only the HTML the browser receives first. It does not include the bytes of the images, CSS, JavaScript, fonts, or video that the browser then fetches to render the page. A document can look lean here and still load slowly once those assets arrive, so treat the result as a measure of document bloat rather than total transfer size.
The colour cues are driven by simple, fixed cut-offs so the result is easy to read at a glance. An HTML body under roughly 80 KB is treated as lean, between about 80 KB and 140 KB it is flagged as moderately heavy with a prompt to review repeated blocks and inline payloads, and past 140 KB it is marked heavy with a suggestion to trim non-critical markup before first paint. On the asset side, more than eight script references earns a note to cut non-critical JavaScript, more than four stylesheets prompts you to consolidate them, and any iframe at all triggers a reminder that embeds can add weight and delay interactivity.
None of these numbers are hard rules from a standard — they are pragmatic defaults that catch the most common cases of document bloat. A content-heavy article can sit comfortably above them, and a tiny page can still be slow for reasons the byte count does not capture.
Treat the HTML size as a signal about your template, not your whole page. If the number is high, view the source and look for large inline JSON blobs, repeated boilerplate, or a wall of inlined SVG — those are the usual culprits and the easiest to defer or externalise. Compare the raw HTML bytes against the Content-Length row: when the transferred figure is much smaller, compression is doing its job; when the two are close, the server may not be sending gzip or brotli, which is a quick win. For a fair before-and-after, run the same URL twice around a change rather than comparing two different pages, since templates and content differ.
The kilobyte figure and the asset tallies are reference counts and document size, not downloaded file sizes or render time. A document can look lean here and still load slowly once large images, heavy JavaScript bundles, web fonts, or third-party tags arrive. For an end-to-end view of how the page actually loads — including those assets and real Core Web Vitals — pair this with the Page Speed Test, which runs a full Lighthouse audit. Use this checker to diagnose document bloat specifically.
Only the URL you enter is sent to our edge, which fetches the page once to measure its HTML and count the referenced assets. The page content is not stored, and only publicly reachable URLs can be measured because the request is made as an anonymous visitor.
Input: https://example.com/
Output: HTML size 162.4 KB (heavy), Scripts 11, Stylesheets 5, Images 23, Iframes 1. Suggestions: trim non-critical markup and reduce script references.
162 KB of HTML alone is large; much of it is often inline JSON that can be deferred.
Input: https://example.com/docs/intro
Output: HTML size 28.7 KB (good), Scripts 2, Stylesheets 1, Images 4, Iframes 0, with a note that the payload looks lean.
A light HTML body still says nothing about the image and font bytes loaded afterward.
Input: https://example.com/products/widget
Output: HTML bytes 96,200 bytes (93.9 KB, moderate) · Transferred (Content-Length) 21.4 KB · Scripts 6 · Stylesheets 2. Suggestion: review repeated blocks and inline payloads.
The transferred figure being far below the raw bytes confirms gzip or brotli is active.
No. It is the size of the HTML document only. The full transfer also includes images, CSS, JavaScript, fonts, and any media the browser requests after parsing the HTML, none of which are added to this figure.
The counter looks for img tags in the delivered HTML. Backgrounds set in CSS, images loaded by scripts, or pictures inserted client-side will not be in that count.
It is the transferred size the server advertised in its response header, which often reflects gzip or brotli compression. When the host does not send that header, the row shows that it was not reported.
There is no universal target, but keeping the HTML body well under 100 KB and the script references in the single digits is a reasonable rule of thumb for most content pages. The tool flags anything past about 140 KB as heavy.
It can, because each reference is a potential request, but the count says nothing about file size or how long a script takes to run. Treat a high number as a prompt to investigate which scripts are critical, not as a measurement of performance.
Because iframes load their own separate documents, often with their own scripts and styles, they can add substantial weight and delay interactivity out of proportion to a single tag. The note is a reminder to confirm each embed is worth its cost, not a claim that it is broken.
Our editorial and data-source notes explain how each check works and where estimates come from.