使用 HTML 頁面權重分析工具時，最大的錯誤就是貼上的標記與伺服器實際傳送的位元組不一致，因為分析工具回報的每一個數字——總 UTF-8 位元組、內嵌腳本與樣式所佔比例、data URI 權重，以及與 2 MB Googlebot 門檻的比較——都是根據你提供給它的原始文字計算，而非來自即時擷取。像 HTML Page Weight Analyzer 這類現代分析工具會透過瀏覽器的 TextEncoder API 來衡量你貼上的原始碼，並把貼上的字串視為一個獨立、不會執行的 HTML 片段，既不會執行、也不會提交，也絕對不會向其中的標籤發出任何請求。這項設計選擇讓「輸入內容」成為整個量測結果的唯一依據，這也表示只要在輸入階段出了錯，這個錯誤就會一路傳遞到下游所有的百分比與位元組標籤。從渲染後的 Elements 面板複製、貼上部分壓縮過的 bundle、混入來自錯誤建置版本的存檔，或在貼上時漏掉了伺服器實際有送出的 HTML，都會在沒有任何警告的情況下悄悄改變總數。學會取得正確的輸入來源、把位元組標籤視為 UTF-8 而不是字元數，並把 2,000,000 位元組的內文參考值當作一個標示點、而非保證，就能解決人們一次又一次反覆犯下的大部分錯誤。
讓每個數字失真的來源錯誤
你貼上的 HTML 就是分析工具實際量測的文件內容。任何「你貼上的內容」與「伺服器實際送出的內容」之間的落差，都會讓接下來這次分析的其餘結果淪為虛構。
最常見的來源錯誤，是在 JavaScript 執行後才從瀏覽器的 Elements 面板抓取標記。Elements 反映的是當下的 DOM，這代表它可能包含那些原本不在回應內容中、由執行階段注入的變更——例如 hydration 外殼、動態插入的標籤、稍晚才出現的片段——同時也可能漏掉原始碼中的部分細節，因為這個面板會重新排版，有時還會將屬性內聯。對於一次分析工具的檢測而言，「檢視原始碼」、一份已儲存的回應內文，或是對公開回應執行一筆授權過的 curl 擷取，都會是更好的輸入。
第二個來源錯誤，是假設伺服器對每一位訪客都回傳相同的內容。許多網站會根據使用者代理、語系、驗證狀態、裝置類型或功能開關，回傳不同的內容。請為每一個重要的變體分別測試其具代表性的回應，而不是只貼上一次單一內文就概括地做判斷。
第三個來源錯誤，是把建置階段的 bundle 當作實際傳輸的內容。Bundler 與樣板引擎會額外加入 wrapper、註解與 source map，這些內容根本不會送到瀏覽器。請貼上實際傳送的位元組，而不是原始碼。
把 UTF-8 與字元混淆的位元組計算錯誤
位元組不等於字元，而分析工具最顯眼的數字是位元組，不是字元數。
HTML Page Weight Analyzer 透過瀏覽器的 TextEncoder API 回報 UTF-8 位元組，即計算貼上文字經編碼後的位元組長度。ASCII 字元通常佔 1 個 UTF-8 位元組，但帶有變音符號的字母、CJK 文字與 emoji 則會擴展成多個位元組。相對地，JavaScript 字串計算的是 UTF-16 code unit。只要文件包含非 ASCII 內容，這兩種量測結果就會開始分歧。
這裡常見的錯誤，是把分析工具的總數當作字元數來讀，並拿它與「200 萬字元」的預期相比，然後得出文件其實小很多的結論。一份含有大量 emoji 或 CJK 內文的文件，實際大小可能遠比其字元數所暗示的要大好幾倍。MDN 關於 TextEncoder.encode() 的文件說明了這個工具所使用的編碼行為，把這個標籤視為權威依據，就能避免大多數這類錯誤。
另一個相關的錯誤，是把分析工具的總數當作實際傳輸的大小。貼上的內文是未壓縮的。實際的傳輸大小取決於伺服器協商出來的 gzip 或 Brotli，而分析工具看不到那些位元組。當你需要的是實際傳輸量時，請改用 DevTools 或加上正確 Accept-Encoding 的 curl。
2 MB Googlebot 門檻周邊的參考值錯誤
2,000,000 位元組的內文參考值是一個保守的十進位標示點，並非認證標章。
Google 目前的官方文件指出:Googlebot 只會擷取支援檔案類型的前 2 MB，並在達到上限時停止抓取;此限制適用於未壓縮的資料;而 HTTP 標頭會佔用每個 URL 配額的一部分。分析工具只能收到你貼上的內文，因此它既無法得知真實回應標頭的大小，也無法證明 Googlebot 實際會在哪裡停下來。介面上將 2 MB 標示為一個十進位的 2,000,000 位元組內文參考值，目的在於讓這項比較透明且保守，並且保留一個明顯的標頭警示，讓這個數字不會被誤認成保證。Google 自身的後續說明已確認標頭會計入配額，這也解釋了為什麼內文位元組完全相同的兩個回應，可能會落在上限的兩側。
要避免的錯誤，是把「少於 2,000,000 個貼上位元組」當作 Google 已收到整個分頁的證明。僅看內文的檢視方式無法涵蓋標頭位元組、伺服器端壓縮、Web Rendering Service 另行擷取參考資源，或未來此限制文件的變更。Google 也提醒限制可能會變動，因此來源連結與參考日期的重要性，遠超過把這個數字視為永恆不變的常數。請把這條線當作偵錯用的標示，而非契約。
第二個參考值錯誤，是假設 2 MB 規則也適用於被參考的資源。每一個外部樣式表、腳本、圖片與字型，都是各自在它自己的配額下被獨立擷取。分析工具會列出這些參考項目，但不會實際下載它們，因此它無法告訴你其中任何一項離它自己的上限有多接近。
如何在不踩雷的情況下跑一次分析
以下是一套經得起檢驗的分析實作流程。
- 擷取原始、未壓縮的 HTML 回應內文。請使用「檢視原始碼」、一份已儲存的回應內文，或對公開回應執行授權過的 curl 擷取。除非你明確想要量測的是 hydrated 後的 DOM，否則請避開渲染後的 Elements 面板。
- 在 HTML Page Weight Analyzer 中執行分析。此工具會在一個獨立的 HTML 片段中解析文字，不會執行腳本、不會提交表單，也不會對它所發現的任何 URL 發出請求，並透過瀏覽器的 TextEncoder API 計算 UTF-8 位元組。
- 將最顯眼的總數視為 UTF-8 位元組。同時另外記下 Unicode code point 的數量。位元組總數才是 2 MB 參考值用來比較的對象;code point 數量只是輔助偵錯，並非傳輸量測。
- 檢視內嵌腳本與樣式所佔比例、data URI 權重，以及界定的外部資源清單。留意內嵌樣式中重複出現的關鍵 CSS、內嵌腳本中序列化的應用程式狀態或 hydration 區塊，以及 data URI 中的 Base64 圖片或字型。
- 以最小、最真實的變更修掉最大的原始碼層級瓶頸。將適合的程式碼搬移到可快取的外部檔案、移除重複的序列化資料、避免將大型二進位內容嵌入 data URI，並把關鍵的中繼資料與內容放在回應較前面的位置。
- 在改動後，重新量測已部署的回應。請對公開的回應，而不是對本地建置，重複一次擷取步驟，以確保量測結果反映伺服器今天實際送出的內容。
如果經過乾淨的重新量測後結果仍看起來不對勁，這份修正分析結果失真的指南會更詳細地說明輸入與解析器的檢查步驟。
把較小的數字當作結論的修補後錯誤
較小的貼上位元組總數，本身並不構成排名、抓取或索引的訊號。
在瓶頸被縮小後，很容易就想就此打住。分析工具只能告訴你貼上的內文裡有什麼。它無法告訴你:在加上標頭後，已部署的回應是否仍會超過上限;Web Rendering Service 能否順利擷取參考資源;gzip 或 Brotli 在實際傳輸時是否真的有協商成功;或 Google 是否真的已索引該分頁。請使用 DevTools 或對授權過的公開回應執行 curl 來確認傳輸量、回應標頭與實際渲染行為，並到 Search Central 查看索引狀態的證據，而不是把分析工具的數字當作判決。
第二個修補後的錯誤，是從一個瓶頸修到下一個，中間沒有重新量測。每次變更後，請重新執行一次擷取並再跑一次分析。一次使用過時輸入的分析，可能會掩蓋先前某次編輯所引入的退步，尤其在建置流程改寫了空白、註解或屬性順序時更是如此。
第三個修補後的錯誤，是把外部資源清單讀成效能分數。一長串的 preload 標籤、srcset 宣告或樣式表連結，是一張偵錯地圖，而不是判決。光是參考的數量，無法說明抓取成本、快取或執行情況。分析工具列出這些參考項目，目的在於幫助你區分「一份沉重的文件」與「一份只是指向沉重檔案的文件」，而 外部檔案大小指南會說明為什麼這些參考不會讓貼上的內文總數膨脹。
| 分析工具實際量測的內容 | 不會列入貼上內文總數的部分 |
|---|---|
| 貼上回應內文的 UTF-8 位元組 | HTTP 回應標頭(協商與實際傳輸的部分) |
| 同一段文字的 Unicode code point 數量 | gzip 或 Brotli 壓縮後的傳輸大小 |
| 內嵌腳本與樣式文字，以 UTF-8 位元組計算 | 外部腳本、樣式表、圖片、字型、框架的位元組 |
| 完整的 data URI 屬性值，以 UTF-8 位元組計算 | 解碼後的 Base64 內容(會造成來源位元組重複計算) |
| 外部資源的參考:標籤、URL、屬性 | 這些被參考資源本身的回應大小 |
| 與 2,000,000 位元組十進位內文參考值的距離 | 任何 Googlebot 已收到完整文件的保證 |