An HTML page weight analyzer measures the byte size of the HTML response body you provide and compares that number against a transparent reference such as Googlebot's current 2,000,000-byte per-URL fetch boundary. The measurement runs locally against text you paste into the page, never against a live URL, so the result reflects exactly what you supplied rather than an estimated transfer. The headline number is a UTF-8 byte count rather than a JavaScript string length, which matters because ASCII characters fill one byte while accented letters, CJK text and emoji fill more. The analyzer also separates the share taken by inline scripts and styles, the weight of any embedded data URIs, and a bounded inventory of external resource references, so you can tell a heavy document apart from a document that merely points to heavy files. Comparing that body weight against the 2 MB reference gives a conservative map of how close the document itself sits to Google's documented cutoff, while keeping HTTP headers, separately fetched resources, and any client-side DOM mutations clearly outside the calculation.
Why a First Run Matters for HTML Page Weight
A page weight or page size analyzer tells you how many bytes the document itself contributes to what a search engine or browser receives. Many performance problems trace back to a heavy document rather than to the files the document references, so measuring the response body first gives you a clean baseline before chasing network waterfalls or Core Web Vitals. Running the analyzer once is the cheapest way to confirm whether your HTML is small, modest, or creeping toward the limits that search engines document for crawl budgets and rendering budgets.
When the first run shows a document well under the 2 MB reference, you can move on to other optimization tasks. When the first run shows a document approaching or exceeding the reference, the breakdown of inline scripts, inline styles, and data URIs points to where the weight actually lives. That early signal saves time, because you fix the largest hotspot in source rather than guessing which external request is the real culprit behind a slow page.
What This Analyzer Actually Counts and Skips
The HTML Page Weight Analyzer measures the source you paste. It reports the exact UTF-8 byte length of that text using the browser's TextEncoder API, plus the Unicode code-point count, the share of bytes inside inline script and style elements, the bytes taken by data URI attribute values, and a bounded inventory of external resource references. Everything runs in the browser. The HTML is not uploaded, fetched as a page, or executed.
That scope has a matching set of exclusions worth knowing before the first run. HTTP headers, gzip or Brotli transfer size, server configuration, cache behavior, late client-side DOM mutations, the size of external files referenced from the page, execution cost, and what Google actually indexed all stay outside this calculation. The 2,000,000-byte comparison is explicitly labeled as a decimal reference to Google's current documentation, not as a guarantee that Googlebot receives the whole page. If those excluded facts are what you need, browser DevTools or an authorized curl capture against the deployed response remain the right tools.
Pick the Best Source for Your First Paste
The single biggest decision in a first run is what you feed the analyzer. The analyzer can only measure what it receives, so a clean input produces a useful number while a mutated input produces a misleading one. Two capture methods are clearly better than the rest when you want a real HTML page size reading.
| Input Source | What It Captures | Why It Works for This Analyzer |
|---|---|---|
| Browser View Source | Original uncompressed response body | Matches what the server sent before JavaScript ran |
| Authorized curl capture | Exact bytes delivered to clients | Matches wire payload when saved before any decoding |
| Elements panel after JS | Live DOM after mutations | Includes changes the server never sent and omits source detail |
| Saved browser cache file | Possibly compressed payload | Byte count no longer matches the response body the analyzer needs |
If the server varies its response by user agent, locale, authentication or device, capture the representative response for each variant separately. A first run on the wrong input forces you to redo the analysis once the deployed bytes actually matter, and you lose the comparison between runs that makes the tool useful.
Run Your First HTML Weight Analysis
These are the steps for a complete first run with the HTML Page Weight Analyzer.
- Capture the original uncompressed HTML response body from View Source, an authorized curl run, or another method that returns the literal delivered bytes.
- Paste the captured text into the analyzer's input area. Do not paste a snapshot from the Elements panel after JavaScript has run. The analyzer enforces a strict input limit to keep oversized pastes from blocking the main thread, so very large documents may be rejected before any analysis runs.
- Run the analysis and review the total UTF-8 bytes, the 2,000,000-byte body reference, the inline script and style share, the data URI byte total, and the bounded external-resource inventory.
- Identify the largest source-level hotspot. The breakdown tells you whether the weight lives in inline scripts, inline styles, embedded data URIs, or simply in repeated markup.
- Make the smallest truthful change to the source, redeploy the page, and remeasure the new response body. Confirm the new byte count on the real delivered page before assuming the optimization worked.
A first run does not need to be exhaustive. Capture the document, run the analysis, and read the headline numbers. The detailed breakdown becomes important only when one of those numbers points somewhere unexpected, such as a data URI total larger than every external reference combined.
Compare Your Numbers Against the 2 MB Reference
The interface shows the difference between your pasted byte total and the 2,000,000-byte reference, with the HTTP header caveat visible. A document well under the reference has body weight headroom and you can focus on other optimizations. A document within roughly the last hundred kilobytes of the reference is the signal that any further growth risks losing bytes that the documented limit already consumes for headers.
A document over the reference on body bytes alone is the clearest first-run warning. Because the 2,000,000-byte allowance includes HTTP headers per Google's current technical documentation, a body that already exceeds the reference leaves no room for headers in the crawl budget. This is a body reference, not a crawl guarantee, so the right next move is to reduce the document itself rather than to assume Googlebot will fetch the overage.
Fix the Largest Hotspot and Remeasure
Treat the first-run breakdown as a debugging map. Large inline script bytes often point to serialized application state, duplicated hydration data, or embedded libraries that belong in cacheable external files. Large inline style bytes often point to repeated critical CSS that could be deduplicated or trimmed. Large data URI totals often point to Base64 images or fonts embedded directly in markup, which can usually move to external files with proper cache headers.
After you change one hotspot, remeasure the deployed response rather than the change in isolation. The real number to trust is the new byte count from the live response after the change ships. Pasted input that no longer reflects what the server sends is the fastest way to lose confidence in the analysis, and the analyzer makes comparison between runs trivial when the input capture method stays consistent.
What Stays Outside This Measurement
Knowing what the analyzer does not do is part of getting started. It is not a network waterfall, a compression calculator, or a Core Web Vitals test. It does not know gzip or Brotli transfer size, server headers, cache behavior, late client-side DOM mutations, the response size of referenced files, execution cost, rendering cost, or what Google actually indexed. For those facts, browser DevTools or curl against the authorized public response remain the right tools.
Common pitfalls that skew the first reading include pasting a minified production response that hides duplication, copying the Elements panel after a hydration script has injected content, and treating a smaller number on a staging build as proof of a smaller number on production. The Mistakes That Skew Your HTML Page Size Analyzer Results guide covers these patterns in more detail.
A first run with the analyzer should leave you with three things: an honest UTF-8 byte count of the original HTML response body, a clear picture of where the weight lives inside that body, and a stable reference for whether the document sits comfortably inside, close to, or beyond the documented 2 MB boundary. From that point, every later measurement becomes a comparison rather than a guess, and every source change becomes a verifiable optimization rather than a hopeful one.
For a deeper look, see Extract Links From HTML: Source, Base URL, and Counts.