HTML 頁面權重分析器的疑難排解從確認你貼上的是原始未壓縮的 HTML 回應主體開始，然後先閱讀位元組總數、字碼點數量、行內程式碼占比，以及 data URI 權重，再假設是分析器的問題。這個工具完全在瀏覽器中執行，絕不會擷取你的 URL、絕不會請求內嵌資源，也絕不會執行貼上的腳本，因此你在結果面板中看到的每一個意外狀況，都可追溯到三件事之一:你貼上的內容、UTF-8 位元組的運作方式，或是分析器刻意未涵蓋的部分。大多數令人困惑的結果，來自分析器實際測量的文件與你以為自己在測量的文件之間的不一致。被用戶端 JavaScript 修改過的回應、在儲存後才被 minify 的檔案，或是剝除註解與行內腳本的 CMS 匯出檔，都會產生與原始回應不同的位元組總數。一旦你對齊了輸入內容，剩下的疑難排解就會水到渠成。
使用分析器時「疑難排解」的含義
這個詞涵蓋了三種不同的讀者任務。第一個是弄清楚為什麼位元組總數看起來比你在其他地方看到的大小——例如 Lighthouse 稽核、PageSpeed Insights 的傳輸大小，或你在 CMS 中記得的數字——偏大或偏小。第二個是解讀輸出中令人困惑的部分，例如巨大的行內腳本百分比、冗長的外部資源參考清單，或是那條你可能預期會剛好顯示為「2 MB」的 2,000,000 位元組參考線。第三個是驗證在你做出變更後，新貼上的原始碼確實縮小了——而不是工具回報了較小的數字，但你部署的回應卻維持不變。
一個有用的框架是:分析器是你貼上原始碼的除錯對照圖，而非網路瀑布圖、壓縮計算器，或 Core Web Vitals 測試。當看起來有問題時，這個範圍界定非常重要。如果位元組與你的傳輸大小不符，差異來自分析器看不到的 gzip、Brotli 或 HTTP 標頭。如果行內腳本占比偏高，那代表一個真實可在源頭修正的熱點。如果 data URI 總量看起來很重，那是你可以從標記中移出的位元組。了解你的問題屬於哪一類，是任何疑難排解流程的第一步。
為什麼貼上的主體數字與你預期的不同
令人困惑的結果最常見的原因是原始碼本身。分析器圍繞著一條嚴格的規則運作:它只測量你貼上的內容，不測量其他東西。這條規則能產生乾淨的數字，但也意味著三個「遺漏」的位元組來源永遠不會被計入總數。
- HTTP 回應標頭。Google 為 Googlebot 設定的每個 URL 2 MB 文件化配額包含標頭位元組，但分析器只能看到你貼上的主體。標頭、快取控制、Cookie 和內容協商的開銷，不會出現在主要數字中。
- 壓縮。這個工具透過瀏覽器的 TextEncoder 計算未壓縮的 UTF-8 位元組。經 gzip 或 Brotli 壓縮的回應在傳輸工具中會看起來較小，而分析器則會回報較大的未壓縮大小，因為這才是 Googlebot 在 2 MB 限制下實際處理的格式。
- 外部資源酬載。連結的樣式表、腳本、圖片、框架、預載和媒體，只會貢獻它們在 HTML 中出現的 URL 文字與標籤字元。實際的檔案位元組由瀏覽器和 Googlebot 另行擷取，且各有其上限。一份指向重型檔案的文件，並不自動等同於一份重型文件。
第二個原因是 UTF-8 與 JavaScript 字串長度之間的混淆。JavaScript 字串長度計算的是 UTF-16 程式碼單元數，而非位元組數。H、e、l、l、o 等 ASCII 字母各佔一個 UTF-8 位元組。帶音調的字元 é(U+00E9)佔兩個位元組，因為 UTF-8 將其編碼為兩個位元組的序列 0xC3 0xA9。因此四個字元的字串「café」是 4 個 Unicode 字碼點，卻是 5 個 UTF-8 位元組:c(1)+ a(1)+ f(1)+ é(2)= 5。CJK 字元和表情符號會讓差距更大——單一表情符號可佔四個位元組。分析器使用 TextEncoder 來回報位元組數，這也是為什麼它的數字永遠不會與 someString.length 對上。
第三個原因是你實際貼上的內容。從瀏覽器的 Elements 面板複製時，如果 JavaScript 已經執行過，內容可能包含原始回應中從未存在的 DOM 變更，並可能遺漏來源細節，例如註解、原始空白，或在用戶端被移除的行內腳本。View Source、從 CMS 匯出的已儲存回應主體，或經授權的 curl 擷取結果，都是更誠實的輸入。如果你的伺服器會根據使用者代理、地區設定、驗證狀態或裝置來變化回應內容，請擷取具代表性的回應，並將每個變體視為獨立的測量對象。
先讀懂輸出再判定它有誤
在你假設測量結果有問題之前，先掃過分析器給你的每一行。UTF-8 位元組總數是標題數字，而字碼點數量就放在它旁邊作為合理性檢查。行內腳本位元組與行內樣式位元組會分開回報，並附上占整份原始碼的百分比。Data URI 會列出其數量以及它們為標記增加的位元組權重。外部資源則以一組有界限的清單呈現，涵蓋圖片、樣式表、腳本、框架、預載與媒體的參考。
| 輸出項目 | 涵蓋範圍 | 為何對疑難排解很重要 |
|---|---|---|
| UTF-8 位元組總數 | 整份貼上的原始碼以 UTF-8 編碼 | 可直接與 2,000,000 位元組參考線比較 |
| Unicode 字碼點 | 原始碼中的相異字元 | 可察覺吃重位元組的多位元組字元，如音調符號、CJK 或表情符號 |
| 行內腳本位元組 | <script> 標籤內沒有 src 的文字 | 指出序列化狀態或嵌入的程式庫 |
| 行內樣式位元組 | <style> 標籤內的文字 | 指出重複的關鍵 CSS |
| Data URI 位元組 | 完整的 data: 屬性值 | 可察覺嵌入標記中的 Base64 圖片或字型 |
| 外部資源清單 | 連結資源的 URL 與標籤 | 顯示文件是否只是參考了重型檔案 |
當行內腳本或行內樣式的百分比偏高時，通常的解法是將程式碼移至可快取的外部檔案。當 data URI 總量偏高時，解法是從標記中移除嵌入的二進位資料，或將其移到真正的圖片或字型 URL 後方。當外部資源清單異常冗長時，請檢查是否有重複的標籤——例如一個散落的分析碼片段、一個冗餘的預載，或一個被觸發兩次的 CDN 參考。參考數量本身並非效能分數，但一份冗長的清單通常就是原始碼承載過多內容的第一個警訊。
逐步修正令人困惑的分析器結果
- 從乾淨來源重新貼上。在新分頁中開啟頁面並使用 View Source，或使用 curl 擷取回應，然後將未壓縮的主體貼回 HTML 頁面權重分析器。避免在 JavaScript 已變更 DOM 後從 Elements 面板複製。
- 確認位元組總數看起來合理。將回報的 UTF-8 位元組與你儲存的回應檔案大小進行比較。若兩者差異極大，你可能貼錯了文件、把一個被誤認為 HTML 的 minify 打包檔，或只貼到部分片段。
- 一併閱讀字碼點數量與位元組總數。兩者之間的大落差代表多位元組字元正推升位元組總數。這是內容事實，不是工具的 Bug。
- 為熱點排序。查看行內腳本、行內樣式與 data URI 項目。找出單一最大的源頭熱點——通常是在整份原始碼中占比最高的那一個。
- 做一項小而真實的變更。把一段行內腳本移到可快取的外部檔案、移除重複的水合酬載，或把 data URI 圖片換成真正的資源 URL。避免一次編輯多處，才能隔離效果。
- 重新測量部署後的回應。再次使用 curl 或 View Source 擷取線上 URL，將新的主體貼入分析器，並將位元組總數、行內占比與外部資源清單與上一次結果進行比較。
- 檢查 2,000,000 位元組參考線。應將其視為與 Google 目前 Googlebot 每 URL 2 MB 限制的純主體比較，而非頁面必會被完整檢索或索引的保證。請參考 為何貼上的位元組無法保證 Googlebot 抓取 以了解該限制的背景脈絡。
- 驗證部署後的結果。確認回應標頭、渲染後的頁面與索引證據都如你所預期地運作。分析器出現較小的數字，本身並不能證明檢索或排名會更好。
如果你的問題具體是 data URI 總量看起來不對，請記住兩條避免重複計算的解析規則。分析器會依貼上原始碼中出現的完整屬性值來計數——包括 data: 前綴、MIME 類型、選擇性的 ;base64 權杖，以及酬載字元。它不會再把 Base64 酬載解碼後把那些位元組加總一次，因為那些位元組已經存在於 HTML 原始碼中。它同樣不會把任意的 data-* 屬性、類似 #section 的 href，或一個 title 視為資源。巢狀的 <template> 內容會以瀏覽器原生的 HTML tokenizer 解析並保持非作用狀態，因此其標記不會被計入資源清單。srcset 值會被保留為單一宣告，因為以簡單的逗號切分會誤判其中的 data URL。
Confirm the Fix on the Real Deployed Response
The analyzer shows you what the source you pasted looks like; it does not show you what Google saw. After you edit the source and remeasure, the next step is to fetch the live URL the same way your crawler would. An authorized curl capture is usually the cleanest signal, because it gives you the same response body your real users receive and lets you compare against the analyzer's number byte-for-byte.
If the deployed body matches the analyzer's number, the change is real. If it does not, something sits between your source and the deployed response — server-side includes, edge workers, minification, or a CMS rewriting tags on save. The fastest way to spot that gap is to diff the curl output against the file you thought you were shipping. If the analyzer shows a smaller number but the curl output is unchanged, you edited the wrong file.
Two more checks are worth running before you close the troubleshooting session. First, look at the response headers with -I or -D -; the analyzer cannot see them, and they are part of the 2 MB per-URL allowance Googlebot uses. Second, decide whether the deployed page still looks correct in a browser — an inline-script reduction that broke a hydration step will not show up in the analyzer, only in the page. For larger workflows, avoid the input mistakes that skew analyzer output in the first place by saving the response you intend to measure rather than copying from a live DOM.
Limits to Keep in Mind When the Result Still Looks Off
The analyzer is bounded by design. A strict input limit, a shared element cap, and bounded URL display protect against full-site dumps and adversarial markup. Counts and displayed values stop at those limits so the main thread is not blocked. The parser uses the browser's native HTML tokenizer inside a detached template fragment, which means <textarea>, <title>, <script>, and <style> raw-text boundaries are read correctly, even when nested templates contain markup that looks like resources. That same detachment is why pasted scripts never execute, forms never submit, and image or iframe URLs are never requested. Results are rendered as text rather than as live DOM.
It also means there are several things the analyzer cannot tell you. It does not know gzip or Brotli transfer size. It does not know response header size. It does not know cache behavior. It does not know late client-side DOM mutations. It does not know resource response sizes, execution cost, rendering cost, or what Google actually indexed. When any of those matter, use DevTools or curl against the authorized public response. The analyzer gives you a transparent body reference for the source you paste, not a verdict on the live page, and Google's documented limits can change over time, so check the source of the 2 MB reference rather than treating the number as a constant.