An HTML Page Weight Analyzer run is only useful when the five details it actually measures are clear: the input is the original uncompressed HTML response body, the total is UTF-8 bytes rather than a character count, the 2 MB body reference line against Google's documented Googlebot allowance is decimal and body-only, inline script and inline style content plus embedded data URIs count toward the body total, and external file references are listed but never downloaded or added to the byte total. Everything else, from caching and compression to response headers, the size of referenced files, and what a search engine actually indexes, sits outside the pasted-body calculation by design. Treating those boundary lines as the actual surface area of the tool is what separates a number you can act on from a figure you read past.
The exact tool this article describes is the HTML Page Weight Analyzer, which works entirely on the text you paste in. The product contract makes it explicit: it parses the input through a detached template fragment, does not upload or fetch anything, and reports on the UTF-8 byte count of the source plus a bounded inventory of inline and external references. Knowing which details the tool decides for you, and which it leaves you to verify elsewhere, is the whole point of paying attention.
Details That Decide Whether an HTML Page Weight Run Is Useful
Most of the values an HTML weight analyzer prints are decisions, not measurements. "Total bytes" assumes the body you pasted is the body Googlebot would receive. "Inline script share" assumes what is inside a <script> element without a src is meant to be a hot path. "Data URI weight" assumes embedded data: URLs are intentional and not duplicated state. Each of those assumptions is a detail the reader must hold in mind, because the analyzer will silently apply it.
The single biggest detail is that total bytes is UTF-8 bytes, not character count. A browser string is a sequence of UTF-16 code units, so JavaScript .length on a pasted HTML string would return a different number from the byte total the analyzer reports. The tool uses the browser TextEncoder.encode() method so the headline figure reflects what an HTTP response actually carries. ASCII text maps to roughly one byte per character; accented letters, CJK characters, and emoji each take two to four bytes. A short pasted string such as café has four characters but five UTF-8 bytes, because é (U+00E9) is encoded as two bytes (0xC3 0xA9). That gap widens fast on multilingual pages, which is why a character count would mislead.
Inside the Body Total: What's Counted and What's Excluded
The clearest way to hold the boundary in your head is to read the analyzer's three categories explicitly. The table below summarizes the decision the tool makes for every kind of input it can encounter.
| Category | Included in pasted-body UTF-8 total? | What it contributes |
|---|---|---|
| Original uncompressed HTML response body | Yes | Full UTF-8 byte count of the pasted text |
| Inline <script>...</script> without src | Yes | UTF-8 bytes of the in-element text |
| Inline <style>...</style> | Yes | UTF-8 bytes of the in-element text |
| Embedded data: URIs in supported attributes | Yes, counted once | Full attribute value as it appears in source |
| External script/style/image/media/iframe references | Only the URL text counts | Listed by tag and src; file is never downloaded |
| HTTP response headers | No | Outside pasted text by design |
| Gzip or Brotli compressed wire size | No | Uncompressed bytes only |
| Resource response sizes, rendering cost, indexing | No | Out of scope; verify in DevTools or Search Console |
Reading the result through this lens prevents two common errors: assuming the headline total includes assets the page only references, and assuming the headline total describes what the wire looks like under compression. Both are decisions the tool has already made, and both are worth restating in your notes every run.
Running the Analyzer in a Way That Preserves Those Details
How you prepare the input is the detail with the largest influence on the result. The product contract walks the same path for a reason, and following it keeps every other number honest.
- Capture the original uncompressed HTML response body. View Source in the browser, an authorized curl capture with compressed decoding off, or a saved response from server logs gives a faithful input.
- Paste that body into the HTML Page Weight Analyzer. Do not paste from the DevTools Elements panel after JavaScript has run; it can include mutations that were not in the original response and omit source details that were.
- Run the analysis and read the headline UTF-8 byte total, the inline script and style share, the embedded data URI bytes, and the bounded external resource inventory as separate columns.
- Compare the body total against the 2,000,000-byte reference line the analyzer prints. Read it as a body-only decimal reference, not as a guarantee that Googlebot will fetch everything.
- Identify the largest source-level hotspot, usually repeated inline data, duplicated critical CSS, or oversized data: URIs, and make the smallest truthful change that addresses it.
- Remeasure the deployed response from the same source, and confirm against DevTools, an authorized curl capture, or Search Console rather than trusting a lower number alone.
Each step preserves a different detail: step 1 protects the "this is the original body" assumption, step 2 protects the source-versus-DOM distinction, step 3 keeps you from collapsing the breakdown into a single figure, step 4 keeps the Googlebot line in proportion, and steps 5 and 6 keep the change reproducible.
The 2 MB Reference and the Details Surrounding It
Google's current crawler documentation describes a 2 MB allowance per URL for Googlebot, applied to uncompressed data; a later technical explanation adds that HTTP headers consume part of that allowance. Because the analyzer only sees the pasted body, those two facts turn the 2 MB line into a transparent, conservative comparison rather than a certification. The interface labels 2 MB as a decimal 2,000,000-byte body reference, shows remaining bytes below or overage above it, and keeps the header caveat visible. A useful companion read is the guide on why 2,000,000 pasted bytes do not guarantee a Googlebot fetch, which explores the operational consequences in more depth.
The underlying Google statement is the only source worth linking on this point, and it should always be reviewed before treating the number as a constant. Per Inside Googlebot (Google Search Central, March 2026), the limit applies to the uncompressed response and headers share in the per-URL budget. Limits can change, which is why the source link matters more than memorizing the figure.
Small Details That Quietly Distort a Result
Several details look trivial but change the headline number more than a refactor will. A page that varies by user agent, locale, authentication, or device should be tested as each representative response, because the body the analyzer sees is the body you measured, nothing else. Copying from the Elements panel after client-side hydration can inflate inline script bytes with serialized state that was not in the server response, or it can strip source comments and whitespace that originally counted. If the server varies its response by route, paste each canonical route separately.
Data URI handling is another one to watch. The analyzer counts the complete data: attribute value as it appears in source, once, without decoding and adding the decoded payload again. That prevents double-counting, but it also means an embedded Base64 font that looks like roughly 14 KB in markup will not be reported as the larger decoded glyph payload. Treat the figure as document weight, not decoded media weight.
The interaction limits the analyzer enforces also count as details. A strict input limit, a shared element cap, and bounded URL display exist specifically so a huge pasted document or adversarial markup cannot create an unbounded result. If your input is being trimmed by those guards, smaller chunks will give the cleaner read, and the result row telling you why trimming happened is itself a signal worth recording.
Treating the Breakdown as a Debugging Map
The numbers in the breakdown are most useful as a debugging map rather than a performance score. Large inline script bytes often point to serialized application state, duplicated hydration data, or an embedded library that should be a cacheable external file. Large inline style bytes usually indicate repeated critical CSS or template-generated rules that could move to an external stylesheet. A large data URI total often reveals Base64 images or fonts that belong in static asset folders. A long external resource inventory is not a performance verdict on its own: many references can be cheap if cached correctly, but a cluster of duplicate <link rel="stylesheet"> or <script src> entries is a real smell.
The honest summary is that an HTML Page Weight Analyzer only sees what you paste. Use it to map the body, decide whether the body is approaching the documented Googlebot body reference, and then move the right assets 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. Verify the deployed bytes, the response headers, the rendered page, and the indexing evidence separately. A lower pasted-byte number is a useful signal, never a final answer.
If you're weighing options, Bulk Link Extractor: Parse and Deduplicate Pasted HTML covers this in detail.