記錄 HTML 頁面權重分析器的使用步驟，意味著要把一套固定程序寫成文件：將貼上的 HTML 回應主體轉成透明的位元組測量結果、內聯與外部資源的占比分析，並與 Googlebot 目前的 2,000,000 位元組擷取上限做出清楚比較。你撰寫的文件化工作流程應在每次執行時記錄三件事：你貼上的原始來源、分析器回傳的欄位，以及該工具不會測量的範圍。把這些內容寫下來後，你就能在數天後重現同一筆測量、向同事說明結果，或在不需盲目重跑分析的情況下交付給稽核人員。分析器本身完全在瀏覽器中執行，既不上傳你的 HTML，也不會擷取實際 URL——因此你的筆記只需記錄你選擇貼上的內容、貼上時間，以及你如何解讀輸出結果。請把這份文件視為除錯地圖而非最終裁決:小幅且真實的調整，搭配反覆重新測量，才是這個工作流程保持價值的方式，也是當有人質疑數字為何變動時，你的筆記仍站得住腳的關鍵。
HTML 頁面權重分析器實際測量什麼
HTML 頁面權重分析器是一款「貼上即可測量」的工具。它接受 HTML 回應主體——也就是伺服器實際傳送的位元組，而非算繪後的 DOM 或實際 URL——並針對該段文字回報五類事實。首先是總 UTF-8 位元組長度，透過瀏覽器的 TextEncoder API 計算;之所以重要，是因為 JavaScript 字串長度計算的是 UTF-16 程式碼單位，而 HTML 回應在傳輸時通常以編碼後的位元組形式存在。第二是 Unicode 碼點數量，能幫助你辨識那些看起來很短、卻含有大量帶腔調字元、CJK 或表情符號的貼上文件。第三是文件中內聯 script 與 style 元素文字所占的比例。第四是原始屬性中嵌入的 data URI 所消耗的位元組數。第五是外部資源參考的有限清單——script src 屬性、樣式表與預載入連結，以及常見的直接圖片、媒體與框架屬性。
這個醒目的總數會與 2,000,000 位元組的參考值進行對照。這個數字是十進位、保守估計，並已明確標示，因為 Google 現行文件說明 Googlebot 會擷取受支援檔案的前 2 MB，該限制適用於未壓縮資料，且 HTTP 標頭也會佔用每個 URL 配額的一部分。分析器只能看到你貼上的主體，因此這個比較屬於透明的主體參考，並非擷取或索引的保證。外部資源檔案會以 URL 形式列出，但不會被下載;分析器無法證明任何它未實際擷取之檔案的大小。
記錄分析器工作流程的精確步驟
一旦你理解這個工具實際測量什麼，你撰寫的工作流程就應短到可以重複執行，又詳細到足以接受稽核。請將下列順序視為你要貼進操作手冊、工單或變更紀錄中的標準檢查清單。
- 擷取原始未壓縮的 HTML 回應主體。請使用檢視原始碼、儲存的回應檔，或經授權的 curl 擷取結果。請略過元素面板——它可能包含回應中並未存在的載入後 DOM 變更，也可能遺漏原本存在的細節。
- 開啟 HTML 頁面權重分析器 並貼上回應主體。請確認輸入區域顯示的是你預計測量的文件，而非刪節後的片段。
- 執行分析。此工具會在分離的 template 片段中剖析文字，因此不會執行任何程式碼、不會上傳任何資料，也不會擷取任何被參考的資源。
- 記錄四個主要數字:UTF-8 位元組總數、Unicode 碼點數、內聯 script + style 位元組，以及 data URI 位元組。請同時記下每項的位元組總數與占整體來源的百分比。
- 記錄 2,000,000 位元組的參考對照:在該上限以下還剩多少位元組，或超過該上限溢出了多少位元組，並標註可見的提醒——HTTP 標頭同樣會佔用 Google 每 URL 配額的一部分。
- 儲存有限範圍的外部資源清單。script src 清單、樣式表與預載入連結，以及直接圖片、媒體與框架屬性的數量，能幫助你區分「文件本身龐大」與「文件只是指向龐大的檔案」這兩種情況。
- 從你的筆記中找出單一最大的來源層級瓶頸——通常為內聯序列化狀態、重複的 hydration 資料，或大型 data URI——並寫下你打算進行、最小且真實的調整。
- 部署該調整後，請對新的回應重複步驟 1 至 6。將新數字與筆記中的前次結果進行比對;不要預設數值較小就保證能夠被擷取、索引或排名。
如何解讀筆記中的每個數字
為了讓筆記在多次執行間保持可用，每個欄位都應對應一個白話的意義。下方表格將每個欄位所代表的意義，以及它之所以值得在文件中佔有一行，做了整理摘要。
| 筆記中的欄位 | 代表的意義 | 為何屬於文件化工作流程的一部分 |
|---|---|---|
| UTF-8 位元組總數 | 貼上主體的編碼後位元組長度，以 TextEncoder 計算 | 跨次執行比較，以及與 2 MB 參考值對照的醒目數字 |
| Unicode 碼點數 | 貼上文字中使用者可感知字元的數量 | 能揭露那些含有大量帶腔調字元、CJK 或表情符號、看起來比實際簡短的貼上文件 |
| 內聯 script 位元組與占比 | 內聯 script 元素內的 UTF-8 位元組，以及占來源的比例 | 通常指向序列化後的應用程式狀態、嵌入的函式庫，或重複的 hydration 資料 |
| 內聯 style 位元組與占比 | 內聯 style 元素內的 UTF-8 位元組，以及占來源的比例 | 指出可能應移至可快取外部檔案中的重複關鍵 CSS |
| data URI 位元組 | 受支援的直接資源屬性中，data: 屬性值內的 UTF-8 位元組 | 揭露直接嵌入於標記中的 Base64 圖片或字型;只計算一次，不會重複解碼 |
| 外部資源清單 | script src 清單、樣式表與預載入連結、直接圖片、媒體與框架屬性 URL | 區分「文件本身龐大」與「文件只是參考龐大檔案」 |
| 2 MB 參考對照 | 2,000,000 以下剩餘位元組，或超過該值的溢出位元組 | 僅限主體的參考值;絕非擷取或索引的認證 |
一個小而可驗證的範例，能讓讀你筆記的同事具體理解「位元組 vs. 字元」的差異。四個字元的字串 "Hello" 占 5 個 UTF-8 位元組，因為每個 ASCII 字母都是一個位元組。四個字元的字串 "Café" 看似同樣四個字元，卻也占 5 個 UTF-8 位元組，因為 é 編碼為兩個位元組，而 C、a、f 各編碼為一個位元組。在一份文件化的執行紀錄中，把 "Hello" = 5 位元組與 "Café" = 5 位元組並列記載，即可立即對分析器的計算方式進行健全性檢查，並說明碼點與位元組為何不能互換。
每次測量都應一併記錄的測量範圍界線
一份文件化的分析器工作流程，只有同時記錄了「工具不會測量什麼」，才具備可信度。以下五項限制應與你的數字放在同一頁。
第一，分析器測量的是貼上的來源。它不會擷取 URL，因此無法告訴你實際回應的 gzip 或 Brotli 傳輸大小、伴隨主體的伺服器標頭、快取指示，或實際傳送給真正爬蟲的位元組。當這些事實很重要時，請使用瀏覽器 DevTools 或以 curl 對經授權的公開回應進行擷取，再把該主體貼回分析器。
第二，外部資源會被列出，但不會被測量。帶有 src 屬性的 script 元素，只會把 URL 字元貢獻給貼上的 HTML 總數;該 script 本身的承載內容，是由瀏覽器與 Googlebot 另行擷取，並受各自的限制約束。讓 HTML 頁面大小分析器結果失準的常見錯誤 一文逐步說明了這條界線常被忽略的方式，尤其是當開發者誤以為「清單很長」就代表「頁面緩慢」。
第三，data URI 是依其在來源中呈現的形式來測量。分析器會把完整的 data: 屬性值計算一次，且不會先解碼 Base64 再把解碼後的承載內容另外加總，因為那會導致 HTML 中已存在的位元組被重複計算。在 data URI 總數旁記下這項事實，能避免審閱者將數字「向上修正」。
第四，2,000,000 位元組這條線屬於主體參考值。Google 的文件指出 HTTP 標頭會佔用每 URL 配額的一部分，且相關限制可能會變動。請將來源連結與參考日期與該數字一併記錄，而不是把 2,000,000 視為永久常數。
第五，此工具不是網路瀑布圖、壓縮計算機或 Core Web Vitals 測試。它無法掌握算繪成本、執行成本、晚發生的用戶端 DOM 變更，或 Google 實際索引了什麼。這份細目是除錯地圖;真正部署後的回應、回應標頭、算繪後的頁面，以及索引證據，才是驗證任何調整的依據。
將你的文件化步驟轉化為可重複的稽核
一旦步驟與限制都寫成文件，這份文件就會成為可重複的稽核流程。請記錄時間戳、待測的 URL 或路由，以及伺服器若會依使用者代理程式或語言地區而有所不同時的對應變因，以及貼上主體的確切來源。請將分析器輸出儲存為快照——總位元組數、碼點數、內聯占比、data URI 位元組、外部清單長度，以及 2 MB 對照結果——連同你預計進行的調整一併保存。部署後，以同一份檢查清單對新回應重新執行，並比對快照差異。
有三個習慣能讓稽核長期保持誠實。請只貼上伺服器實際傳回的內容，而不是瀏覽器後續在 DOM 中變動後的結果。每次修正後請重新測量部署後的回應，而不是你本機開發時的頁面。請將引用次數與占比視為證據，而非分數:較長的外部資源清單可能揭示值得合併的重複標籤，但單憑這點本身並非效能上的裁決。
有了這些習慣，這份文件化的工作流程就能從一次性備註，轉變成一份在利害關係人質疑「數字為何變動」、「為何回應落在 1,850,000 或 1,950,000 位元組」，或「縮小的趨勢是否屬實」時，你都能據以捍衛的紀錄。分析器本身在每次執行時都保持不變;會改變的，是你餵入原始回應主體與解讀其所回傳位元組時的紀律。