記錄「HTML 頁面權重分析器」的使用步驟，代表要撰寫一套固定程序，把貼上的 HTML 回應內容，轉換成透明的位元組量測、行內與外部資源的占比，以及與 Googlebot 目前 2,000,000 位元組擷取上限之間的明確比較。每次執行時，記錄下來的工作流程應涵蓋三件事：你實際貼上的原始內容、分析器回傳的欄位，以及該工具不會量測的範圍。把它們寫下來，你就能在數天後重現同一量測、向同事說明，或交給稽核人員而無需盲目重新執行分析。分析器本身完全在瀏覽器中執行，不會上傳你的 HTML，也不會擷取實際的 URL——因此你的筆記只需要記錄你選擇貼上的內容、貼上的時間，以及你如何解讀輸出結果。把這份文件視為除錯地圖而非最終裁決：透過小幅度且真實的修改再重新量測，才是這套工作流程保持價值的方式，也才能讓你的筆記在有人質疑數字為何變動時依然站得住腳。
HTML 頁面權重分析器量測的內容
HTML 頁面權重分析器是一個貼上即可量測的工具。它接受 HTML 回應內容——也就是伺服器實際傳送的位元組，而非渲染後的 DOM，也非線上的 URL——並回報該段文字的五類事實。首先，總 UTF-8 位元組長度，透過瀏覽器的 TextEncoder API 計算；這一點很重要，因為 JavaScript 字串長度是以 UTF-16 碼元計算，而 HTML 回應通常以編碼後的位元組傳輸。其次，Unicode 碼點數量，能讓你察覺那些看起來很短、實際上卻包含大量重音字、CJK 或 emoji 字元的貼上文件。第三，文件行內 script 與 style 元素文字所占的比例。第四，原始屬性中內嵌的 data URI 所占用的位元組。第五，外部資源參考的有限清單——script src 屬性、樣式表與 preload 連結，以及常見的直接圖片、媒體與框架屬性。
總額數字會與 2,000,000 位元組的參考值進行對照。這個數字是十進位、保守的、且已標示為參考值，因為 Google 目前的文件說明 Googlebot 會擷取支援檔案的前 2 MB，並將此限制套用於未壓縮的資料，同時 HTTP 標頭也會占用每個 URL 額度的一部分。分析器僅能看到你貼上的內容，因此這項比較是透明的內容參考，而非擷取或索引的保證。外部資源檔案會以 URL 列出，但永遠不會下載；分析器無法證明任何它未實際擷取之檔案的大小。
記錄分析器工作流程的精確步驟
一旦你理解該工具量測的內容，你撰寫下來的工作流程就應該既簡短到足以重複、也詳細到足以稽核。請將以下順序視為你貼到操作手冊、工單或變更紀錄中的標準檢查清單。
- 擷取原始未壓縮的 HTML 回應內容。可使用檢視原始碼、儲存的回應檔案，或經授權的 curl 擷取。請略過 Elements 面板——它可能包含回應後才產生的 DOM 變更，並省略原本回應中的部分細節。
- 開啟 HTML 頁面權重分析器 並貼上回應內容。確認輸入區域顯示的是你預期量測的文件，而非被刪減的片段。
- 執行分析。該工具會在獨立的樣板片段中解析文字，因此不會執行任何程式碼、不會上傳任何內容，也不會擷取任何參考的資源。
- 記錄四個主要數字：總 UTF-8 位元組數、Unicode 碼點數、行內 script + style 位元組數，以及 data URI 位元組數。每一項皆以總位元組數與占完整內容的百分比記錄。
- 記錄 2,000,000 位元組參考值的比較結果：低於該上限的剩餘位元組數，或超出該上限的超量位元組數，並附上明顯的但書說明 HTTP 標頭也會占用 Google 每個 URL 額度的一部分。
- 儲存有限的外部資源清單。script src 清單、樣式表與 preload 連結，以及直接圖片、媒體與框架屬性的數量，能幫助你區分「內容本身龐大」與「內容只是指向龐大檔案」兩種情況。
- 從你的筆記中找出單一最大的原始碼層級熱點——通常是行內序列化狀態、重複的水合資料，或大型 data URI——並寫下你預計進行且最小幅度的真實修改。
- 部署該修改後，針對新的回應重複步驟 1 至 6。在筆記中比較新數字與前一次的結果；不要假設較小的數字就保證了擷取、索引或排名。
如何解讀筆記中每個數字的意義
為了你的筆記在多次執行間保持可用，每個欄位都應對應到一個白話的意義。下方表格摘要說明每個欄位的代表意義，以及為何它值得在你的文件中佔有一席之地。
| 筆記中的欄位 | 其代表意義 | 為何屬於記錄下來的工作流程 |
|---|---|---|
| 總 UTF-8 位元組數 | 貼上內容的編碼後位元組長度，以 TextEncoder 計算 | 這是跨次執行、以及與 2 MB 參考值比較的關鍵數字 |
| Unicode 碼點數 | 貼上文字中使用者可感知的字元數量 | 能顯示那些含有大量重音字、CJK 或 emoji 字元、看起來較實際短的貼上文件 |
| 行內 script 位元組與占比 | 行內 script 元素內的 UTF-8 位元組數，加上占完整內容的百分比 | 通常能指出序列化應用狀態、嵌入的函式庫，或重複的水合資料 |
| 行內 style 位元組與占比 | 行內 style 元素內的 UTF-8 位元組數，加上占完整內容的百分比 | 顯示重複的關鍵 CSS，可能適合移至可快取的外部檔案 |
| 資料 URI 位元組 | 支援的直接資源屬性中 data: 屬性值內的 UTF-8 位元組數 | 顯示直接嵌入標記的 Base64 圖片或字型；僅計算一次，不重複解碼 |
| 外部資源清單 | script src 清單、樣式表與 preload 連結、直接圖片、媒體與框架屬性的 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 中的位元組被重複計算。在資料 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 位元組、或縮減趨勢是否屬實時，你可為其辯護的紀錄。分析器在每次執行時保持不變；改變的是你餵入原始回應內容並解讀其回傳位元組時所抱持的紀律。
如需更深入的探討，請參閱 記錄 GEO 品牌知名度提問生成的步驟。