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 計算，而不是容易誤導的字元數。細部分析也包含內嵌腳本、內嵌樣式、data URI 所佔的位元組比例，以及一份有限範圍的外部資源引用清單。
在評估這類工具時，有三個特性值得注意。第一，它量測的是貼上的文字，而不是即時 URL。它不會抓取、不會執行，也不會上傳；HTML 是在一個分離的樣板片段中解析，所以腳本不會執行、表單也不會送出。第二，它會把本文與一個標示為 2,000,000 位元組的參考值對照——這個值是對 Google 目前文件記載之每 URL 2 MB Googlebot 上限的保守十進位讀數；這是參考值而非認證，這也是為什麼 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 Page Weight Analyzer
如果五項檢查指向「是」，量測本身只需三個步驟。
- 貼上原始未壓縮的 HTML 回應本文。優先使用「檢視原始碼」、已儲存的回應本文，或經授權的 curl 擷取。避免在 JavaScript 執行後從 Elements 面板複製，因為它可能包含原本回應中沒有的變動，也會省略原本的原始碼細節。如果伺服器會依使用者代理程式或地區而異，請分別儲存並量測每一份具代表性的回應。
- 執行分析並檢視細部結果。HTML Page Weight Analyzer 會回報總 UTF-8 位元組數、Unicode 碼點數、內嵌腳本與樣式所佔比例、data URI 權重，以及有限範圍的外部資源清單。請將位元組總數與標示為 2,000,000 位元組的參考值比較，記得注意標頭中的但書：該參考值是 Google 文件記載之 2 MB 上限的「僅限本文」十進位讀數。
- 修正最大宗的原始碼熱點並重新量測。把細部結果當作除錯地圖。大量內嵌腳本位元組可能指向序列化狀態或內嵌函式庫。大量內嵌樣式位元組可能代表重複的關鍵 CSS。較大的 data URI 總和可能代表直接嵌在標記中的 Base64 圖片或字型。做出最小且真實的變更，重新量測部署後的回應，並驗證渲染後的頁面與索引證據，而不是預設「數字變小就保證檢索、索引或排名一定改善」。
請記住：計算範圍僅限貼上的文字。HTTP 標頭、壓縮、分別抓取的資源，以及任何用戶端 DOM 變動，依設計都不在這個數字之內。
解讀結果以決定下一步要修什麼
細部分析是一張除錯地圖，不是效能分數。請用來決定下一個變更，然後重新量測。
| 結果中的訊號 | 通常指向什麼 | 優先嘗試的方向 |
|---|---|---|
| 內嵌腳本位元組佔比偏高 | 序列化狀態、水合承載內容、內嵌函式庫 | 將可快取的程式碼移到外部檔案，去重複序列化資料 |
| 內嵌樣式位元組佔比偏高 | 重複的關鍵 CSS、框架注入的樣式 | 將可重複使用的規則抽出到外部樣式表 |
| data URI 總和偏高 | 直接嵌在標記中的 Base64 圖片或字型 | 將二進位承載內容另外託管，再以引用方式使用 |
| 外部資源清單過長 | 重複的標籤、多餘的 preload、臨時拼湊的引用 | 稽核重複引用；引用次數本身不是效能分數 |
| 本文接近或超過 2,000,000 位元組參考值 | 文件本文逼近 Googlebot 文件記載的本文上限 | 把程式碼與資料移出本文，把關鍵詮釋資料和內容放在前面，然後重新量測部署後的回應 |
每一列都是一個除錯方向，不是定論。做出最小且真實的變更，重新量測部署後的回應，並透過 DevTools 或 Search Console 確認這個變更是否真的移動了你關心的數字。
這個量測無法告訴你的事
一旦你拿到位元組總數，許多相鄰的問題仍沒有答案。這個分析工具刻意只做一件事，而這些限制也是這個數字值得信賴的部分原因：
- 壓縮。以貼上為基礎的工具無法得知 gzip 或 Brotli 的傳輸大小。當傳輸大小很重要時，請以 DevTools 或對經授權的公開回應使用 curl。
- HTTP 標頭。標頭會佔用 Google 每個 URL 額度的一部分，且不在貼上的本文中。2,000,000 位元組參考值依設計就是僅限本文。
- 外部資源大小。從本文中引用到的樣式表、腳本、圖片、框架、preload 與媒體只會被列出，不會被下載，且僅以它們的標籤和 URL 字元計入本文總計。
- 渲染與執行成本。位元組大小不是執行期指標。兩份位元組相同的文件，解析或水合成本可能差異極大。
- 索引與排名結果。本文低於標示的參考值，並不保證 Google 一定檢索、索引或排名了該頁。請把這個參考值視為除錯訊號，而非認證。
當決策是「我想檢查的變數就是文件本文」時，HTML 頁面權重分析工具就切合這個問題。當變數是別的東西時，就選擇為那個變數而生的工具。這就是整個決策。