HTML 頁面權重與大小分析器會讀取您提供給它的原始碼，並回報該原始碼的位元組數，僅此而已。標題上的數字是針對所貼上內容的精確測量，不是對線上 URL 的估算，也不會擷取所引用的資源，因此任何會改變輸入內容的因素——被竄改的 DOM、最小化後的版本、不完整的 HTML，或在 JavaScript 執行後從 Elements 面板複製的內容——都會以難以察覺的方式改變結果。總數旁邊那個 2,000,000 位元組的比較值，是對 Google 目前 2 MB Googlebot 限制的保守主體參考值；這個工具看不到 HTTP 標頭、gzip 或 Brotli 壓縮、所引用腳本、樣式表、圖片或字型的位元組權重，也看不到實際進入 Google 索引的內容。每個失效模式都是從這三項事實衍生出來的：錯誤的輸入會產生錯誤的數字，該數字會與僅限於主體的門檻進行比較，而該門檻是一個會變動的參考值，而非永久的閾值或保證。將結果視同即時網路測量、Core Web Vitals 分數、壓縮計算器，或對爬蟲行為的預測，這才是分析出錯的原因，而不是分析器本身的問題。
數字是精確的，但僅針對您所貼上的內容
HTML 頁面權重分析器會使用瀏覽器的 TextEncoder API 將您貼上的文字轉換為 UTF-8 位元組，然後回報該位元組數、Unicode 碼點數、內嵌腳本與樣式文字所佔的比例、data URI 內部的位元組數，以及一份有界限的外部資源引用清單。這種程度的細節正是結果可以重複的原因；相同的原始碼在每次執行時都會產生相同的總數。其限制在於分析器不測量什麼。它不會從您的伺服器擷取任何東西，也不會從所引用的樣式表、腳本、圖片、框架、預載或媒體 URL 載入任何內容。瀏覽器的原生 HTML tokenizer 會走訪一個分離的 template 片段，這表示標記會被解析但不會附加到實際文件上，內部的任何 URL 都不會被請求。
這也是為什麼輸入一改變，結果就會跟著改變。標題上的總數追蹤的是該文字的位元組，而不是您訪客瀏覽器所下載的位元組。HTTP 標頭、gzip 或 Brotli 壓縮、個別擷取的資源酬載、後期的用戶端 DOM 變更，以及任何載入後的算繪工作，全都落在計算範圍之外。貼上的 script 元素不會執行，表單不會提交，而圖片、iframe、樣式表或腳本的 URL 也不會被請求——這些界線中的每一條，都是讓分析器保持安全、並限制它能告訴您多少內容的原因。
會產生誤導數字的輸入失效模式
大多數錯誤的答案都從錯誤的輸入開始。下方四種輸入失效模式，是在實際頁面權重工作中最常出現的，而且每一種都會在任何分析開始之前靜悄悄地改變標題上的總數。
在 JavaScript 執行後從 Elements 面板複製內容。Elements 分頁顯示的是當下的 DOM，其中包含了由框架水合、瀏覽器擴充功能、開發人員工具覆寫層，以及用戶端樣板引擎所注入的變更。這些位元組從未實際在網路上傳輸，因此會把總數推向伺服器從未送出的字元。View Source、已儲存的回應主體，或經授權的 curl 擷取，才是可信賴的輸入。
在您原本想要的是原始版本時，卻貼上了最小化或部分最小化的 HTML。最小化會移除空白字元並縮短識別符，進而降低位元組數。如果您正在偵錯的是部署後的回應，請貼上該回應——而不是您在編輯器中最初開始處理的原始碼。
包含了錯誤的變化版本，或漏掉了正確的變化版本。伺服器可能會根據使用者代理、地區設定、驗證、Cookie、A/B 分組或裝置類別，回傳不同的 HTML。一次貼上只會捕捉到一個變化版本；具代表性的回應必須分開測試，否則結論將會套用到這個工具從未觀察過的流量上。
將主體隱藏在包裝層之中。部分瀏覽器、代理伺服器與開發人員工具擴充功能，會在顯示之前將 HTML 包裝在註解、橫幅或水合 JSON blob 之中。如果包裝層的位元組存在於貼上內容中，它們就會被計算進去；如果被移除，結果就會在不知不覺中縮水。請讓貼上的內容與伺服器實際回傳的內容一致。
一個小型的編碼範例可以讓另一種失效模式更具體。ASCII 字元通常佔 1 個 UTF-8 位元組，帶腔調的字母佔 2 個，中文、日文和韓文字元佔 3 個，而大多數 emoji 佔 4 個。字串 "Aé中😀" 是 4 個碼點，但卻是 10 個 UTF-8 位元組——"A" 佔 1 個、"é" 佔 2 個、"中" 佔 3 個、"😀" 佔 4 個。在 CJK 比重高的頁面上，將「4 個字元」回報為頁面大小會低估主體；而回報「10 個位元組」才能重現實際傳輸的內容。
正確執行 HTML 頁面權重分析器，讓結果禁得起檢驗
以下是如何以日後禁得起檢驗的方式使用 HTML 頁面權重分析器的具體做法。
- 儲存原始的未壓縮 HTML 回應主體。請使用 View Source、經授權的 curl 擷取，或從部署記錄中儲存的回應檔案。避免在腳本執行後使用 Elements 面板。
- 將該文字貼到分析器中並執行分析。運算過程完全在本地進行，不會離開您的瀏覽器。
- 首先閱讀標題上的 UTF-8 位元組總數。接著閱讀 2,000,000 位元組的參考值、低於該值的剩餘位元組，或超過該值的溢量。這個參考值被標示為與 Google 目前每個 URL 2 MB 限制的保守主體比較，而非爬蟲保證。
- 將結果拆解來看。檢視內嵌腳本所佔比例、內嵌樣式所佔比例、data URI 位元組總數，以及有界限的外部資源清單。每一列都是獨立的偵錯介面。
- 找出原始碼層級最大的熱點。將內嵌腳本所佔比例與其他項目進行比較，尋找較長的 data URI 段落，或尋找重複的外部標籤。挑選位元組影響最大的那一項。
- 做出最小且誠實的變更。將嵌入的程式庫移至可快取的外部檔案、移除重複的序列化狀態 blob，或將 Base64 圖片從 data URI 中移出。避免更動無關的標記。
- 重新測量部署後的回應。從線上 URL 貼上新的未壓縮主體。確認位元組總數反映了這個變更，而不僅僅反映您編輯過的原始碼。
- 透過 DevTools、curl 或 Search Console，驗證分析器無法看到的周邊事實——回應標頭、壓縮下的傳輸大小、索引收錄的證據，以及算繪後的行為。
分析器是一張偵錯地圖，而不是判決書。請用它來找出最大的權重來源，然後在對爬取、索引或排名下結論之前，先檢查部署後的位元組。
解讀輸出結果，不要過度解讀
分析器會回傳一組數字與一份清單。將它們視為其他東西，就是下一輪失效的由來。
| 測量項目 | 它代表什麼 | 它不代表什麼 |
|---|---|---|
| UTF-8 位元組總數 | 所貼上原始碼的編碼後位元組長度 | gzip 或 Brotli 下的傳輸大小 |
| 內嵌腳本與樣式所佔比例 | 每個內嵌 script 或 style 元素內部的位元組數 | 外部託管的 JS 或 CSS 檔案的位元組數 |
| data URI 位元組 | 原始碼中顯示的完整屬性值 | 被計算兩次的解碼後 Base64 酬載 |
| 外部資源清單 | 所引用 URL 的有限清單 | 這些引用檔案被下載的大小 |
| 2,000,000 位元組參考值 | 對 2 MB Googlebot 限制的保守主體比較 | 爬取、排名或索引的保證 |
最常見的過度解讀是「低於 2,000,000 位元組就代表 Googlebot 會擷取整個頁面」。Google 目前的說明文件指出，2 MB 的配額適用於未壓縮的資料，而且 HTTP 標頭會佔用每個 URL 預算的一部分。分析器只能看到主體，因此它無法知道 Googlebot 實際會在哪裡停止。這個結果是透明的主體參考值，而不是認證——Google 的 Inside Googlebot 文章以及 Googlebot 說明文件才是該限制的權威來源，而這些頁面上的參考日期，比把這個數字視為常數更為重要。
第二種過度解讀是「外部資源清單顯示了我的頁面大小」。事實並非如此。連結的資源在 HTML 回應中只貢獻 URL 字元。Googlebot 與網頁算繪服務可能會分別擷取這些引用的資源，每個資源都有自己的限制，但分析器從不下載這些資源，也從不宣稱知道它們的大小。一份僅指向大型檔案的文件，在這項測量中並不算大型文件。
第三種過度解讀是「位元組數較小就保證排名較佳」。分析器不會測量壓縮、執行成本、算繪成本、快取行為，也不會測量實際被索引的內容。請將拆解結果視為修正的依據，然後另外驗證部署後的回應。
分析器無法告訴您的事
有必要明確指出這些界線。HTML 頁面權重分析器並不是以網路瀑布圖、壓縮計算器或 Core Web Vitals 測試的方式執行。它不知道 gzip 或 Brotli 的傳輸大小、伺服器標頭、快取行為、後期的用戶端 DOM 變更、所引用資源的回應大小、執行成本、算繪成本，也不知道 Google 實際索引了什麼內容。
針對上述每一項事實，請使用合適的工具。DevTools 的 Network 面板用於查看傳輸大小與資源拆解。對經授權的公開 URL 使用 curl，可取得原始回應標頭與未壓縮的位元組。Search Console 用於查看爬取、索引與算繪的證據。根據 Google 目前的 Googlebot 說明文件，2 MB 的配額適用於未壓縮資料，而 HTTP 標頭會佔用每個 URL 預算的一部分，這表示分析器僅針對主體的比較在本質上是保守的。UTF-8 位元組運算本身有明確的定義，並記載於 MDN TextEncoder 參考資料，因此標題上的總數是可靠的；標題總數與「Googlebot 收到了這個頁面」之間的差距，才是分析器無法彌補的部分。
一個實用的收尾習慣：在分析器標出熱點、且您做了最小且誠實的變更之後，再次貼上部署後的回應，確認新的位元組總數。如果您在 DevTools 中也能看到壓縮下的傳輸大小變小，並在 Search Console 中看到索引的算繪結果沒有改變，那麼這個變更就通過驗證了。如果這三項檢查中有任何一項與其他項不一致，請把這種不一致視為下一個要調查的對象——而不是分析器出了錯的跡象。