The best way to use the HTML Page Weight Analyzer for HTML page size analysis is to paste the original uncompressed response body, inspect its exact UTF-8 byte breakdown, fix the largest source-level hotspot, and remeasure the deployed HTML against the conservative 2,000,000-byte body reference.
That workflow matters because “page weight” can describe two different things. The HTML response body is the source document itself; total transfer weight can also include separately fetched scripts, stylesheets, images, fonts, frames, and media. The HTML Page Weight Analyzer measures only the body you paste and does not fetch a URL or load linked resources.
Everything runs locally in your browser. The HTML is not uploaded, pasted scripts do not execute, forms do not submit, and embedded URLs are not requested. That makes the analyzer suitable for a focused source audit, but not a replacement for browser DevTools, a network waterfall, a compression check, or a Core Web Vitals test.
Know what the byte total includes
The analyzer uses the browser TextEncoder API to report the exact UTF-8 byte length of the pasted text, along with its Unicode code-point count. This avoids a misleading character-count result. ASCII usually occupies one UTF-8 byte per character, while accented letters, CJK text, and emoji can occupy more. A browser string also counts UTF-16 code units, so its length is not the same as an encoded response body. MDN's TextEncoder documentation describes the encoding operation behind the measurement.
Inline script and style text counts toward the document body. A data URI also counts because its encoded value appears directly in the HTML. By contrast, an external script, stylesheet, image, frame, preload, or media reference contributes only the characters present in the HTML; the analyzer never downloads those files or claims to know their payload sizes.
| Result | Useful interpretation | Not established |
|---|---|---|
| Total UTF-8 body bytes | Exact size of the pasted source | Transfer size, headers, or crawl outcome |
| Inline script and style share | Bytes embedded directly in the document | Runtime cost or Core Web Vitals |
| Data URI weight | Complete supported attribute values counted once | A separately downloaded file or decoded payload added again |
| External resource inventory | Supported references and their URL text | Linked file sizes or load success |
Supported data URI attribute values are counted once, complete as they appear in the pasted source. The analyzer does not decode Base64 and add the decoded payload again, which would double-count bytes already present in the HTML. Arbitrary title and data-* attributes are not treated as resources.
Googlebot and the Web Rendering Service may fetch linked resources separately, with their own limits. A long reference inventory can reveal duplicate tags, but reference count alone is not a performance score. It tells you where to inspect the page, not how expensive the linked files are.
Capture the response you meant to measure
Use the original delivered source whenever possible: View Source, a saved response body, or an authorized curl capture. Copying the Elements panel after JavaScript has run can include DOM mutations that were not in the response and omit source details that were. If a result seems inconsistent with the deployment, review these mistakes that skew HTML page size analyzer results before changing the site.
Capture uncompressed body content, and test representative responses separately when the server varies output by user agent, locale, authentication, or device. The parser uses a detached template fragment and the browser's native HTML tokenizer, which respects raw-text boundaries in elements such as textarea, title, script, and style. Nested template content remains inert and outside the resource inventory.
The analyzer applies a strict input limit, a shared element cap, and bounded URL display to protect the browser from accidental full-site dumps or adversarial markup. For accepted input, the headline byte total describes the whole pasted text, while element counts and displayed values remain bounded. An abbreviated resource list should not be treated as proof that no additional references exist beyond those bounds.
Measure, reduce, and verify the body
Use the analyzer as a short diagnose-fix-remeasure loop rather than as a one-time score.
- Capture the original body. Save the uncompressed response source from View Source or an authorized curl capture. Keep the markup unchanged; do not copy a live, script-mutated Elements tree.
- Paste the source into the analyzer. Because processing is local, the text remains in the browser and is not uploaded or fetched as a page.
- Run the analysis and read the complete breakdown. Check total UTF-8 bytes, the Unicode code-point count, inline script and style shares, data URI weight, the bounded external-resource inventory, and remaining bytes or overage against the 2,000,000-byte body reference.
- Change the largest source-level hotspot. Remove duplicated serialized state or hydration data, move appropriate inline code to cacheable external files, consolidate repeated CSS when safe, and replace large embedded data URIs with suitable separately served assets when possible. Make the smallest truthful change rather than optimizing a small share.
- Deploy and repeat the measurement. Capture the new delivered response, paste it into the analyzer, and compare the byte breakdown. Then use other tools to verify headers, resources, rendering, and any indexing evidence that matters.
Repeat the same procedure for each materially different response template. A change to one locale, device, or authenticated state does not establish the weight of every page the site serves.
Match each hotspot to a source-level correction
Use the breakdown as a debugging map. The same total can come from very different markup, and the appropriate fix depends on what the source contains.
| Finding | Inspect | Source-level correction | Verify |
|---|---|---|---|
| Inline script dominates | Serialized state, duplicated hydration data, or embedded library text | Remove duplicate payloads; externalize suitable cacheable code | New body bytes and application behavior |
| Inline style dominates | Repeated critical CSS rules | Consolidate repeated rules or externalize suitable CSS | Styles and critical rendering |
| Data URI dominates | Base64 images or fonts in supported resource attributes | Avoid embedding large binary payloads in markup | Body bytes and the resulting asset response |
| External list is unusually long | Duplicate script, style, preload, image, or media tags | Remove duplicates or incorrect references without inferring payload size | Actual network requests |
Move code to an external file only when the deployment can serve and cache it appropriately. Removing a large payload can improve the HTML body while creating a new network request, so verify both sides of the change. Likewise, replacing a data URI with an asset URL reduces body bytes but does not remove the asset's separate download.
Set a priority without turning the reference into a verdict
Google's current crawler documentation says Googlebot crawls the first 2 MB of a supported file and stops fetching at the cutoff; the limit applies to uncompressed data. A later technical explanation says HTTP headers consume part of the per-URL allowance. Because this analyzer receives only a pasted body, it cannot know the real response-header size or prove exactly where Googlebot would stop. It therefore labels 2 MB as a decimal 2,000,000-byte body reference and keeps the header caveat visible.
Use the remaining-byte or overage figure to prioritize source work, not to predict an indexing outcome. A body below the reference does not guarantee a complete fetch because headers still count. An overage flag means only that the pasted body exceeds the body reference; it does not expose the exact stop point within a response that also has headers. Google's limits can change, so check the current Googlebot crawler documentation and its reference date rather than treating the number as permanent. For the reference's interpretation in this workflow, see what 2 MB means in an HTML page weight analyzer.
Close the loop with deployed evidence
After remeasurement, inspect the deployed response with browser DevTools or an authorized curl capture when those facts matter. The analyzer does not know gzip or Brotli transfer size, server headers, cache behavior, late client-side DOM mutations, external response sizes, execution cost, rendering cost, or what Google indexed. It is also not a network waterfall or Core Web Vitals test.
Verify the new body bytes, response headers, relevant linked resources, and rendered page. If your question extends to crawling or indexing, use appropriate search evidence rather than assuming that a smaller number guarantees visibility or ranking. The strongest use of the analyzer is therefore diagnostic: it points to source weight, quantifies the hotspot, and provides a repeatable baseline for the next deployment.