HTML 網頁權重分析器會回報您貼上內容的 UTF-8 位元組權重——而非線路上實際傳輸的大小——並將內文與一個 2,000,000 位元組的參考值進行比對，該參考值取自 Googlebot 有文件記載的每個 URL 2 MB 抓取上限。在本文中「正確使用」包含三件事：將原始未壓縮的回應內文（而非經變動的快照）提供給分析器、正確讀取欄位而不混淆位元組與字元數，以及將結果視為一張除錯地圖，每次只指向一個源頭層級的熱點。該工具完全透過分離的樣板片段在瀏覽器中執行，既不上傳也不抓取任何內容，並使用平台 TextEncoder API，讓顯示的數字反映編碼後的位元組，而不是 JavaScript 字串長度。HTML 中引用的外部檔案——圖片、腳本、樣式表、字型——會以 URL 形式列出，但絕不會被下載或測量大小。正確使用意味著接受這些限制，而不是試圖將本工具延伸為網路瀑布圖、壓縮計算機或 Core Web Vitals 測試。
正確使用對讀者的要求
若要正確使用 HTML 網頁權重分析器，請區分三個經常被混淆的決策:選擇輸入、讀取輸出，以及依據輸出採取行動。這三個決策各自至少有一種會悄悄扭曲結果的失敗模式。
第一個決策是輸入選擇。正確使用的分析器應從原始未壓縮的 HTML 回應內文開始，而不是瀏覽器在 JavaScript 執行後顯示的 DOM。第二個決策是欄位選擇。正確使用的分析器聚焦於 UTF-8 位元組總數，而不是 JavaScript 字串長度，且絕不會將結果解讀為 Core Web Vitals 預測。第三個決策是後續追蹤。正確使用的分析器每次只產生一個源頭層級的熱點，之後重新測量已部署的回應，以確認該變更確實已上線。
如果略過這三個決策中的任何一個，顯示的數字仍會出現，但其所支撐的工作流程已不再可信。本篇文章接下來會依序說明每一個決策。
測量範圍
分析器的輸入是您貼上的文字，並透過嚴格的輸入上限、共用元素上限，以及有限的 URL 顯示加以保護，以避免意外的全站傾印和惡意標記癱瘓主執行緒或輸出。其輸出涵蓋從該文字中刻意界定的一組測量，以及一項 Googlebot 比較。其餘皆在結果之外。
| 分析器納入計算的項目 | 本工具不測量的項目 |
|---|---|
| 貼上來源的 UTF-8 位元組總長度 | HTTP 回應標頭 |
| 貼上來源的 Unicode 碼點數 | Gzip 或 Brotli 傳輸大小 |
| 各行內 <script> 元素的位元組 | 外部 CSS、JS、圖片、字型或媒體檔案的傳輸量 |
| 各行內 <style> 元素的位元組 | 伺服器快取行為與 CDN 設定 |
| data: URI 屬性值佔用的位元組 | 後續的用戶端 DOM 變動 |
| 外部資源引用的清單 | 渲染時間、Core Web Vitals 或執行成本 |
| 相對於 2,000,000 位元組內文參考值的落點 | 索引或排名結果 |
連結的資源並不會將其傳輸量位元組加總到貼上的 HTML 總量中。外部樣式表、腳本、圖片、框架、preload 或媒體引用，只會貢獻出現在 HTML 回應內的字元。分析器會列出這些引用，讓您能區分「內文本身就龐大」與「內文只是指向龐大的檔案」，但它既不下載這些檔案，也不宣稱知道它們的大小。Googlebot 與網頁渲染服務 (Web Rendering Service) 可能會以各自的限制另外抓取被引用的資源，而根據Google 搜尋中心檢索器公告，這些資源並不會附加在回應內文額度之內。
2,000,000 位元組的比較值同樣刻意採取保守設定。Google 目前的說明文件指出，Googlebot 會抓取支援檔案的前 2 MB，並在切斷點停止抓取，而稍後的技術說明更補充說 HTTP 標頭會佔用每個 URL 額度的一部分。由於分析器只接收貼上的回應內文，因此無法看到回應標頭，也無法精確證明 Googlebot 會在哪裡停止。介面將 2 MB 標示為十進位的 2,000,000 位元組內文參考值，於其下方顯示剩餘位元組，或於其上方顯示超出量，並讓標頭註解持續可見，讓這個數字被當作參考值而非認證。
選擇正確的 HTML 輸入
正確使用在任何測量執行之前就已開始。分析器無法判斷您貼上的內容是否與 Googlebot 收到的 HTML 相同，因此輸入是您的責任。
建議的來源包括瀏覽器的「檢視原始碼」、儲存的回應內文，或針對公開 URL 進行授權的 curl 擷取。這些都代表伺服器實際回傳的內容。相對地，Elements 面板顯示的是 JavaScript 變動後的即時 DOM;從中複製可能納入回應中未曾出現的變更，也可能遺漏原始的細節。對於伺服器會依使用者代理、地區設定、驗證狀態或裝置類別而有所不同服務的頁面，請擷取您實際關注的代表性回應——分析器會測量您貼上的內容，而不是您原本打算貼上的內容。
ASCII 字元通常各佔一個 UTF-8 位元組，但帶有變音符號的字母、CJK 文字與表情符號各自佔用更多位元組。這正是為什麼同一份來源上，字元數與位元組數可能出現明顯落差，也說明分析器使用瀏覽器 TextEncoder API 而非 JavaScript 字串長度作為顯示總數的原因。
逐步執行分析
- 使用「檢視原始碼」、儲存的回應內文，或授權的 curl 擷取來取得原始未壓縮的 HTML 回應內文。在本機儲存，讓您可以完整貼上而不被截斷。
- 將擷取到的內文貼入HTML 網頁權重分析器。內容既不會上傳也不會執行;文字會在分離的樣板片段內解析。
- 執行分析，並將顯示的總數讀為 UTF-8 位元組，而非字元數。將 Unicode 碼點數視為次要參考，有助於辨識多位元組佔比高的內容，但絕非網頁權重本身。
- 接著檢視行內 <script> 與行內 <style> 所佔的比例。兩者皆會同時以位元組總數與佔整份來源的比例回報，讓您能看出內文的主體是標記、程式碼或樣式。
- 檢查 data: URI 區段中內嵌的 Base64 圖片、字型或其他二進位承載。分析器會依貼上來源中出現的完整屬性值計算;並不會先解碼 Base64 再將解碼後的承載額外加總，因為那會重複計算 HTML 中已存在的位元組。
- 快速瀏覽外部資源清單。請將其視為一份列表，而非評分:冗長的清單可能指向重複的標記、非預期的 preload 或 iframe 載入，但高引用數本身並非效能評等。
- 將顯示總數與 2,000,000 位元組參考值進行比對。請留意剩餘或超出的位元組，但記得 HTTP 標頭與另外抓取的資源並未納入此計算，因此這個數字屬於內文參考值，而非抓取保證。
將結果視為除錯地圖，而不是評分
結果面板不是效能評分，而是貼上來源的除錯地圖。以這種方式解讀，正是正確使用與過度樂觀使用之間的分野。
第一張要讀的地圖是行內腳本佔比。龐大的行內腳本位元組通常指向序列化後的應用程式狀態、重複的水合 (hydration) 資料，或內嵌的函式庫——這些若改為可快取的外部檔案會更小。第二張地圖是行內樣式佔比。龐大的行內樣式位元組常代表重複的關鍵 CSS、可去除重複的框架樣板，或應從共用樣式表拉取而非直接以行內方式輸出的設計權杖。第三張地圖是 data: URI 總和，可揭示直接內嵌於標記中的 Base64 圖片或字型——這些承載看起來像文字，行為卻像二進位檔案。
冗長的外部資源清單是第四張地圖。它並不測量外部檔案本身，但能凸顯重複的標記、多餘的 preload，或頁面實際不需要的 iframe 引用。將這份清單與行內佔比一併解讀，可粗略區分「文件本身龐大」與「文件指向龐大的檔案」。
以下用一個數字範例把「位元組 vs 字元」的差異講清楚。假設您貼上的來源包含 100 個 ASCII 字元與 20 個表情符號。UTF-8 位元組權重為 100 × 1 + 20 × 4 = 180 個位元組，而 JavaScript 字串長度則回報 140。兩組數字在其各自的定義下都正確;只有 180 位元組這個數字才是分析器顯示的標題總數，也就是 Googlebot 實際透過線路為內文傳輸的數字。
修正一個熱點、重新測量並驗證
依據結果採取行動是正確使用的第三個環節，也是多數「正確使用」工作流程悄悄出錯的地方。
挑選一個熱點。將適合的程式碼移至可快取的外部檔案、移除重複的序列化狀態、避免將大型二進位承載以 data URI 形式內嵌，並將關鍵的中繼資料與內容放在回應的較前段。在做出最小且真實的變更後，別假設分析器會顯示更小的數字——請將新部署的回應重新貼上並再次測量。以部署後的位元組為準，而非部署前磁碟上的位元組。
驗證並不止於內文。分析器看不到 HTTP 標頭、gzip 或 Brotli 傳輸大小、伺服器快取標頭、後續的用戶端變動或渲染成本，也不會宣稱低於 2,000,000 位元組內文參考值就能保證 Googlebot 會完整抓取該頁。這些問題需要 DevTools 或針對授權公開回應的 curl 來回答，並搭配對渲染後頁面與索引證據的檢查，才能將這次變更視為成功。本工具顯示較小的數字代表來源變輕了;它本身並非代表抓取、排名或索引有所改善的訊號。
如果結果看起來與您的預期不一致——例如數字比 DevTools 顯示的小很多——請先從輸入流程逐項檢查。多數失準的結果來自貼上的是變動後的 Elements 快照、gzip 解壓縮後的樣本，或是部分片段，而不是原本送出的內文。如需更完整的輸入與讀取錯誤清單，請參閱讓 HTML 網頁大小分析器結果失準的常見錯誤。
如需更深入的探討，請參閱從 HTML 原始碼取得 Facebook 粉絲頁的連結。