HTML 頁面權重分析工具回傳的結果如果看起來不對，幾乎一定可以追溯到以下三個地方之一：貼上的內容、分析工具實際測量的範圍，或計算 UTF-8 位元組與字元的方式。分析工具會回報一個透明的數字，也就是你提供的純文字的 UTF-8 位元組長度，並附上該來源文字的組成細項。它不會估算實際上線的 URL、不會下載參照的檔案，也不會猜測搜尋引擎在爬取時看到的內容。當數字看起來太高、太低，或與其他工具不一致時，原因通常是輸入內容或預期不同，而非測量錯誤。本文會帶你了解最常見的不一致情況，示範如何使用 HTML 頁面權重分析工具重新貼上可信的 HTML 主體，並說明如何解讀組成細項，讓數字反映你實際部署的回應。在修改頁面之前，請先確認分析工具測量的確實是你以為的內容。
為什麼結果看起來不對：常見的不一致
這個分析工具是確定性的，所以對任何固定的輸入，輸出都會相同。「看起來不對」的結果，幾乎總是代表所測量的內容與你預期要測量的內容不同。下列四種情境佔了大多數的意外狀況。
你貼上的是被竄改過的文件。瀏覽器的 Elements 面板顯示的是 JavaScript 執行完畢後的 DOM。如果你從那裡複製，可能會帶上注入的節點、已水合的元件狀態、開發工具註記，以及原始回應中根本沒有的標記。這段文字已經不再是回應主體，所以對它計算位元組並不會與部署的文件相符。
你把字元數和位元組數拿來比較。一個帶腔調的字母、一個 CJK 字元或一個表情符號，在 UTF-8 中會佔用超過一個位元組。如果分析工具回報某份文件為 47,200 位元組，但感覺只有 40,000 字元，差異來自多位元組文字，並非測量錯誤。關於位元組計算的定義，請參考 MDN TextEncoder 參考文件。
你預期外部資源會被計入總和。這個工具只計算 HTML 中每個參照的 URL 文字本身，並不算 URL 指向的檔案位元組。一個連結到 600 KB 圖片的頁面，並不會讓標題數字增加 600 KB；只會加上該圖片 src 屬性的字元數。外部檔案會列在資源清單中，但不會測量其實際內容大小。
你把 2,000,000 位元組當作 Googlebot 的保證。介面將這個數值標示為十進位 2 MB 主體的參考值，並非擷取或索引的保證。根據 Google 目前的說明文件，2 MB 的額度包含 HTTP 標頭，而這個工具只看得到主體。這個結果是一個透明的比較，並非 Googlebot 一定會接收或索引整個頁面的認證。許多這類模式都收錄在會扭曲 HTML 頁面大小分析工具結果的常見錯誤指南中。
分析工具實際計算的內容（與不計算的內容）
在修改頁面之前，請先確定測量範圍。這個分析工具會使用瀏覽器的 TextEncoder 計算輸入文字的 UTF-8 位元組，解析一個未附加到實際文件的獨立樣板片段，分類行內 script 與 style 文字，計算 data URI 屬性值一次，並同時限制擷取與顯示的範圍。它不會知道 HTTP 標頭、傳輸壓縮、資源的回應大小，或 Google 實際索引了什麼。
| 計入貼上主體的總和 | 不計入貼上主體的總和 |
|---|---|
| 你所貼上純文字的 UTF-8 位元組 | HTML 參照的任何外部檔案位元組 |
| 行內 script 元素的內容，以 UTF-8 計算 | HTTP 回應標頭的位元組 |
| 行內 style 元素的內容，以 UTF-8 計算 | 經過 gzip 或 Brotli 壓縮後的網路傳輸大小 |
| 完整的 data URI 屬性值，只計算一次 | 資源回應大小、渲染時間、Core Web Vitals |
| 每個外部參照的 URL 文字 | Googlebot 實際擷取或索引的內容 |
如果你想要的數字在右邊那一欄，這個工具就不是該看的地方。
修正輸入：重新貼上可信的 HTML 主體
要得到有意義的結果，最快的方法就是從乾淨的輸入開始。當貼上的文字與爬蟲或真實使用者收到的回應一致時，分析工具最能發揮作用。
- 取得原始未壓縮的回應主體。在瀏覽器中開啟頁面並使用「檢視原始碼」，或執行經授權的 curl 擷取，例如 curl -s --compressed https://example.com/page > page.html，若需要原始線路位元組，請再停用解壓縮。對大多數讀者來說，「檢視原始碼」是最簡單的來源。
- 避免使用 Elements 面板。在渲染後的頁面上按右鍵，選擇「檢視頁面原始碼」而非「檢查」。Elements 面板可能會顯示 JavaScript 新增的標記，也可能省略註解或原始空白等原始細節。
- 貼上完整的主體。複製整份文件，從 doctype 或 HTML 的第一個位元組到結束標籤為止，而不是片段。貼上部分內容只會產生部分的位元組計數。
- 執行分析。工具會回報總 UTF-8 位元組數、2,000,000 位元組的參考值、行內 script 與 style 所佔比例、data URI 的權重，以及受限的外部資源清單。
- 與 2 MB 參考值進行比較。將 2,000,000 以下的剩餘位元組數視為餘裕，而非擷取保證。標頭的注意事項是結果的一部分，而非註腳。
- 修正原始碼層級最大的熱點後重新測量。做最小且真實的修改，然後貼上新的回應主體，確認新的數字。熱點通常出在行內 script 位元組、行內 style 位元組或 data URI 位元組；將適合的程式碼移到可快取的外部檔案，移除重複的序列化資料，避免在 data URI 中嵌入大型二進位內容。
用一份好的輸入取代一份壞的輸入，往往就是全部的修正。工具無法挽救一個錯誤的貼上內容，但會用一個你可以採取行動的數字來回報乾淨的輸入。
解讀組成細項地圖：位元組都跑到哪裡去了
當輸入正確時，組成細項會告訴你這是什麼類型的頁面，而非它的效能如何。把每一個比例都當作除錯提示來看待。
行內 script 比例。大量的行內 script 位元組通常代表序列化的應用程式狀態、重複的水合資料，或可以移到外部檔案的內嵌函式庫。較小的行內比例加上較長的外部 script 清單是正常的。
行內 style 比例。大量的行內 style 位元組通常代表重複的關鍵 CSS、框架預設值，或個別元件的樣式。修正方法很少是刪除樣式，而是去除重複或將其移到可快取的外部樣式表。
Data URI 權重。分析工具會在支援的直接資源屬性中尋找 data: 值，計算其數量，並以原始檔案中出現的完整屬性值進行測量。它不會解碼 Base64 後再把解碼後的內容加上去，因為那會重複計算 HTML 中已經存在的位元組。過重的 data URI 總量是一個強烈訊號，代表應該把該二進位內容移到真正的檔案中。
外部資源清單。一長串參照清單並非效能分數。分析工具列出支援的參照，讓你區分「沉重的文件」與「只是指向沉重檔案的文件」；它永遠不會下載這些檔案。2 MB 的限制只套用於主體，Googlebot 會以各自的限制分別擷取參照的資源。
若想快速檢查字元與位元組的混淆，可以執行以下單一計算。想像一個包含 1,000 個 ASCII 字元、200 個帶腔調字母，以及 50 個表情符號的片段：
- 1,000 個 ASCII 字元，每個 1 位元組 = 1,000 位元組
- 200 個帶腔調字母，每個 2 位元組 = 400 位元組
- 50 個表情符號，每個 4 位元組 = 200 位元組
- UTF-8 位元組總計：1,000 + 400 + 200 = 1,600 位元組
- 字元總數：1,250
- 差異：350 個位元組是粗糙的字元計數會遺漏的部分
這個差距與你在 JavaScript 字串長度和分析工具的 UTF-8 位元組總和之間看到的差距相同。這不是 bug。
| 字元類型 | UTF-8 中每個字元的位元組數 | 範例 |
|---|---|---|
| ASCII 字母、數字、基本標點 | 1 位元組 | a, 7, ? |
| Latin-1 補充（帶腔調字母） | 2 位元組 | é, ñ, ü |
| CJK 字元 | 3 位元組 | 中，日，語 |
| 大多數表情符號與輔助平面字元 | 4 位元組 | 🚀, 🎉 |
將工具的數字與實際回應對齊
當分析工具回報一個可信的數字後，下一步是確認該數字與實際部署的內容一致。如果伺服器會根據使用者代理、地區設定、身份驗證或裝置而產生差異，請分別測試具代表性的回應，而非將它們平均。如果你的網站對行動裝置和桌面端提供不同的 HTML，那麼你測量的回應就是機器人收到的回應。
2,000,000 位元組的主體參考值刻意設定得較為保守。Google 目前的說明文件指出，Googlebot 會爬取支援檔案的前 2 MB，並在達到上限時停止擷取，稍後的技術說明還補充說 HTTP 標頭會佔用每個 URL 額度的一部分。由於分析工具只看得到主體，它無法知道實際回應標頭的大小，也無法證明 Googlebot 會在哪個位置停止擷取。請將這個數字視為僅限主體的參考值，並留意標頭的注意事項。Google 自己也提到限制可能會變動，這就是為什麼來源連結與參考日期比把這個數字視為永恆常數更重要。更多相關內容，請參考為什麼 2,000,000 個貼上位元組並不保證 Googlebot 擷取指南，以及底層的 Google Search Central 說明。
When to Switch to a Different Tool
The analyzer has a clear job, and that job is bounded. Reach for a different tool when you need facts it deliberately does not produce. Browser DevTools or an authorized curl capture will tell you the compressed transfer size, the response headers, cache headers, and per-resource timings. A Lighthouse or PageSpeed Insights run will give you Core Web Vitals, render-blocking resource counts, and JavaScript execution cost. Search Console or a fetch-and-render tool will tell you what Google actually saw.
A smaller number from this analyzer is a debugging signal, not a ranking promise. After finding the hotspot, make the smallest truthful change, remeasure the real response, and verify the deployed bytes, the response headers, the rendered page, and any indexing evidence you have. The tool earns its keep when its number is treated as one transparent input into a wider verification workflow, not as the final word.