Documenting the steps to use an HTML Page Weight Analyzer means recording a fixed procedure that turns a pasted HTML response body into a transparent byte measurement, an inline-versus-external breakdown, and a clear comparison with Googlebot's current 2,000,000-byte fetch boundary. The documented workflow should capture three things each time you run it: the exact source you paste, the fields the analyzer returns, and the boundaries the tool does not measure. By writing those down, you can reproduce a measurement days later, explain it to a teammate, or hand it to an auditor without re-running the analysis blind. The analyzer itself runs entirely in the browser, never uploads your HTML, and never fetches the live URL — so your notes only need to record what you chose to paste, when you pasted it, and how you read the output. Treat the document as a debugging map rather than a verdict: small, truthful changes followed by remeasurement are how the workflow earns its keep, and how your notes stay defensible when someone asks why the number moved.
What the HTML Page Weight Analyzer measures
The HTML Page Weight Analyzer is a paste-and-measure tool. It accepts an HTML response body — the bytes the server delivered, not a rendered DOM and not a live URL — and reports five categories of facts about that text. First, the total UTF-8 byte length, computed through the browser's TextEncoder API, which matters because a JavaScript string length counts UTF-16 code units while an HTML response is normally transferred as encoded bytes. Second, the Unicode code-point count, which lets you spot pasted documents that look short but carry a lot of accented, CJK, or emoji characters. Third, the share of the document occupied by inline script and style element text. Fourth, the bytes consumed by data URIs embedded in source attributes. Fifth, a bounded inventory of external resource references — script src attributes, stylesheet and preload links, plus common direct image, media, and frame attributes.
The headline total is positioned against a 2,000,000-byte reference. That number is decimal, conservative, and labeled as such, because Google's current documentation states that Googlebot crawls the first 2 MB of a supported file, applies the limit to uncompressed data, and consumes part of the per-URL allowance with HTTP headers. The analyzer sees only your pasted body, so the comparison is a transparent body reference, not a crawl or indexing guarantee. External resource files are listed by URL but never downloaded; the analyzer cannot prove the size of any file it did not fetch.
The exact steps to document your analyzer workflow
Once you understand what the tool measures, the workflow you write down should be short enough to repeat and detailed enough to audit. Treat the following sequence as the canonical checklist you paste into your runbook, ticket, or change log.
- Capture the original uncompressed HTML response body. Use View Source, a saved response file, or an authorized curl capture. Skip the Elements panel — it can include post-load DOM mutations that were not in the response and omit details that were.
- Open the HTML Page Weight Analyzer and paste the response body. Confirm the input area shows the document you intended to measure, not a stripped excerpt.
- Run the analysis. The tool parses the text inside a detached template fragment, so nothing executes, nothing is uploaded, and no referenced resource is fetched.
- Record the four primary numbers: total UTF-8 bytes, Unicode code-point count, inline script + style bytes, and data URI bytes. Note each as both a byte total and a percentage of the full source.
- Log the 2,000,000-byte reference comparison: how many bytes remain under the line or how many bytes of overage stand above it, with the visible caveat that HTTP headers also consume part of Google's per-URL allowance.
- Save the bounded external-resource inventory. The script src list, stylesheet and preload links, and direct image, media, and frame attribute counts let you separate a heavy document from a document that merely points to heavy files.
- Identify the single largest source-level hotspot from your notes — usually inline serialized state, duplicated hydration data, or a large data URI — and write down the smallest truthful change you intend to make.
- After deploying that change, repeat steps 1 to 6 on the new response. Compare the new numbers with the previous run in your notes; do not assume the smaller value guarantees crawling, indexing, or ranking.
How to interpret each number in your written notes
For your notes to stay useful across runs, every field should map to one plain-English meaning. The table below summarizes what each field represents and why it earns a line in your document.
| Field in your notes | What it represents | Why it belongs in the documented workflow |
|---|---|---|
| Total UTF-8 bytes | Encoded byte length of the pasted body, computed with TextEncoder | The headline number you compare across runs and against the 2 MB reference |
| Unicode code-point count | Number of user-perceived characters in the pasted text | Reveals pasted documents heavy in accented, CJK, or emoji characters that look shorter than they are |
| Inline script bytes and share | UTF-8 bytes inside inline script elements plus percentage of source | Often points to serialized application state, embedded libraries, or duplicated hydration data |
| Inline style bytes and share | UTF-8 bytes inside inline style elements plus percentage of source | Indicates repeated critical CSS that may belong in a cacheable external file |
| Data URI bytes | UTF-8 bytes inside data: attribute values in supported direct resource attributes | Reveals Base64 images or fonts embedded directly in markup; counted once, not double-decoded |
| External resource inventory | Script src list, stylesheet and preload links, direct image, media, and frame attribute URLs | Distinguishes a heavy document from a document that merely references heavy files |
| 2 MB reference comparison | Bytes remaining under 2,000,000 or bytes of overage above it | Body-only reference; never a crawl or indexing certification |
One small, verifiable example makes the byte-versus-character distinction concrete for a teammate reading your notes. The four-character string "Hello" weighs 5 UTF-8 bytes, because each ASCII letter is one byte. The four-character string "Café" still looks like four characters but weighs 5 UTF-8 bytes, because é encodes as two bytes while C, a, and f each encode as one. A documented run that records "Hello" = 5 bytes next to "Café" = 5 bytes gives an immediate sanity check on how the analyzer counts and shows why code points and bytes are not interchangeable.
Boundaries to record next to every measurement
A documented analyzer workflow is only credible if it also records what the tool does not measure. Five limits belong on the same page as your numbers.
First, the analyzer measures the pasted source. It does not fetch the URL, so it cannot tell you the live response's gzip or Brotli transfer size, the server headers that accompanied the body, the cache directives, or the actual bytes delivered to a real crawler. When those facts matter, use browser DevTools or curl against the authorized public response and paste that body back into the analyzer.
Second, external resources are listed, not weighed. A script element with a src attribute contributes only the URL characters to the pasted HTML total; the script's own payload is fetched separately by browsers and by Googlebot, with their own limits. Mistakes That Skew Your HTML Page Size Analyzer Results walks through the common ways that boundary gets forgotten, especially when developers assume a long inventory means a slow page.
Third, data URIs are measured as they appear in the source. The analyzer counts the complete data: attribute value once and does not decode Base64 and then add the decoded payload again, because that would double-count bytes already in the HTML. Recording that fact next to your data URI total prevents a reviewer from "correcting" the number upward.
Fourth, the 2,000,000-byte line is a body reference. Google's documentation says HTTP headers consume part of the per-URL allowance, and limits can change. Record the source link and reference date with the number rather than treating 2,000,000 as a permanent constant.
Fifth, the tool is not a network waterfall, compression calculator, or Core Web Vitals test. It does not know rendering cost, execution cost, late client-side DOM mutations, or what Google actually indexed. The breakdown is a debugging map; the deployed response, response headers, rendered page, and indexing evidence are how you verify any change.
Turning your documented steps into a repeatable audit
Once the steps and limits are written down, the document becomes a repeatable audit. Capture the timestamp, the URL or route under test, the user agent or locale variant if the server varies by those, and the exact source of the pasted body. Store the analyzer output as a snapshot — total bytes, code points, inline shares, data URI bytes, external inventory length, and the 2 MB comparison — alongside the change you intended to make. After deployment, run the same checklist on the new response and diff the snapshot.
Three habits keep the audit honest over time. Paste only what the server delivered, not what the browser later mutated in the DOM. Re-measure the deployed response after each fix rather than the page you developed locally. Treat reference counts and percentages as evidence, not as scores: a long external-resource inventory may reveal duplicate tags worth consolidating, but it is not by itself a performance verdict.
With those habits, the documented workflow turns from a one-off note into a record you can defend when a stakeholder asks why the number moved, why the response sits at 1,850,000 or 1,950,000 bytes, or whether a shrinking trend is real. The analyzer stays the same on each run; what changes is the discipline with which you feed it the original response body and interpret the bytes it returns.