HTML 頁面權重分析工具只解決一個很窄的問題：貼上的 HTML 回應主體有多大（以 UTF-8 位元組計算），以及該主體與 Googlebot 文件記載的每個 URL 2 MB 擷取上限相差多少。當你懷疑問題出在「文件本身」，而不是網路、不是渲染後的頁面、也不是另外擷取的資源，導致檢索、索引或首位元組時間出狀況時，就應該使用它。決策規則比看起來更簡單：如果你的問題是伺服器回傳的原始標記位元組，那麼像 HTML Page Weight Analyzer 這類分析工具能提供透明、本地的測量。如果你的問題是傳輸大小、gzip 或 Brotli 壓縮、包含圖片和腳本在內的整體頁面權重，或是像 Core Web Vitals 這類即時效能指標，那麼這個類別的工具就不是正確的起點。當你想檢視的是文件主體本身時，使用分析工具；若不是，則改用 DevTools、curl 或網路瀑布圖。本文接下來會帶你走過決策清單、工具會回報哪些內容，以及一旦確定合適後該如何解讀結果。
分析工具會測量什麼（以及忽略什麼）
HTML 頁面權重分析工具是一種貼上後即可測量的工具。你複製原始的未壓縮 HTML 回應主體（通常來自「檢視原始碼」或經授權的 curl 擷取），工具便會回傳這段確切文字的細項統計。首要數字是 UTF-8 位元組總數，並使用瀏覽器的 TextEncoder 計算，而非容易誤導的字元數。統計內容還包含行內腳本、行內樣式、資料 URI，以及有限範圍的外部資源參考所佔的位元組比例。
評估這個類別的工具時，有三個特性值得注意。第一，它測量的是貼上的文字，而不是即時 URL。它不會擷取、執行或上傳任何內容；HTML 會在隔離的樣板片段中解析，因此腳本不會執行、表單也不會送出。第二，它會將主體與一個 2,000,000 位元組的參考值進行比較，該值標示為對 Google 目前文件記載的 Googlebot 每 URL 2 MB 上限的保守十進位讀數；這只是參考，並非認證，這正是為什麼2,000,000 貼上位元組並不保證 Googlebot 一定會擷取。第三，HTTP 標頭、壓縮以及外部檔案負載都不納入計算。首要數字僅計算原始的回應主體。
五項檢查，告訴你何時需要這個分析工具
請依序檢查以下五項。如果超過一項符合你的情況，那麼 HTML 頁面權重分析工具就是正確的下一步。
- HTML 文件本身感覺太大。症狀包括首位元組時間緩慢、伺服器回應過於龐大，或標記中明顯含有序列化狀態、水合資料或嵌入的函式庫。
- 你正在依 Googlebot 的 2 MB 上限進行稽核。分析工具會以透明的十進位參考值顯示剩餘位元組或超出量，適用於你想檢視的正是文件主體這個邊界。
- 你需要一個不依賴即時擷取的測量方式。如果你的伺服器會依使用者代理、地區、認證或裝置而產生不同結果，貼上型的方式讓你能視需要測量某個已儲存的特定回應。
- 你想把行內程式碼與外部參考分開來看。統計結果能區分「標記本身就肥大」與「文件只是指向肥大的檔案」，這在你需要決定是把程式碼移出主體，還是精簡被參考的資產時特別有用。
- 你需要一個在本機執行、不上傳任何資料的測量方式。貼上的 HTML 完全不會離開本機，這對於預備環境、內部工具或處於禁運狀態的內容來說很重要。
何時其他工具更合適
HTML 頁面權重分析工具回答的是文件主體的問題。許多相關的問題其實能由其他工具更直接地回答，而辨識這個界線本身就是做出正確決定的一部分。
| 你真正想問的問題 | 為何這個分析工具是錯誤的選擇 | 更好的起點 |
|---|---|---|
| gzip 或 Brotli 壓縮後的線上傳輸大小是多少？ | 這個工具測量的是貼上主體的未壓縮 UTF-8 位元組，而不是編碼後的網路大小。 | 瀏器 DevTools 的 Network 面板、使用 --compressed 的 curl，或傳輸大小檢查工具 |
| 頁面載入的圖片、腳本和樣式表有多大？ | 外部資源僅依 URL 與標籤列管，並非以檔案大小計算；它們的負載位元組不計入主體總和。 | 網路瀑布圖測試或逐資源稽核 |
| Largest Contentful Paint 或其他 Core Web Vitals 分數是多少？ | 分析工具測量的是位元組，而非渲染或執行成本。 | Lighthouse 或 Search Console 的現場資料 |
| Google 究竟有沒有檢索並索引我的網頁？ | 主體小於 2,000,000 位元組只是一個透明參考值，並不代表擷取或索引的結果。 | Search Console 的 URL 檢查功能和檢索紀錄 |
如果你真正想問的問題出現在這個表格中，請先執行對應的工具。當你想隔離的變數是文件主體本身時，分析工具才會在稍後派上用場。
決定之後，如何使用 HTML 頁面權重分析工具
如果五項檢查都指向「是」，那麼測量本身只需要三個步驟。
- 貼上原始的未壓縮 HTML 回應主體。建議使用「檢視原始碼」、已儲存的回應主體，或經授權的 curl 擷取結果。避免在 JavaScript 執行完後從 Elements 面板複製，因為它可能包含原始回應中沒有的變更，並省略原始回應中曾有的細節。如果伺服器會依使用者代理或地區產生不同結果，請分別儲存並測量每個具代表性的回應。
- 執行分析並檢視細項統計。HTML Page Weight Analyzer 會回報 UTF-8 位元組總數、Unicode 碼點數、行內腳本與樣式所佔比例、資料 URI 的權重，以及有限範圍的外部資源清單。請將位元組總數與標示為 2,000,000 位元組的參考值進行比較，並留意該參考值是 Google 文件記載之 2 MB 上限「僅限主體」的十進位讀數這一前提。
- 修正最大的原始碼層級熱點並重新測量。把細項統計當作除錯地圖。龐大的行內腳本位元組可能指向序列化狀態或嵌入的函式庫。龐大的行內樣式位元組可能代表重複的關鍵 CSS。龐大的資料 URI 總和可能意味著有 Base64 圖片或字型直接嵌在標記中。做出最小且真實的修改，重新測量已部署的回應，並以渲染後的頁面與索引證據來驗證，而不要假設數字變小就一定代表檢索、索引或排名會改善。
請記住，這個計算僅限於貼上的文字。HTTP 標頭、壓縮、分別擷取的資源，以及任何客戶端的 DOM 變更，依設計都不在這個數字之內。
解讀結果，以決定下一步該修什麼
細項統計是除錯地圖，不是效能分數。請用它來選擇下一個改動，然後重新測量。
| 結果中的訊號 | 通常代表什麼 | 可以先嘗試的方向 |
|---|---|---|
| 行內腳本位元組佔比偏高 | 序列化狀態、水合負載、嵌入的函式庫 | 將可快取的程式碼移到外部檔案，去除重複的序列化資料 |
| 行內樣式位元組佔比偏高 | 重複的關鍵 CSS、框架注入的樣式 | 將可重複使用的規則抽到外部樣式表 |
| 資料 URI 總和偏高 | Base64 圖片或字型直接嵌在標記中 | 將二進位負載另外託管，再用參考方式引入 |
| 外部資源清單很長 | 重複的標籤、多餘的 preload、臨時性的參考 | 稽核重複的參考；參考數量本身並非效能分數 |
| 主體接近或超過 2,000,000 位元組參考值 | 文件主體逼近 Googlebot 文件記載的主體上限 | 將程式碼與資料移出主體，將關鍵中繼資料與內容提前，然後重新測量已部署的回應 |
每一列都是一個除錯方向，而不是結論。做出最小且真實的修改，重新測量已部署的回應，並透過 DevTools 或 Search Console 確認改動確實移動了你真正在意的那個數字。
這項測量無法告訴你的事
即使得到位元組總數，許多相關的問題仍未被回答。這個分析工具刻意只涵蓋狹窄範圍，而這些限制正是這個數字值得信賴的原因之一：
- 壓縮。貼上型工具無法得知 gzip 或 Brotli 的傳輸大小。當傳輸大小很重要時，請針對經授權的公開回應使用 DevTools 或 curl。
- HTTP 標頭。標頭會佔用 Google 每個 URL 額度的一部分，並不在貼上的主體內。2,000,000 位元組參考值依設計標示為僅限主體。
- 外部資源大小。樣式表、腳本、圖片、框架、preload 和媒體雖然會在主體中被列出，但永遠不會被下載，它們在主體總和中只貢獻標籤與 URL 字元。
- 渲染與執行成本。位元組大小不是執行期的指標。兩個位元組總數相同的文件，其剖析或水合成本可能截然不同。
- 索引與排名結果。主體小於標示的參考值，並不保證 Google 已檢索、索引或排名該頁。請把這個參考值視為除錯訊號，而非認證。
當決策是「我想檢視的變數是文件主體」時，HTML 頁面權重分析工具就切合這個問題。當變數是別的東西時，就選擇為該變數而生的工具。這就是完整的決策。
如果你正在權衡各種選項，記錄使用 HTML 頁面權重分析工具的步驟對此有更詳細的說明。