The HTML Page Weight Analyzer reports the UTF-8 byte weight of the HTML you paste — not the on-the-wire transfer size — and lays the body against a 2,000,000-byte reference drawn from Googlebot's documented 2 MB per-URL fetch limit. "Correct use" in this context means three things: feeding the analyzer the original uncompressed response body rather than a mutated snapshot, reading the right fields without conflating bytes with character counts, and treating the result as a debugging map that points to one source-level hotspot at a time. The tool runs entirely in the browser through a detached template fragment, never uploads or fetches anything, and uses the platform TextEncoder API so the headline number reflects encoded bytes rather than a JavaScript string length. External files referenced from the HTML — images, scripts, stylesheets, fonts — are inventoried by URL but never downloaded or sized. Correct use means accepting those boundaries instead of trying to stretch the tool into a network waterfall, a compression calculator, or a Core Web Vitals test.
What Correct Use Requires of the Reader
Use an HTML page weight analyzer correctly by separating three decisions that often get blurred: choosing the input, reading the output, and acting on what the output shows. Each of those decisions has at least one failure mode that quietly skews the result.
The first decision is input selection. A correctly used analyzer starts with the original uncompressed HTML response body, not the DOM the browser shows you after JavaScript runs. The second decision is field selection. A correctly used analyzer focuses on UTF-8 byte totals, not JavaScript string lengths, and it never tries to read the result as a Core Web Vitals prediction. The third decision is follow-up. A correctly used analyzer produces a single source-level hotspot at a time, after which the deployed response is remeasured to confirm the change actually shipped.
If any of those three decisions is skipped, the headline number still prints, but the workflow it supports is no longer trustworthy. The rest of this article walks through each one in turn.
Scope of the Measurement
The analyzer's input is the text you paste, and that input is guarded by a strict input limit, a shared element cap, and bounded URL display so accidental full-site dumps and adversarial markup cannot overwhelm the main thread or output. Its output covers a deliberately bounded set of measurements drawn from that text plus a single Googlebot comparison. Everything else lives outside the result.
| Counted by the analyzer | Not measured by this tool |
|---|---|
| Total UTF-8 byte length of the pasted source | HTTP response headers |
| Unicode code-point count of the pasted source | Gzip or Brotli transfer size |
| Bytes inside each inline <script> element | External CSS, JS, image, font, or media file payloads |
| Bytes inside each inline <style> element | Server cache behavior and CDN settings |
| Bytes occupied by data: URI attribute values | Late client-side DOM mutations |
| Inventory of external resource references | Render time, Core Web Vitals, or execution cost |
| Position against the 2,000,000-byte body reference | Indexing or ranking outcomes |
Linked resources do not add their payload bytes to the pasted HTML total. An external stylesheet, script, image, frame, preload, or media reference contributes only the characters that appear inside the HTML response. The analyzer lists those references so you can distinguish a heavy document from a document that merely points to heavy files, but it never downloads those files or claims to know their sizes. Googlebot and the Web Rendering Service may fetch referenced resources separately, with their own limits, and per a Google Search Central crawler post those resources do not piggyback on the response-body allowance.
The 2,000,000-byte comparison is also deliberately conservative. Google's current documentation says Googlebot crawls the first 2 MB of a supported file and stops fetching at the cutoff, and a later technical explanation adds that HTTP headers consume part of the per-URL allowance. Because the analyzer receives only a pasted response body, it cannot see response headers or prove exactly where Googlebot will stop. The interface labels 2 MB as a decimal 2,000,000-byte body reference, shows remaining bytes below it or overage above it, and keeps the header caveat visible so the number is read as a reference, not a certification.
Choose the Right HTML Input
Correct use starts before any measurement runs. The analyzer cannot tell whether what you pasted is the same HTML Googlebot received, so the input is your responsibility.
The recommended sources are View Source in the browser, a saved response body, or an authorized curl capture against the public URL. These represent what the server actually returned. The Elements panel, by contrast, shows the live DOM after JavaScript has mutated it; copying from it can include changes that were never in the response and can omit source details that were. For pages where the server varies by user agent, locale, authentication, or device class, capture the representative response you actually care about — the analyzer will measure whatever you paste, not what you intended.
ASCII characters usually occupy one UTF-8 byte each, but accented letters, CJK text, and emoji each occupy more. That is why a single character count and a byte count can diverge sharply on the same source, and why the analyzer uses the browser TextEncoder API rather than a JavaScript string length for the headline total.
Run the Analysis Step by Step
- Capture the original uncompressed HTML response body using View Source, a saved response body, or an authorized curl capture. Save it locally so you can paste it without truncation.
- Paste the captured body into the HTML Page Weight Analyzer. Nothing is uploaded or executed; the text is parsed inside a detached template fragment.
- Run the analysis and read the headline total as UTF-8 bytes, not characters. Treat the Unicode code-point count as a secondary reference, useful for spotting multibyte-heavy content but never as the page weight.
- Review the inline <script> and inline <style> shares next. Each is reported as both a byte total and a percentage of the complete source, which lets you see whether the bulk of the body is markup, code, or styling.
- Inspect the data: URI section for embedded Base64 images, fonts, or other binary payloads. The analyzer counts the complete attribute value as it appears in the pasted source; it does not decode the Base64 and then add the decoded payload again, because that would double-count bytes already present in the HTML.
- Skim the external resource inventory. Read it as a list, not a score: long inventories can point to duplicate tags or unintended preload or iframe loads, but a high reference count is not a performance rating.
- Compare the headline total with the 2,000,000-byte reference. Note the remaining or overage bytes, but remember that HTTP headers and separately fetched resources sit outside this calculation, so the number is a body reference rather than a fetch guarantee.
Read the Result as a Debugging Map, Not a Score
The result panel is not a performance score. It is a debugging map of the pasted source, and reading it that way is what separates correct use from optimistic use.
The first map to read is the inline script share. Large inline script bytes commonly point to serialized application state, duplicated hydration data, or embedded libraries that would be smaller as cacheable external files. The second map is the inline style share. Large inline style bytes often indicate repeated critical CSS, framework boilerplate that could be deduplicated, or design tokens emitted inline rather than pulled from a shared sheet. The third map is the data: URI total, which can reveal Base64 images or fonts embedded directly in markup — payloads that look like text but behave like binaries.
A long external resource inventory is a fourth map. It does not measure the external files, but it can surface duplicate tags, redundant preloads, or iframe references that the page does not actually need. Reading the inventory alongside the inline shares gives you a rough split between "the document itself is heavy" and "the document points to heavy files."
One numeric example makes the byte-versus-character distinction concrete. Suppose your pasted source contains 100 ASCII characters and 20 emoji. The UTF-8 byte weight is 100 × 1 + 20 × 4 = 180 bytes, while a JavaScript string length reports 140. Both numbers are correct under their own definitions; only the 180-byte figure is the headline total the analyzer displays, which is the figure Googlebot actually transfers across the wire for the body.
Fix One Hotspot, Remeasure, and Verify
Acting on the result is the third leg of correct use, and it is where most "use it correctly" workflows quietly break.
Pick one hotspot. Move appropriate code to cacheable external files, remove duplicated serialized state, avoid embedding large binary payloads as data URIs, and place critical metadata and content early in the response. After making the smallest truthful change, do not assume the analyzer will show a smaller number — paste the new deployed response back in and remeasure. The deployed bytes matter, not the bytes on disk before deploy.
Verification does not stop at the body. The analyzer does not see HTTP headers, gzip or Brotli transfer size, server cache headers, late client-side mutations, or rendering cost, and it does not claim that being below the 2,000,000-byte body reference guarantees Googlebot will fetch the whole page. Those questions need DevTools or curl against the authorized public response, plus a check of the rendered page and the indexing evidence, before you treat the change as a win. A smaller number from this tool is a signal that the source got lighter; it is not, on its own, a signal that crawling, ranking, or indexing improved.
If the result ever looks inconsistent with what you expected — for example a much smaller number than DevTools suggests — work through the input pipeline first. Most skewed results come from pasting a post-mutation Elements snapshot, a gzip-decompressed sample, or a partial fragment rather than the original delivered body. For a deeper checklist of input and reading pitfalls, see Mistakes That Skew Your HTML Page Size Analyzer Results.
For a deeper look, see Get the Link for a Facebook Page From HTML Source.