Troubleshooting the HTML Page Weight Analyzer starts by confirming you pasted the original uncompressed HTML response body, then reading the byte total, code-point count, inline-code share, and data-URI weight before assuming the analyzer is at fault. The tool runs entirely in the browser, never fetches your URL, never requests embedded resources, and never executes pasted scripts, so every surprise you see in the result panel traces back to one of three things: what you pasted, how UTF-8 bytes work, or what the analyzer is intentionally leaving out. Most confusing results come from a mismatch between the document the analyzer measured and the document you thought you were measuring. A response that has been mutated by client-side JavaScript, a saved file that was minified after the fact, or a CMS export that stripped comments and inline scripts will all produce a different byte total than the original response. Once you align the input, the rest of the troubleshooting falls into place.
What "Troubleshooting" Means When You Use the Analyzer
The phrase covers three distinct reader tasks. The first is figuring out why a byte total looks too large or too small compared with the size you saw elsewhere — a Lighthouse audit, a PageSpeed Insights transfer size, or a number you remember from the CMS. The second is decoding a confusing part of the output, such as a giant inline-script percentage, a long list of external resource references, or the 2,000,000-byte reference line that you may have expected to see as "2 MB" exactly. The third is verifying, after you make a change, that the new pasted source actually shrank — not that the tool reported a smaller number while your deployed response stayed the same.
A useful framing is that the analyzer is a debugging map for the source you paste, not a network waterfall, a compression calculator, or a Core Web Vitals test. That scope matters when something looks wrong. If the bytes do not match your transfer size, the difference is gzip, Brotli, or HTTP headers that the analyzer cannot see. If the inline-script share is high, that is a real source-level hotspot you can fix. If the data-URI total looks heavy, that is bytes you can move out of the markup. Knowing which bucket your problem falls into is the first step in any troubleshooting session.
Why Pasted-Body Numbers Diverge From What You Expected
The most common cause of a confusing result is the source itself. The analyzer is built around a strict rule: it measures what you paste and nothing else. That rule produces clean numbers, but it also means three sources of "missing" bytes are always outside the total.
- HTTP response headers. Google's documented 2 MB per-URL allowance for Googlebot includes header bytes, but the analyzer only sees the body you pasted. Headers, cache control, cookies, and content-negotiation overhead do not show up in the headline number.
- Compression. The tool counts uncompressed UTF-8 bytes via the browser's TextEncoder. A gzipped or Brotli-compressed response will look smaller in transfer tools while the analyzer reports the larger uncompressed size, because that is the form Googlebot actually processes for the 2 MB limit.
- External resource payloads. Linked stylesheets, scripts, images, frames, preloads, and media only contribute the URL text and tag characters that appear in the HTML. Their actual file bytes are fetched separately by the browser and by Googlebot, with their own limits. A document that points to a heavy file is not automatically a heavy document.
The second cause is the UTF-8 vs JavaScript string length confusion. A JavaScript string length is the count of UTF-16 code units, not bytes. ASCII letters such as H, e, l, l, o each take one UTF-8 byte. The accented character é (U+00E9) takes two bytes because UTF-8 encodes it as the two-byte sequence 0xC3 0xA9. So the four-character string "café" is 4 Unicode code points but 5 UTF-8 bytes: c (1) + a (1) + f (1) + é (2) = 5. CJK characters and emoji push the gap wider — a single emoji can occupy four bytes. The analyzer uses TextEncoder to report bytes, which is why its number never matches someString.length.
The third cause is what you actually pasted. Copying from the browser's Elements panel after JavaScript has run can include DOM mutations that were never in the response and can drop source details such as comments, original whitespace, or inline scripts that were removed client-side. View Source, a saved response body from your CMS export, or an authorized curl capture is a more honest input. If your server varies the response by user agent, locale, authentication, or device, capture the representative response and treat each variant as its own measurement.
Read the Output Before Calling It Wrong
Before you assume a measurement is broken, scan every line the analyzer gives you. The total UTF-8 bytes is the headline, but the code-point count sits next to it as a sanity check. Inline script bytes and inline style bytes are reported separately, with percentages of the full source. Data URIs are listed with their count and the byte weight they add to the markup. External resources appear as a bounded inventory of image, stylesheet, script, frame, preload, and media references.
| Output line | What it covers | Why it matters for troubleshooting |
|---|---|---|
| Total UTF-8 bytes | The full pasted source encoded as UTF-8 | Compares directly to the 2,000,000-byte reference line |
| Unicode code points | Distinct characters in the source | Spots heavy multi-byte characters such as accents, CJK, or emoji |
| Inline script bytes | Text inside <script> tags without a src | Points to serialized state or embedded libraries |
| Inline style bytes | Text inside <style> tags | Points to repeated critical CSS |
| Data URI bytes | Complete data: attribute values | Spots Base64 images or fonts embedded in markup |
| External resource inventory | URLs and tags for linked assets | Shows whether the document merely references heavy files |
When the percentage of inline script or inline style is high, the fix is usually to move code into cacheable external files. When the data-URI total is high, the fix is to remove embedded binaries from the markup or move them behind a real image or font URL. When the external-resource inventory is unusually long, look for duplicate tags — a stray analytics snippet, a redundant preload, or a CDN reference that fires twice. Reference count alone is not a performance score, but a long list is often the first sign that the source carries more than it needs.
Fix Confusing Analyzer Results Step by Step
- Re-paste from a clean source. Open the page in a new tab and use View Source, or capture the response with curl, then paste that uncompressed body back into the HTML Page Weight Analyzer. Avoid copying from the Elements panel once JavaScript has mutated the DOM.
- Confirm the byte total looks reasonable. Compare the reported UTF-8 bytes with the file size of your saved response. If they differ wildly, you may have pasted the wrong document, a minified bundle that you thought was HTML, or a partial snippet.
- Read the code-point count next to the byte total. A large gap between the two numbers tells you that multi-byte characters are inflating the byte total. This is a content fact, not a tool bug.
- Sort the hotspots. Look at the inline-script, inline-style, and data-URI lines. Identify the single largest source-level hotspot — usually the one with the biggest percentage of the full source.
- Make one small truthful change. Move a block of inline script into a cacheable external file, drop a duplicated hydration payload, or replace a data-URI image with a real asset URL. Avoid editing multiple things at once so you can isolate the effect.
- Remeasure the deployed response. Fetch the live URL again with curl or View Source, paste the new body into the analyzer, and compare the byte total, inline shares, and external inventory against the previous run.
- Check the 2,000,000-byte reference line. Read it as a body-only comparison against Google's current 2 MB per-URL Googlebot limit, not as a guarantee that the page will be fully crawled or indexed. See why pasted bytes do not guarantee a Googlebot fetch for the limit context.
- Verify the deployed outcome. Confirm the response headers, rendered page, and indexing evidence behave the way you expected. A smaller number from the analyzer does not by itself prove better crawling or ranking.
If your problem is specifically that the data-URI total looks wrong, remember two parsing rules that protect against double-counting. The analyzer counts the full attribute value as it appears in the pasted source — including the data: prefix, the MIME type, the optional ;base64 token, and the payload characters. It does not decode the Base64 payload and then add those bytes again, because those bytes are already present in the HTML source. It also does not treat an arbitrary data-* attribute, an href like #section, or a title as a resource. Nested <template> content is parsed with the browser's native HTML tokenizer and stays inert, so its markup does not contribute to the resource inventory. A srcset value is preserved as one declaration because naive comma splitting would misinterpret data URLs inside it.
Confirm the Fix on the Real Deployed Response
The analyzer shows you what the source you pasted looks like; it does not show you what Google saw. After you edit the source and remeasure, the next step is to fetch the live URL the same way your crawler would. An authorized curl capture is usually the cleanest signal, because it gives you the same response body your real users receive and lets you compare against the analyzer's number byte-for-byte.
If the deployed body matches the analyzer's number, the change is real. If it does not, something sits between your source and the deployed response — server-side includes, edge workers, minification, or a CMS rewriting tags on save. The fastest way to spot that gap is to diff the curl output against the file you thought you were shipping. If the analyzer shows a smaller number but the curl output is unchanged, you edited the wrong file.
Two more checks are worth running before you close the troubleshooting session. First, look at the response headers with -I or -D -; the analyzer cannot see them, and they are part of the 2 MB per-URL allowance Googlebot uses. Second, decide whether the deployed page still looks correct in a browser — an inline-script reduction that broke a hydration step will not show up in the analyzer, only in the page. For larger workflows, avoid the input mistakes that skew analyzer output in the first place by saving the response you intend to measure rather than copying from a live DOM.
Limits to Keep in Mind When the Result Still Looks Off
The analyzer is bounded by design. A strict input limit, a shared element cap, and bounded URL display protect against full-site dumps and adversarial markup. Counts and displayed values stop at those limits so the main thread is not blocked. The parser uses the browser's native HTML tokenizer inside a detached template fragment, which means <textarea>, <title>, <script>, and <style> raw-text boundaries are read correctly, even when nested templates contain markup that looks like resources. That same detachment is why pasted scripts never execute, forms never submit, and image or iframe URLs are never requested. Results are rendered as text rather than as live DOM.
It also means there are several things the analyzer cannot tell you. It does not know gzip or Brotli transfer size. It does not know response header size. It does not know cache behavior. It does not know late client-side DOM mutations. It does not know resource response sizes, execution cost, rendering cost, or what Google actually indexed. When any of those matter, use DevTools or curl against the authorized public response. The analyzer gives you a transparent body reference for the source you paste, not a verdict on the live page, and Google's documented limits can change over time, so check the source of the 2 MB reference rather than treating the number as a constant.