設定一個可重複執行、經得起檢視的 HTML 頁面權重分析器 流程，代表要把它從單次點擊的檢查，轉變為一個五個階段的測量工作流程，而非一次性的點擊操作。該流程仍包含相同的五個階段——擷取原始未壓縮的 HTML 回應主體、對該貼上的內容執行分析器、依據 Googlebot 的 2 MB 參考值讀取 UTF-8 位元組總量以及內聯、data URI 與外部參考的細部分析、修正最大的來源級熱點，然後重新測量實際部署的回應——不過每個階段的存在，是因為下一個階段會依賴它。貼上錯誤的來源會使所有下游數字失真；忽略標頭與壓縮的注意事項，會把一個透明的主體讀數變成虛假的擷取保證；而重新貼上已縮減的草稿而非部署的回應，則會隱藏你真正需要修正的熱點。分析器完全在瀏覽器中執行，會在獨立的 template fragment 中解析貼上的文字，不會擷取或執行它，並透過瀏覽器的 TextEncoder API 回報 UTF-8 位元組數。這三項特性——僅限本機解析、瀏覽器等級的 UTF-8 測量，以及僅限主體的參考值——是設定中每個步驟都必須遵守的限制。在打開工具之前，請利用本文將這些限制明確記錄下來，讓每次貼上、點擊與重新測量都能回答一個經過深思的問題，而非製造雜訊。
一個良好的設定檢查清單應承諾的內容
在貼上任何內容之前，設定應將五項決策明確記錄下來。第一，命名你打算測量的確切回應——公開的 HTML、地區語系變體、經身分驗證的變體，或是經 JavaScript 算繪的快照——並從中擇一。第二，命名與該決策相符的擷取方法：公開 HTML 使用「檢視原始碼」；瀏覽器未顯示的變體使用經授權的 curl 擷取；離線檢視使用儲存的回應主體。第三，同意標題數字將採用 UTF-8 位元組，而非 JavaScript 字串長度，也非傳輸大小。第四，同意 2,000,000 位元組的參考值是僅限主體的十進位比較，而非 Googlebot 將擷取整份文件的認證證明。第五，同意重新測量的觸發條件：部署 HTML 的變更，而非本機草稿的變更。將這五項承諾寫入設定，能把分析器從一個一次性的小工具，轉變為一個測量儀器；當數字出現爭議時，也能為其他人留下一份書面紀錄。
如果你想要一份更簡短的起飛前檢查清單，記錄步驟工作流程 說明了書面檢查清單如何保護每次流程，避免擷取之間發生隱而不宣的來源漂移。
先擷取正確的回應主體
擷取是最容易讓後續所有數字失效的步驟。分析器測量的是你貼上的內容，而非即時 URL，因此貼上內容的品質就是結果的品質。首選的輸入是來自「檢視原始碼」所取得的原始未壓縮 HTML 回應主體、儲存的回應主體，或是對公開 URL 進行經授權的 curl 擷取結果。請避免在 JavaScript 執行後使用 Elements 面板。該檢視可能包含回應中未曾出現的變更，也可能省略原本存在的來源細節。如果伺服器會依使用者代理、地區語系、身分驗證或裝置類別而產生不同回應，請為每個具代表性的回應分別規劃貼上作業，因為單一貼上會平均掉真實的差異，並隱藏真正超出預算的變體。
設定中還應加入另外兩條擷取規則。分析器絕不會下載被參考的資源，因此任何外部樣式表、指令碼、影像、frame、preload 或媒體參考，只會將其 URL 字元計入貼上的總量——而非該檔案的實際內容。請將外部參考的清單視為一份清單來閱讀，而非視為一項權重。並請預期標題總量將使用 UTF-8 位元組，其中 ASCII 字元通常是一個位元組，但帶有腔調的字母、CJK 文字與 emoji 每個都會佔用一個以上的位元組。一份在文字編輯器中看起來很短的文件，在分析器中讀起來可能很大，正是基於這個原因。
依正確順序執行分析器
一旦貼上內容準備就緒，流程本身應遵循一個固定的順序。請將這個順序視為設定的一部分，而非只是建議。
- 開啟 HTML 頁面權重分析器，並將擷取到的回應主體貼入輸入區域。請勿貼上片段、摘要或重建後的標記。
- 執行分析並等待結果檢視算繪完成。分析器會在獨立的 template fragment 中解析貼上的內容，因此貼上的指令碼不會執行，被參考的 URL 也不會被請求。
- 首先讀取標題總量。確認它是以 UTF-8 位元組表示，並分別確認底層的程式碼點 (code point) 數量，以便一眼看出 UTF-16 與 UTF-8 之間的混淆。
- 接著讀取內聯指令碼與內聯樣式的占比，然後是 data URI 的位元組總量，再來是受限的外部資源清單。順序很重要，因為內聯指令碼或 data URI 中的熱點，通常比隱藏在外部檔案清單中的熱點更容易修正。
- 將標題總量與 2,000,000 位元組的主體參考值進行比較，並記下剩餘的位元組或超出量。請將此參考值視為僅限主體的十進位比較，而非 Googlebot 的擷取保證。
- 記錄此次流程的擷取方法、變體、日期與結果數字，以便下一次重新測量有基準可循。
依據 2 MB 參考值解讀結果
解讀步驟正是設定能發揮價值的地方。分析器會回報五類數字——UTF-8 位元組總量、Unicode 程式碼點、內聯指令碼與樣式占比、data URI 位元組，以及受限的外部參考清單——每一類都回答一個不同的問題。UTF-8 位元組總量能告訴你回應主體是否接近 Googlebot 的文件化限制。程式碼點能幫助你抓出某些看似便宜、實際上卻在悄悄推升位元組總量的字元，例如 emoji 或帶有腔調的產品名稱。內聯指令碼與樣式占比能告訴你這份文件是否將序列化的應用程式狀態、重複的 hydration 資料、嵌入的程式庫或重複的關鍵 CSS 拖入回應主體中。data URI 位元組能告訴你這份文件是否將 Base64 影像或字型直接嵌入標記——這會使來源膨脹，即使它移除了網路請求。外部參考清單則能告訴你這份文件要求瀏覽器擷取多少個不同的 URL，而非這些 URL 的大小。
| 類別 | 它計算的內容 | 它刻意忽略的內容 |
|---|---|---|
| UTF-8 位元組總量 | 由瀏覽器的 TextEncoder API 所測得的貼上回應主體。 | HTTP 回應標頭、gzip 或 Brotli 傳輸大小，以及貼上內容中未出現的任何資源。 |
| 內聯指令碼與樣式占比 | 每個內聯指令碼或樣式元素內部的文字，以 UTF-8 位元組與占整份貼上內容的百分比表示。 | 外部 script src 的值，以及外部樣式表的連結。 |
| data URI 位元組 | 每個受支援的 data: 參考的完整屬性值，僅計算一次。 | 解碼後的 Base64 內容，以避免重複計算已存在於來源中的位元組。 |
| 外部資源清單 | 來自常見影像、媒體、frame、樣式表、preload 與外部指令碼屬性的受限 URL 清單，加上保留的 srcset 宣告。 | 每個被參考檔案的內容大小；分析器絕不會下載這些檔案。 |
| 2,000,000 位元組參考值 | 符合 Google 文件化 2 MB 每 URL Googlebot 容量的保守十進位主體參考值。 | 標頭位元組、壓縮、個別擷取的資源，以及索引結果。 |
舉例而言，如果一份貼上的主體測得為 1,873,420 個 UTF-8 位元組，則低於參考值的剩餘位元組為 2,000,000 − 1,873,420 = 126,580 個位元組。這是一個有用的規劃數字，但設定中必須一併記錄對應的標頭注意事項：Google 的文件指出此限制適用於未壓縮的資料，且標頭會佔用每 URL 容量的一部分，因此一份能完全容納於 2,000,000 位元組內的主體，一旦加入標頭，仍可能越過實際的界線。
規劃修正與重新測量的循環
設定的最後一個階段，是將測量轉化為行動與驗證。第一個決策是先修正哪個熱點，規則是修正回應主體中最大的來源級熱點，而非外部參考清單中最大的數字。來源級熱點存在於貼上的內容內，因此下一次重新測量將能直接看到變更。外部參考熱點則存在於分析器不會下載的檔案中，因此即使頁面實際上變快了，重新測量貼上的內容也不會讓數字產生變化。
在分析器中能直接以位元組節省呈現的典型來源級修正包括：將內聯指令碼移至可快取的外部檔案、移除重複的序列化 hydration 資料、將單一過大的內聯樣式區塊拆分為關鍵 CSS 檔案加上延遲載入的樣式表，以及將大型 Base64 data URI 替換為同源的影像或字型 URL。每次修正之後，必須重新測量部署的回應，而非本機草稿，且必須使用相同的擷取方法，將部署的主體與相同的 2,000,000 位元組參考值進行比較。如果你想針對最常見的漂移來源設定一道防護機制，會扭曲 HTML 頁面大小分析器結果的常見錯誤 這份指南與這個循環搭配得當，因為它會明確指出會產生誤導性下降結果的輸入。
只有當部署的主體遠低於參考值且有足夠的標頭餘裕、當內聯占比與 data URI 總量符合設計意圖、且當外部資源清單反映的是實際頁面而非開發階段的殘留內容時，這個循環才算結束。分析器絕不會聲稱頁面將因此被擷取、建立索引或排名；相關證據仍然必須來自 Search Console、伺服器記錄檔，以及對實際上線頁面所提供內容的人工檢視。