Checking the result from an HTML page weight and size analyzer starts with reading five distinct fields, not a single score: the total UTF-8 byte count of the pasted source, the share taken by inline script and style text, the byte weight of embedded data URIs, the bounded inventory of external resource references, and the gap to the 2,000,000-byte reference tied to Googlebot's documented 2 MB per-URL fetch limit. Each field comes from the analyzer's measurement of the text you paste, not from a network request to the live page, so the first check after you run the tool is whether your input was the right one. The headline number is the UTF-8 byte length of the source as encoded by the browser's TextEncoder API; it is not the JavaScript string length, it is not the on-the-wire gzipped size, and it is not the rendered DOM size. A short page in characters can still be heavy in bytes if it carries accented letters, CJK text, or emoji, and a page with many external script tags can look light because the analyzer only counts the URL characters, never the payload those URLs point to.
What the Analyzer Returns After You Paste HTML
When you paste the original uncompressed HTML response body into the HTML Page Weight Analyzer, the interface returns a fixed set of measurements built directly from the bytes of your input. The headline total is the exact UTF-8 byte length of the pasted text, alongside a Unicode code-point count, so you can see both numbers side by side and notice when they diverge. ASCII characters usually take one UTF-8 byte each, but accented letters, CJK text, and emoji take more, which is why a JavaScript string length computed by .length will understate the wire weight for non-ASCII content.
Below the headline, the result breaks the source into three debugging slices plus an inventory. The first slice reports the UTF-8 byte total of every inline script element's text content and every inline style element's text content, expressed both as bytes and as a share of the full document. The second slice reports the byte weight of every data: value found in supported direct resource attributes (such as src, href, srcset, and similar media attributes), again with a count and a percentage of the whole document. The third output is a bounded inventory of external resource references, grouped by element type, that lists the URLs the document points to without ever fetching them. The fourth output is the gap to the 2,000,000-byte reference, which is shown as remaining headroom or as overage when the body crosses that line.
How to Check the Result Step by Step
- Confirm the input was the original response body, not the Elements panel after JavaScript ran. View Source, a saved response file, or an authorized curl capture gives you the source the server sent; the live Elements panel can hide source details and add DOM mutations that were never on the wire.
- Read the headline total as UTF-8 bytes, not characters. The analyzer uses the browser TextEncoder API, so ASCII-heavy sources will be close to the character count and CJK or emoji sources will not. The MDN documentation for TextEncoder.encode() describes how this byte encoding behaves.
- Read the inline script and inline style fields as percentages of the full document. A combined share above roughly a third of the total usually signals serialized hydration data, embedded libraries, or repeated critical CSS that belongs in cacheable external files.
- Read the data URI byte total and count. Data URIs are part of the HTML source and can quietly inflate the response with Base64 images or fonts; the analyzer counts the complete attribute value once and does not decode the Base64 payload to add it again.
- Read the external resource inventory as a list, not as a weight. Each entry is the URL text the document carries, and the analyzer does not download or measure the files those URLs point to, so a long inventory does not by itself mean a heavy page.
- Read the remaining or overage line against the 2,000,000-byte reference. This is a decimal body comparison to Google's current documentation of a 2 MB per-URL Googlebot allowance, not a guarantee that the page was crawled in full.
- Pick the largest source-level hotspot from the breakdown, make the smallest truthful change (move code to an external file, drop duplicated serialized data, or split a heavy data URI into a separate fetch), then paste the new response body to remeasure.
Reading the Numbers Against the 2 MB Googlebot Reference
The 2,000,000-byte line is the most misread field, so it deserves its own check. The interface labels 2 MB as a decimal 2,000,000-byte body reference because Google's current documentation says Googlebot crawls the first 2 MB of a supported file and stops at the cutoff, and Google adds that the limit applies to uncompressed data. A later technical explanation notes that HTTP headers consume part of the per-URL allowance. The analyzer receives only a pasted response body, so it cannot know the size of the real response headers and cannot prove exactly where Googlebot will stop. Treat the 2,000,000 number as a transparent and conservative body comparison and read the displayed remaining-bytes value or overage value against it, with the header caveat visible. Limits can change, so the source link and reference date matter more than treating the number as a timeless constant.
| Output field | What it reflects | What it leaves out |
|---|---|---|
| Total UTF-8 bytes | The byte length of the pasted source as encoded by the browser. | HTTP response headers, gzip or Brotli transfer size, referenced file payloads. |
| 2,000,000-byte reference | A decimal body comparison to the documented 2 MB per-URL Googlebot cap. | Header bytes that also count toward the same allowance on Google's side. |
| Inline script and style share | UTF-8 bytes of text content inside inline script and style elements. | External script src payloads and linked stylesheet bytes. |
| Data URI total | Bytes of every data: value in supported resource attributes, counted once. | Decoded Base64 payload sizes, which are not double-counted on purpose. |
| External resource inventory | A bounded list of referenced URLs grouped by element type. | Actual response sizes, fetch results, and caching behavior for each URL. |
For a concrete read of the comparison, suppose the headline reports 1,847,520 UTF-8 bytes for the pasted response body. The arithmetic for remaining headroom under the 2,000,000-byte body reference is 2,000,000 minus 1,847,520, which equals 152,480 bytes of room. That is the gap you can read on screen, and it tells you nothing about the real response headers Googlebot would also bill against its own allowance. For a deeper read on the limit and the headers caveat, see the guide on why that reference does not guarantee a Googlebot fetch.
What the Output Leaves Out, and Why That Matters
The analyzer is not a network waterfall, a compression calculator, or a Core Web Vitals test, and a clean read of the result has to acknowledge what it does not see. HTTP response headers, gzip or Brotli transfer size, late client-side DOM mutations, and the response size of any external resource are all outside the pasted-body measurement. The analyzer does not know whether the server varies its response by user agent, locale, authentication, or device, and it does not know whether a referenced stylesheet is 4 KB or 400 KB. For any of those facts, the right next step is browser DevTools or curl against the authorized public response, then a fresh paste of the delivered body.
Two related limits also shape the read. The parser uses a detached template fragment and the browser's native HTML tokenizer, so textarea, title, script, style, and other raw-text boundaries are handled correctly; nested template content stays inert and outside the resource inventory. A strict input limit, a shared element cap, and bounded URL display protect the result view from accidental full-site dumps or adversarial markup, so if the analyzer caps a count or trims an entry, treat that as a deliberate guardrail rather than a measurement error. For a fuller treatment of how URL text differs from file payload in the result, see this breakdown of external file sizes in the result.
Acting on the Result Without Trusting It Blindly
Treat the breakdown as a debugging map, not a verdict. Large inline script bytes usually point to serialized application state, duplicated hydration data, or embedded libraries. Large inline style bytes usually point to repeated critical CSS. A large data URI total usually points to Base64 images or fonts embedded directly in markup, which are cheaper to host as separate cacheable files. A long external-resource inventory may reveal duplicate tags, but reference count alone is not a performance score, so the priority list is set by the byte-weighted fields, not the URL list.
After finding a hotspot, make the smallest truthful change and remeasure the real deployed response. Move appropriate code to cacheable external files, remove duplicated serialized data, avoid embedding large binary payloads in data URIs, and place critical metadata and content early in the response. Then check the deployed bytes, response headers, rendered page, and indexing evidence rather than assuming a smaller pasted number guarantees crawling, indexing, or ranking. The result is a reliable body measurement; it is not a promise about Googlebot.