使用 HTML Page Weight Analyzer 時，大多數的錯誤，都來自貼錯了來源、讀錯了數字，或是把一項僅限本文（body）的量測結果，當成一整次完整爬取的保證。這個分析工具量測的，是你貼上去那段文字、以位元組計的 UTF-8 重量，把行內腳本、行內樣式，以及內嵌的資料 URI，跟外部參照分開，並把這個本文重量，拿去跟一個透明的、針對 Googlebot 的 2,000,000 位元組參考值做比較。它不會擷取你的網址、不會執行任何腳本、不會下載任何被參照的檔案，也不知道 HTTP 標頭的大小。因為這個工具回報的是位元組，而不是字元，帶重音符號的字母、中日韓文字，以及表情符號，都會以 JavaScript 字串長度不會呈現的方式，改變這個標題總數。因為這個本文總數，排除了外部檔案的負載，一個小小的 HTML 本文，仍然可能指向一個沉重的頁面。因為這條 2 MB 界線，是一個本文參考值，而不是一項認證，維持在這條線以下，並不能證明 Googlebot 會擷取整個回應。把這三個範疇——位元組、行內對外部，以及本文對完整擷取——當成三個各自獨立的概念來看待，正是區分一項有用量測與一項誤導性量測的關鍵。
HTML Page Weight Analyzer 量測什麼，又略過了什麼
在追查錯誤之前，先修正心智模型。HTML Page Weight Analyzer 只接受一種輸入：你貼進去的那段文字。它回報的每一項內容，都是從你瀏覽器中的那個字串推導出來的。根據MDN documentation for TextEncoder.encode()，這個編碼器產生的是 UTF-8 位元組，因此這個標題總數，反映的是一個回應本文通常是如何被傳輸的，而不是 JavaScript 字串如何計算字元數。這個剖析器，使用的是一個未附著的範本片段，以及瀏覽器原生的 HTML 詞元化器，這代表貼上去的 script 元素不會執行，表單不會送出，img、iframe、樣式表，或 script 的網址，也都不會被請求。
「我給了它文字，它量測的就是文字」——這個單一事實，排除了一長串的期待。這個工具從不宣稱知道實際線上頁面的大小、gzip 或 Brotli 傳輸後的大小、你的 CDN 快取行為、算繪成本，或是 Google 實際收錄了什麼。如果你需要以上任何一項，你需要的是 DevTools、對一個經授權的公開回應執行 curl，或是你自己的伺服器日誌，而不是這個分析工具。
五個貼上與剖析時常犯的錯誤，會讓結果失真
每一列，都把一個典型的使用者錯誤，跟正確的輸入或解讀方式配對在一起。在你信任分析工具顯示的數字之前，可以把它當成一份檢查清單來用。
| 常見錯誤 | 為什麼它會讓結果失真 | 正確做法 |
|---|---|---|
| 從瀏覽器的 Elements 面板複製 | 包含了算繪後的變動，並遺漏了原始回應中原本存在的來源細節。 | 改用「檢視原始碼」、一份儲存下來的回應本文，或一次經授權的 curl 擷取。 |
| 把標題數字當成字元數來讀取 | 瀏覽器公開的字串長度，是以 UTF-16 編碼單位計算的；回應本文則是以 UTF-8 位元組傳輸的，這兩者在帶重音字母、中日韓文字，以及表情符號上會出現落差。 | 把標題數字當成 UTF-8 位元組來看待，這正是編碼器產生出來的東西。 |
| 把外部檔案的大小，也算進本文總數裡 | 一個外部樣式表、腳本、圖片、框架、預先載入，或媒體參照，貢獻的只有出現在 HTML 中的那些字元而已。 | 使用分析工具的外部資源清單，標示出較重的參照，再分別為每一個被參照的檔案量測大小。 |
| 把一個資料 URI 解碼，並把解碼後的負載再加算一次 | 這些位元組，已經存在於屬性值之中；重複計算，會誇大標題數字，並扭曲資料 URI 所占的比例。 | 請信任分析工具對這個屬性值在原始碼中完整內容所做的量測。 |
| 把 2,000,000 位元組這條線，當成一項完整擷取的保證 | Google 目前的容許額度，包含 HTTP 標頭，這個上限適用於未壓縮的資料，而被參照的資源，是分開擷取的。 | 把這條線，當成一個透明的本文參考值，而不是一項爬取或收錄的承諾。 |
前三個錯誤，改變的是輸入內容或量測單位。第四個，改變的是資料 URI 的計算方式。第五個，改變的是這個結果被拿去怎麼使用。它們沒有一個是這個分析工具本身的錯誤；每一個，都是使用者在分析執行之前或之後所做的決定。
如何在 HTML Page Weight Analyzer 中得到可靠的量測結果
HTML Page Weight Analyzer 是為一種特定的輸入而打造的：一次擷取、完整貼上的原始未壓縮 HTML 回應本文。以下步驟，反映的是經過驗證的操作流程，並包含了能防止上述錯誤的防護措施。
- 擷取原始、未壓縮的回應本文。 在你的瀏覽器中，用「檢視原始碼」打開這個頁面，或執行一次經授權的 curl 擷取，例如 curl -s --compressed https://example.com/page > body.html，並驗證這份儲存下來的檔案。避免從 Elements 面板複製，因為那反映的是腳本執行之後的 DOM。
- 把完整的原始碼貼進分析工具。 開啟 HTML Page Weight Analyzer，貼上儲存下來的本文，並在執行分析之前，確認編輯器裡沒有內容被截斷。
- 執行分析並檢視報告。 讀取 UTF-8 位元組總數、低於 2,000,000 位元組本文參考值的剩餘位元組數、行內腳本與行內樣式各自所占的比例、資料 URI 的重量，以及有界限的外部資源清單。
- 找出最大的來源層級熱點。 很大的行內腳本位元組數，通常指向序列化的應用程式狀態、水合資料，或內嵌的函式庫。很大的行內樣式位元組數，通常指向被重複的關鍵 CSS。很大的資料 URI 總數，通常代表直接內嵌在標記語言中的 Base64 圖片或字型。
- 修正這個熱點，並重新量測部署後的回應。 把適合的程式碼，搬到可快取的外部檔案中，移除重複的序列化資料，避免把大型二進位負載內嵌成資料 URI，並把關鍵的中繼資料與內容，放在回應的前段。接著重新擷取、重新貼上，而不是重新檢查快取下來的結果。
- 在分析工具之外做驗證。 使用 DevTools 或 curl，確認部署後的位元組數、回應標頭、算繪後的頁面，以及任何收錄證據。這個分析工具給出的數字，是一張除錯用的地圖，而不是一個排名訊號。
讀取位元組報告時，別誤讀它
這份報告內容密集，有好幾個數值，乍看之下似乎可以互換，但其實不然。下面這張表，把分析工具實際量測到的項目，跟看起來相關、但其實落在它範圍之外的項目區分開來。
| 在分析工具的範圍之內 | 在分析工具的範圍之外 |
|---|---|
| 貼上的 HTML 本文的 UTF-8 位元組總數 | 實際線上回應的 gzip 或 Brotli 傳輸大小 |
| 貼上文字的 Unicode 碼點數量 | HTTP 回應標頭，以及它們貢獻的位元組數 |
| 行內腳本與行內樣式的位元組總數與百分比佔比 | 外部腳本、樣式表、圖片、框架、預先載入，以及媒體檔案的負載 |
| 內嵌資料 URI 屬性的位元組總數，只計算一次 | 這些資料 URI 解碼後的 Base64 負載，其實已經包含在屬性值中 |
| 一份有界限的外部資源參照清單 | Googlebot 在某個特定網址上，實際會在哪裡停止擷取 |
| 低於 2,000,000 位元組本文參考值的剩餘位元組數 | 跟這個參考值綁在一起的爬取、收錄，或排名保證 |
右邊那一欄，並不是一個缺陷。這個分析工具，維持嚴格的本機端運作；它不會從你的標記語言中，發出請求、執行、上傳，或送出任何東西。就像相關指南Does the HTML Weight Analyzer Fetch Your URL or Resources?詳細說明的那樣，這個剖析過程，是針對一個未附著的範本片段執行的，這也是為什麼巢狀範本內容，會保持不作用，並落在資源清單之外的原因。
2,000,000 位元組這個參考值，同樣值得謹慎對待。Google Search Central 目前記載的內容是，Googlebot 會爬取一個受支援檔案的前 2 MB，並在這個截止點停止擷取，而Inside Googlebot post中一段稍後的技術說明則補充道，HTTP 標頭會占用每個網址容許額度的一部分。因為這個分析工具只看得到本文，它無法知道實際回應標頭的大小，也無法證明 Googlebot 究竟會在哪裡停止擷取。為了做到透明且保守的計算，這個介面把 2 MB 標示為一個十進位的 2,000,000 位元組本文參考值，顯示低於它的剩餘位元組數，或超過它的超量部分，並讓標頭這個但書保持可見。這種設計背後更深一層的意涵——為什麼貼上的位元組數低於 2,000,000，仍然不能保證會被擷取——則在2,000,000 Pasted Bytes Do Not Guarantee a Googlebot Fetch中有所說明。
把這份拆解，變成真正的修正動作
這份拆解，是一張除錯用的地圖，而不是一個定論。用它來做初步分流，接著做出最小、最誠實的改動，再重新量測。行內腳本膨脹，通常指向重複的水合資料，或應該放進可快取外部檔案中的函式庫。行內樣式膨脹，通常指向在多個範本間重複出現、原本可以去重複化的關鍵 CSS。很重的資料 URI 總數，幾乎都代表一個 Base64 圖片或字型，如果改成用正常快取標頭、分開擷取的檔案，壓縮效果會更好。一份很長的外部資源清單，本身並不代表有效能問題；參照數量並不是一個分數。搭配的指南 HTML Page Weight: Are External File Sizes Included? 詳細說明了如何解讀這份清單，而不會把它跟負載位元組數混為一談。
一旦你開始改動程式碼，有兩道防護措施最重要。第一，如果伺服器的回應會依使用者代理、地區、身分驗證，或裝置而有所不同，請分別擷取並貼上具代表性的回應，因為這個分析工具，只會量測你給它的那份本文。第二，把這個分析工具給出的數字，當成一個起點，並用 DevTools、curl，或你自己的伺服器日誌，來確認部署後的回應。讓貼上的本文總數變小，是維持在接近 2 MB 這個參考值附近所必要的工作，但它本身，並不足以證明 Google 就會爬取、收錄，或為這個頁面排名。