An HTML Page Weight Analyzer measures the UTF-8 byte size of an HTML document you paste into it, breaks that total into inline scripts, style blocks, data URIs, and external resource references, and labels it against a 2,000,000-byte reference that mirrors Googlebot's documented 2 MB per-URL allowance. The headline number is the exact UTF-8 byte length of the text you submit, computed with the browser TextEncoder API, alongside a Unicode code-point count so you can see the difference between JavaScript string length and byte length. Inline script text, inline style text, and data URI attribute values count toward that total; referenced external files are listed by URL but never fetched or weighed. Everything happens in a detached template fragment — the analyzer does not request resources, execute pasted scripts, submit forms, or upload your markup. The 2 MB label is a body-only decimal reference, not a guarantee that Googlebot will index the page, and the tool surfaces that header caveat alongside any byte total it returns.
What the Tool Actually Measures on the Pasted HTML
When you open the HTML Page Weight Analyzer and paste a response body, the analyzer runs a fixed pipeline. It first measures the total UTF-8 bytes of your pasted text using the browser TextEncoder API, because ASCII characters usually occupy one byte and accented letters, CJK text, and emoji occupy more, which is why a character count is the wrong headline number. It also reports the Unicode code-point count so the difference between JavaScript string length and UTF-8 byte length stays visible. Next, it parses the markup inside a detached template fragment and walks the resulting tree to classify what each part of the source actually contributes. Inline script and inline style text are read out and reweighed as UTF-8 bytes; external script elements are listed by src attribute, never fetched; stylesheet, preload, and module links are identified through rel tokens; direct image, media, and frame attributes are inventoried; and a srcset value is preserved as one declaration because data URLs make naive comma splitting unsafe. The result is a byte total for the pasted HTML, a percentage breakdown for the inline slices, a data URI byte count, and a bounded list of external references — bounded so a very large response cannot create an unbounded result view.
Preparing the HTML You Will Paste
The single biggest source of misleading numbers is bad input, and the input you choose shapes what the analyzer can tell you. View Source is the fastest reliable capture for a public page: it shows the original response body with all source-level whitespace and HTML comments intact. A saved response body from DevTools, or an authorized curl capture, is even better when the server varies by user agent, locale, authentication, or device, because you can store the exact bytes the server sent to that representative client. Avoid copying from the Elements panel after JavaScript has run. Mutations the framework made at runtime show up alongside the original response, while source-level details such as HTML comments, original attribute ordering, and certain meta tags can be dropped. Treat the Elements panel copy as a debugging hint, not a measurement input, and remeasure from a saved body whenever the first number looks suspicious.
How to Use the HTML Page Weight Analyzer
The full workflow is short, and each step maps to a specific part of the result.
- Capture the uncompressed HTML response body with View Source, a DevTools save, or an authorized curl run, and copy the entire response body text.
- Paste the body into the HTML Page Weight Analyzer and run the analysis. Wait for the total UTF-8 byte count, code-point count, inline script and style percentages, data URI byte count, and bounded external-resource inventory to render as text.
- Read the headline number against the 2,000,000-byte reference the analyzer displays. Note remaining bytes if you are under, overage if you are over, and remember that the analyzer is labelling the body only.
- Open the breakdown and identify the largest single source-level hotspot: usually a chunk of inline script, a block of inline style, or a pile of data URIs.
- Apply the smallest truthful fix on the deployed source: move a script or critical CSS into a cacheable external file, drop duplicated serialized data, replace a Base64 image with a real file URL, or trim inline payload that should be lazy-loaded.
- Remeasure the deployed response with the same capture method, not the in-progress draft, and confirm the byte count moves the right way.
Reading the Numbers Against the 2 MB Reference
The analyzer labels 2,000,000 bytes as a conservative decimal reference to Google's documented 2 MB per-URL Googlebot allowance, where the stated limit applies to uncompressed data and HTTP headers consume part of the per-URL allowance, as described in Google's Inside Googlebot post. Because the analyzer only sees the body, it cannot prove where Googlebot will actually stop, and it tells you so. The displayed comparison is a transparent body reference, not a certification. Below the byte total, the analyzer shows inline script bytes as a percentage of the complete source, inline style bytes as a percentage, and the data URI byte count. The external-resource inventory lists how many external scripts, stylesheets, images, frames, preloads, and media references the markup points at, but it never adds their payload bytes to the total. Numbers that are close to the reference still need a sanity check on response headers, transfer size, and any caching you have configured.
What the Analyzer Weighs Versus What It Lists Only
Two categories of result come back from the analyzer, and mixing them up is the easiest way to misread the output.
| What the analyzer counts toward the byte total | What the analyzer lists but does not weigh |
|---|---|
| Total UTF-8 bytes of the pasted HTML body | External script src URLs |
| Unicode code-point count of the same body | External stylesheet, preload, and module link targets |
| Inline script text inside script elements | Image, media, and iframe reference counts |
| Inline style text inside style elements | srcset preserved as a single declaration |
| Data URI bytes counted once per attribute value | Header sizes, cache behavior, and transfer compression |
| No header bytes are seen by the tool | External script, CSS, image, and media payload sizes |
Finding the Largest Source-Level Hotspot
Treat the breakdown as a debugging map rather than a performance score, because the analyzer is showing you where the source itself is large. Large inline script bytes usually point to serialized application state, duplicated hydration data, or libraries that should live in a cacheable external file with a long cache lifetime. Large inline style bytes usually mean repeated critical CSS that belongs in an external stylesheet, not duplicated on every page render. A large data URI total almost always reveals Base64 images or fonts that were inlined for legacy reasons and would be smaller, cacheable, and parallel-fetchable as separate files. A long external-resource inventory is a different kind of signal. Reference count alone is not a performance score, but a long list of duplicate or near-duplicate tags often points at template code that emits the same analytics, marketing, or styling snippets several times. The analyzer keeps counts bounded so you can see the pattern without scrolling through thousands of rows.
Acting on the Result and Remeasuring the Deployed Response
After you find a hotspot, make the smallest truthful change on the deployed source and remeasure the real response, not the editor draft. Move appropriate code into cacheable external files, remove duplicated serialized data, stop embedding large binary payloads in data URIs, and place critical metadata and visible content early in the response so the most useful text sits below the byte reference. Then verify the deployed bytes, response headers, rendered output, and any indexing evidence you can collect. A smaller pasted number is a debugging clue, not a ranking guarantee, and it is the first move in the loop rather than the last one. Rerun the same capture and the same paste after each change so the comparison stays fair, and stop optimizing the source once the breakdown no longer points at a single dominant hotspot.
If you're weighing options, Get Your LinkedIn Profile Link From HTML Source covers this in detail.