HTML Page Weight Analyzer（HTML 頁面權重分析器）的執行結果只有在它實際測量的五項細節明確時才有用：輸入是原始未壓縮的 HTML response body、總計是 UTF-8 位元組而非字元數、對應 Google 所記載之 Googlebot 容許量的 2 MB body 參考線採用十進位且僅計算 body、行內 script 與行內 style 內容加上嵌入的 data URI 都會計入 body 總和，而外部檔案引用則僅列出但不下載也不加入位元組總和。其他一切，從快取與壓縮到 response headers、引用檔案的大小、以及搜尋引擎實際索引的內容，依設計都在貼上 body 的計算範圍之外。把這些界線視為工具真正的作用範圍，就是區分「可以依據採取行動的數字」與「看完就跳過的數字」的關鍵。
本文所描述的具體工具是 HTML Page Weight Analyzer，它完全依據你貼上的文字運作。其產品合約明確說明：透過分離的 template fragment 解析輸入、不上傳也不擷取任何東西，並回報來源的 UTF-8 位元組數以及行內與外部引用的有限清單。了解工具為你決定了哪些細節、又把哪些留給你另行驗證，才是值得專注閱讀的整個重點。
決定 HTML 頁面權重檢測是否實用的細節
HTML weight analyzer 列印出的大部分數值是「決定」而非「測量」。「Total bytes」假設你貼上的 body 就是 Googlebot 將收到的 body。「Inline script share」假設沒有 src 的 <script> 元素內部內容屬於熱路徑。「Data URI weight」假設嵌入的 data: URL 是刻意設計且沒有重複狀態。這些假設每一項都是讀者必須牢記的細節，因為分析器會默默地套用它們。
最關鍵的一項細節在於 total bytes 是 UTF-8 位元組，不是字元數。瀏覽器的字串是一序列 UTF-16 code unit，因此對貼上的 HTML 字串執行 JavaScript .length 會得到一個與分析器回報的位元組總數不同的數字。此工具使用瀏覽器的 TextEncoder.encode() 方法，使主要數字反映 HTTP response 實際承載的內容。ASCII 文字大約每個字元一個位元組；帶有變音符號的字母、CJK 字元和 emoji 則各佔二到四個位元組。像 café 這樣的短字串有四個字元，但有五個 UTF-8 位元組，因為 é（U+00E9）編碼為兩個位元組（0xC3 0xA9）。在多語系頁面上這個差距會迅速擴大，這就是為什麼字元數會造成誤導。
Body 總和的內部：哪些計入、哪些排除
牢記這條界線最清楚的方式，是明確閱讀分析器的三個分類。下表摘要說明工具對其可能遇到的每一種輸入所做的決定。
| 類別 | 是否計入貼上 body 的 UTF-8 總和？ | 其貢獻內容 |
|---|---|---|
| 原始未壓縮的 HTML response body | 是 | 貼上文字的完整 UTF-8 位元組數 |
| 沒有 src 的行內 <script>...</script> | 是 | 元素內部文字的 UTF-8 位元組數 |
| 行內 <style>...</style> | 是 | 元素內部文字的 UTF-8 位元組數 |
| 支援屬性中嵌入的 data: URI | 是，僅計算一次 | 來源中呈現的完整屬性值 |
| 外部 script/style/image/media/iframe 引用 | 僅計算 URL 文字 | 依標籤與 src 列出；不下載該檔案 |
| HTTP response headers | 否 | 依設計排除於貼上文字之外 |
| Gzip 或 Brotli 壓縮後的傳輸大小 | 否 | 僅採用未壓縮位元組數 |
| 資源 response 大小、算繪成本、索引狀態 | 否 | 超出範圍；請於 DevTools 或 Search Console 驗證 |
透過這個視角解讀結果可以避免兩個常見錯誤：誤以為主要總和包含頁面僅引用的資產，以及誤以為主要總和描述壓縮下傳輸的實際樣貌。這兩項都是工具已經做出的決定，每次執行都值得在自己的筆記中重新確認。
以保留這些細節的方式執行分析器
準備輸入的方式是對結果影響最大的細節。產品合約走的是同一條路徑有其原因，遵循它才能讓其他每個數字都站得住腳。
- 擷取原始未壓縮的 HTML response body。使用瀏覽器的 View Source、關閉壓縮解碼的授權 curl 擷取、或伺服器日誌中儲存的 response，都能給出忠實的輸入。
- 將該 body 貼入 HTML Page Weight Analyzer。不要從 JavaScript 執行後的 DevTools Elements 面板貼上；它可能納入原始 response 中沒有的變動，並漏掉原始 response 中存在的來源細節。
- 執行分析並將主要 UTF-8 位元組總數、行內 script 與 style 佔比、嵌入的 data URI 位元組數，以及有限的外部資源清單視為各自獨立的欄位分別閱讀。
- 將 body 總數與分析器列印的 2,000,000 位元組參考線進行比對。請將其理解為僅針對 body 的十進位參考，而非 Googlebot 將擷取所有內容的保證。
- 找出來源層級最大的瓶頸，通常是重複的行內資料、重複的關鍵 CSS、或過大的 data: URI，並做出最小且真實的修改來處理它。
- 從同一來源重新量測部署後的 response，並以 DevTools、授權的 curl 擷取或 Search Console 進行驗證，而非僅憑較低的數字就予以採信。
每一步都保留不同的細節：步驟 1 保護「這是原始 body」這項假設；步驟 2 保護來源與 DOM 的區別；步驟 3 避免你把整個細項合併成單一數字；步驟 4 使 Googlebot 界線保持在適當比例；步驟 5 與 6 則讓修改具有可重現性。
2 MB 參考線及其相關細節
Google 目前的爬蟲文件說明 Googlebot 每個 URL 有 2 MB 的容許量，適用於未壓縮資料；稍後的技術性補充說明指出 HTTP headers 會佔用該容許量的一部分。由於分析器只能看到貼上的 body，這兩項事實使 2 MB 界線成為透明且保守的比較，而非一張認證。介面上將 2 MB 標示為十進位的 2,000,000 位元組 body 參考，顯示低於或超出該值的剩餘位元組數，並將 header 的警語保持可見。一篇值得搭配閱讀的文章是關於貼上 2,000,000 位元組並不保證 Googlebot 會擷取的指南，其中更深入探討其運作層面的影響。
這方面唯一值得連結的來源是 Google 本身的說明，在將這個數字視為常數之前都應該加以檢視。依據 Inside Googlebot（Google Search Central，2026 年三月），該上限適用於每個 URL 預算中的未壓縮 response 與 headers 共享部分。上限可能變動，這就是為什麼來源連結比記住數字更重要。
悄悄扭曲結果的小細節
有幾項細節看似微不足道，但對主要數字的影響比重構更大。會因使用者代理、地區、驗證狀態或裝置而有所不同的頁面，應針對每個具代表性的 response 進行測試，因為分析器看到的 body 就是你所測量的那個 body，別無其他。從用戶端 hydration 後的 Elements 面板複製內容，可能會加入伺服器 response 中沒有的序列化狀態而膨脹行內 script 位元組，也可能移除原本算入的來源註解與空白。若伺服器依路由回應不同的內容，請分別貼上每個標準路由。
Data URI 的處理方式也是需要注意的一項。分析器將來源中呈現的完整 data: 屬性值計算一次，不會再解碼後把解碼後的內容加回來。這避免了重複計算，但也意味著一個在標記上看起來約 14 KB 的嵌入 Base64 字型，不會被回報為更大的解碼後字型資料。請將該數字視為文件權重，而非解碼後的媒體權重。
分析器強制執行的互動限制也算細節。嚴格的輸入限制、共用元素上限，以及有限的 URL 顯示，都是刻意設計來防止巨大的貼上文件或惡意標記產生無界結果。若你的輸入被這些保護機制裁切了，分批以較小的區塊處理會得到更乾淨的讀數，而說明為何發生裁切的結果列本身也是值得記錄的訊號。
將細項視為除錯對照表
細項中的數字最適合當作除錯對照表，而非效能評分。較大的行內 script 位元組通常指向序列化的應用程式狀態、重複的 hydration 資料，或應該改為可快取外部檔案的內嵌函式庫。較大的行內 style 位元組通常代表重複的關鍵 CSS，或可移至外部樣式表的樣板產生規則。較大的 data URI 總和常反映出屬於靜態資產資料夾的 Base64 圖片或字型。較長的外部資源清單本身並非效能判決：若快取得當，許多引用都能保持輕量；但叢聚的重複 <link rel="stylesheet"> 或 <script src> 條目則確實是警訊。
坦誠的結論是：HTML Page Weight Analyzer 只能看到你貼上的內容。用它來繪製 body 對照圖、判斷 body 是否接近 Googlebot 所記載的 body 參考，再將適當的資產移至可快取的外部檔案、移除重複的序列化資料、避免在 data URI 中嵌入大量二進位資料，並將關鍵的中繼資料與內容放在 response 的前段。請分別驗證部署後的位元組、response headers、算繪後的頁面以及索引證據。較低的貼上位元組數是有用的訊號，但絕非最終答案。
若你在權衡選項，Bulk Link Extractor：解析並去除貼上 HTML 中的重複連結對此有詳細說明。