The 2 MB limit means Googlebot stops fetching a supported file after reaching a 2 MB per-URL allowance, measured on uncompressed data, so an HTML document close to that boundary may be only partly fetched. In the HTML Page Weight Analyzer, this boundary appears as a conservative 2,000,000-byte reference for the pasted response body. It is a diagnostic comparison, not a pass/fail certificate: Google's allowance also consumes space for HTTP headers, while the analyzer can see only the body you paste. If the body is below 2,000,000 bytes, that does not prove Googlebot received every byte; if it is above, the body exceeds the analyzer's conservative body reference, but the exact point at which a live fetch stops still depends on the real headers and response. The tool does not fetch the URL, calculate compressed transfer size, or inspect what Google indexed. Its purpose is to show where a document's own source weight comes from—inline scripts, inline styles, embedded data URIs, and external-reference text—so you can reduce a genuine source-level hotspot and remeasure the deployed response.
What Googlebot's 2 MB boundary means
Google's published crawler documentation says Googlebot crawls the first 2 MB of a supported file and stops fetching at the cutoff. This is not a page-quality score, a ranking threshold, or a promise that content after 2 MB will be indexed. The limit applies to uncompressed data rather than a compressed transfer size. Google's technical explanation of the crawler limit also says HTTP headers use part of the per-URL allowance. A 2,000,000-byte body can therefore still exceed the live allowance once headers are counted, and a pasted-body tool cannot identify the exact stop point.
| What is measured | Googlebot's per-URL fetch | HTML Page Weight Analyzer |
|---|---|---|
| Uncompressed HTML body | Counts toward the fetch allowance | Measures the exact UTF-8 bytes in the pasted text |
| HTTP response headers | Consume part of the allowance | Cannot be measured from a pasted body |
| Content encoding | The limit concerns uncompressed data | Does not calculate gzip or Brotli transfer size |
| External files | May be fetched separately under their own limits | Lists references without downloading their payloads |
The analyzer consequently reports remaining bytes below its decimal body reference or overage above it while keeping the header caveat visible. These labels are conservative comparisons, not crawl certificates. Because Google can change limits, check the source and its date rather than treating 2 MB as a permanent constant. For the distinction in full, see why 2,000,000 pasted bytes do not guarantee a Googlebot fetch.
What the HTML Page Weight Analyzer measures
Use the HTML Page Weight Analyzer when you need to inspect a captured response rather than estimate a live page. It reports the exact UTF-8 byte length of the pasted text, its Unicode code-point count, the bytes and percentages occupied by inline script and style elements, embedded data URI bytes, and a bounded inventory of external resource references. Everything runs in the browser: the HTML is not uploaded, fetched as a page, or executed. Pasted scripts do not run, forms do not submit, and referenced image, iframe, stylesheet, or script URLs are not requested.
The byte total comes from the browser's TextEncoder.encode() method, not JavaScript string length. A browser string counts UTF-16 code units, while the analyzer counts UTF-8 bytes. ASCII characters usually occupy one UTF-8 byte, but accented letters, CJK text, and emoji can occupy more. The parser uses a detached template fragment and the browser's native HTML tokenizer, which helps it respect raw-text boundaries such as script, style, textarea, and title content. Nested template content remains inert and outside the resource inventory. A strict input limit, shared element cap, and bounded URL display protect the main thread and output from accidental full-site dumps or adversarial markup.
Measure an HTML response with the analyzer
- Capture the original response body. Prefer View Source, a saved response body, or an authorized curl capture rather than copying the Elements panel after JavaScript has run. The Elements panel can contain mutations that never appeared in the response and omit source details that did. An authorized curl capture can save the decoded body with a command such as curl --compressed -sS https://www.example.com/page/ -o response.html.
- Paste that uncompressed HTML body. Do not paste a full-site dump when you intend to diagnose one page. If the server varies its response by user agent, locale, authentication, or device, measure each representative variant separately.
- Run the analysis. The analyzer processes the pasted text locally and produces the byte total and source breakdown without requesting the page or its referenced resources.
- Review the complete breakdown. Check the total UTF-8 bytes, the 2,000,000-byte reference, inline script and style shares, embedded data URI weight, and the bounded list of external references.
- Fix the largest source-level hotspot. Start with the category consuming the most body weight rather than changing several unrelated parts at once. Make the smallest truthful change that addresses the main issue.
- Deploy and capture the response again. Remeasure the delivered HTML body after the change. Remember that real response headers and separately fetched resources remain outside this pasted-body calculation.
Interpret the body, inline weight, and references
The analyzer's figures describe the source you supplied, but each number answers a different question. Use the following distinctions to avoid treating the headline total as a complete account of page delivery.
| Analyzer output | Correct interpretation |
|---|---|
| Total UTF-8 bytes | Exact encoded weight of the pasted HTML body |
| Unicode code-point count | Number of Unicode characters, not bytes |
| Inline script and style weight | Source text inside those elements, counted in the body total |
| Data URI weight | The complete supported attribute value counted once; decoded payload bytes are not added again |
| External reference inventory | Reference text and tags only; linked file payloads are not downloaded or added |
| srcset handling | One declaration is preserved because naive comma splitting would mishandle data URLs |
An external stylesheet, script, image, frame, preload, or media reference contributes only the characters that appear in the HTML response. Googlebot and the Web Rendering Service may fetch those resources separately, with their own limits. The analyzer recognizes supported direct resource attributes, but it does not treat an arbitrary title or data-* attribute as a resource. A long external-reference inventory may reveal duplicate tags, although reference count by itself is not a performance score. Likewise, the displayed remaining-byte count is measured against the conservative body reference; it is not the exact balance of a live Googlebot request after headers.
Reduce the largest source-level hotspot
The breakdown is a debugging map. Large inline script bytes may point to serialized application state, duplicated hydration data, or embedded libraries. Large inline style bytes may indicate repeated critical CSS. Large data URI totals can reveal Base64 images or fonts embedded directly in markup. An extended external-reference list may expose duplicate tags, although each reference still contributes only its source text to this particular measurement.
After identifying the largest hotspot, make the smallest truthful correction. Move appropriate code to cacheable external files, remove duplicated serialized data, avoid embedding large binary payloads in data URIs, and place critical metadata and content early in the response. Externalizing code does not make its payload disappear: Google may fetch the new file separately. That is why the analyzer result should be combined with a review of the deployed response, its headers, and the resources it references.
Verify the deployed response separately
The analyzer is not a network waterfall, compression calculator, or Core Web Vitals test. It does not know the real gzip or Brotli transfer size, server headers, cache behavior, late client-side DOM mutations, resource response sizes, execution cost, rendering cost, or what Google actually indexed. Use browser DevTools or an authorized curl request when those facts matter, and verify the deployed bytes, response headers, rendered page, and available indexing evidence separately.
A smaller body can reduce exposure to the fetch boundary, but it does not guarantee complete crawling, indexing, or ranking. Likewise, a body above the reference does not prove that Google omitted important content because the exact cutoff depends on the live response and headers. The practical goal is to remove avoidable source weight while preserving useful content, metadata, and functionality, then confirm the result on a representative deployed response.
Related reading: Audit HTML Responses With an HTML Page Weight Analyzer.