Repeated measurements of the exact same pasted HTML return identical numbers every time because the analyzer measures the text you paste rather than re-fetching a live URL, so variability only appears when the input itself changes. The HTML Page Weight Analyzer parses the pasted response body in a detached template fragment using the browser's native tokenizer and the TextEncoder API, so given the same characters in the same order the headline UTF-8 byte total, the inline script and style shares, the data URI weight, and the bounded external-resource inventory are deterministic. Repeatability therefore lives upstream of the tool: if your paste matches the original delivered HTML byte for byte, the analyzer will produce the same result on run one, run two, and run ten. Two conditions break that promise — a different capture method (View Source versus the live Elements panel) or a different representative response (user agent, locale, authentication, device) — and both can be controlled with a small, repeatable workflow that anchors your paste to one specific delivery of the page.
Why the same page can produce different numbers
The HTML Page Size Analyzer does not vary; the input does. Three patterns cause the apparent noise between two runs, and each one has a different fix.
Elements panel versus View Source. The Elements panel reflects the live DOM after JavaScript has run. Hydration scripts rewrite class attributes, replace placeholder tokens with translated strings, and inject analytics, consent banners, or feature-flag nodes that were never in the response body. View Source and a saved curl capture preserve the original uncompressed response, so they are the inputs that keep measurements stable across runs.
Different responses for the same URL. Many servers vary the HTML they send by user agent string, locale, cookie, authentication state, and device class. Each variant produces a different response body, so each variant produces a different analyzer result. If you paste a desktop Chrome response once and a Googlebot Smartphone response a second time, the numbers you compare are not measuring the same artifact even though the URL is identical.
Different runs after a deploy. That is not analyzer noise — it is a real change in the body. Repeatability across deploys requires saving the previous paste and comparing new runs to that baseline instead of comparing two new runs to each other.
How to repeat the same result in the HTML Page Size Analyzer
- Lock one capture setup. Pick one capture method (View Source or curl) and one representative response — for example desktop Chrome, en-US locale, unauthenticated — and write those choices down so every run starts from the same setup.
- Capture the original uncompressed response body. In a browser, open View Source (Ctrl+U on Windows/Linux, Cmd+U on macOS) and copy the entire document. On the command line, run curl with the matching user-agent string and save the body to a file with curl -A "Mozilla/5.0 ..." -o page.html https://example.com/ so you can diff it later.
- Paste and analyze once. Open the HTML Page Weight Analyzer, paste the full response body, and run the analysis. The result covers the UTF-8 byte total, the 2 MB reference line, the inline script and style shares, the data URI weight, and the bounded external-resource inventory.
- Save the baseline. Store the capture file and the analyzer output together — either as a screenshot or as a text note listing the headline bytes and each share — so the baseline can be retrieved for the next comparison.
- Remeasure after a change. Make the smallest truthful change to the deployed response, redeploy, recapture from the same method, paste again, and compare the new total to the saved baseline. The numbers should only differ by the bytes your change actually added or removed.
What the analyzer counts and what stays outside the calculation
The tool reports the UTF-8 byte length of the pasted text, its Unicode code-point count, the share of bytes held inside each inline <script> and <style> element, the bytes inside data: attribute values on supported attributes, and a bounded inventory of external references such as img src, link rel="stylesheet", link rel="preload", script src, video, audio, and iframe. External file payloads stay outside the total — only the URL characters count toward the body, which is the same input the Googlebot comparison line uses.
HTTP response headers, gzip or Brotli transfer encoding, late client-side DOM mutations, and what Google actually indexed are also outside the calculation. The 2,000,000-byte body reference is a decimal approximation of Google's documented 2 MB per-URL Googlebot limit applied to the body only; Google's crawler blog notes that headers consume part of the per-URL allowance, so a body that fits comfortably below the line still cannot prove where Googlebot will stop. The reference is a debugging marker, not a crawl guarantee.
Side-by-side: which capture method stays repeatable
| Capture method | What gets pasted | Deterministic across runs | Needs a network call |
|---|---|---|---|
| View Source (Ctrl/Cmd+U) | Original uncompressed response body | Yes, for the same URL and headers | No |
| Saved page.html from curl | Original uncompressed response body | Yes, and easy to diff between runs | Yes (authorised fetch) |
| Elements panel copy | Live DOM after JavaScript mutations | No — hydration, analytics and feature flags drift | No |
| Browser "Copy outerHTML" | Live DOM, may include shadow content | No — same drift as the Elements panel | No |
For a repeatable baseline, prefer View Source or a curl capture saved to a file. Reserve the Elements panel for inspecting the rendered DOM, not for measuring the response body.
Remeasuring after a fix without breaking the baseline
Once the baseline is saved, the rule is one small truthful change at a time. Move appropriate code to cacheable external files, remove duplicated serialized hydration data, avoid embedding large Base64 images in data: URIs, and place critical metadata and content early in the response. Redeploy, recapture from the same method, paste again, and compare the new total to the saved one. A delta you cannot explain usually means the capture method slipped — for example, the second run came from the Elements panel or the server switched response variants. Treat unexplained deltas as a signal to re-anchor the capture rather than a reason to keep editing.
Finally, verify the deployed bytes, response headers, rendered page, and indexing evidence rather than assuming a smaller body guarantees crawling, indexing, or ranking. The analyzer measures the pasted text honestly; the surrounding pipeline — compression, headers, caching, and Google's actual fetch — still needs its own checks. If you keep seeing odd numbers between runs, the guide on mistakes that skew your HTML page size analyzer results walks through the most common drift causes in more detail.
If you're weighing options, Get a LinkedIn Profile Link From Pasted HTML covers this in detail.