查看 HTML 網頁權重與大小分析器的結果,並不是先看單一分數,而是先讀取五個不同的欄位:貼上來源的總 UTF-8 位元組數、內嵌 script 與 style 文字所佔的比例、嵌入資料 URI 的位元組權重、外部資源參照的有限清單,以及與 2,000,000 位元組參考值之間的差距,這個參考值與 Googlebot 文件記載的每個 URL 抓取上限 2 MB 相關。每個欄位都來自分析器對你貼上文字的量測,而不是對線上頁面發出的網路請求,所以執行工具後的第一個檢查就是確認你的輸入是否正確。標題數字是來源經瀏覽器 TextEncoder API 編碼後的 UTF-8 位元組長度;它不是 JavaScript 字串長度,也不是實際傳輸的 gzip 壓縮大小,更不是渲染後的 DOM 大小。一個字元數很少的頁面,如果有重音字母、CJK 文字或表情符號,位元組數可能仍然很大;反之,一個外部 script 標籤很多的頁面看起來可能很輕,因為分析器只計算 URL 字元,從不計算這些 URL 指向的酬載。
貼上 HTML 後,分析器會回傳什麼
當你把原始未壓縮的 HTML 回應主體貼進 HTML 網頁權重分析器時,介面會回傳一組直接從你輸入位元組建構出來的固定量測結果。標題總計是貼上文字精確的 UTF-8 位元組長度,並附上 Unicode 碼點數,讓你可以並排查看兩個數字,並注意它們何時出現分歧。ASCII 字元通常每個佔一個 UTF-8 位元組,但重音字母、CJK 文字和表情符號會佔更多,這就是為什麼用 .length 計算出來的 JavaScript 字串長度,會低估非 ASCII 內容的傳輸權重。
在標題下方,結果會將來源切分為三個除錯切片加上一份清單。第一個切片回報每個內嵌 script 元素文字內容與每個內嵌 style 元素文字內容的 UTF-8 位元組總數,同時以位元組與佔整份文件的比例表示。第二個切片回報在支援的資源屬性(例如 src、href、srcset 及類似的媒體屬性)中,每個 data: 值的位元組權重,同樣附上數量與佔整份文件的百分比。第三個輸出是一份外部資源參照的有限清單,依元素類型分組,列出文件指向的 URL,但絕不會實際去抓取它們。第四個輸出是與 2,000,000 位元組參考值之間的差距,當主體跨越該界線時,會以剩餘餘量或超量來顯示。
如何逐步檢查結果
- 確認輸入是原始回應主體,而不是 JavaScript 執行後的 Elements 面板。檢視原始碼、儲存的回應檔案,或經授權的 curl 擷取,能讓你取得伺服器送出的原始內容;線上的 Elements 面板可能隱藏來源細節,並加入從未在傳輸線上的 DOM 變更。
- 將標題總計讀為 UTF-8 位元組,而非字元數。分析器使用瀏覽器的 TextEncoder API,所以以 ASCII 為主的來源會接近字元數,而 CJK 或表情符號來源則不會。TextEncoder.encode() 的 MDN 說明文件描述了這種位元組編碼的行為。
- 將內嵌 script 與內嵌 style 欄位讀為佔整份文件的百分比。合併比例超過總計約三分之一時,通常代表有序列化的 hydration 資料、嵌入的函式庫,或是重複的關鍵 CSS,這些都應該放到可快取的外部檔案中。
- 讀取資料 URI 的位元組總計與數量。資料 URI 屬於 HTML 來源的一部分,可能會透過 Base64 圖片或字型悄悄膨脹回應大小;分析器只計算一次完整的屬性值,不會再解碼 Base64 酬載重複計算。
- 將外部資源清單讀為一份列表,而不是一個權重。每個項目都是文件攜帶的 URL 文字,分析器並不下載或量測這些 URL 指向的檔案,所以清單很長本身並不代表頁面很重。
- 將剩餘或超量那一行對照 2,000,000 位元組的參考值來讀。這是與 Google 目前文件中每個 URL Googlebot 2 MB 容量的十進位主體比較,並非保證該頁面會被完整抓取。
- 從各項數據中挑出最大的來源層級熱點,做出最小且誠實的修改(把程式碼移到外部檔案、移除重複的序列化資料,或是把沉重的資料 URI 拆成獨立抓取),然後重新貼上新的回應主體再量測一次。
對照 2 MB Googlebot 參考值讀取數字
2,000,000 位元組這條線是最容易被誤讀的欄位,因此值得單獨檢查。介面將 2 MB 標示為十進位的 2,000,000 位元組主體參考值,因為 Google 目前的文件說明 Googlebot 只會抓取支援檔案的前 2 MB,到了截斷點就停止;Google 也補充說明此限制適用於未壓縮資料。後續的技術說明指出 HTTP 標頭會佔用每個 URL 容量的部分配額。分析器只接收貼上的回應主體,所以無法得知實際回應標頭的大小,也無法精準判斷 Googlebot 會在哪裡停止。請將 2,000,000 這個數字視為透明且保守的主體比較,並對照畫面上顯示的剩餘位元組值或超量值來讀取,同時留意標頭的但書。限制可能會變動,所以來源連結與參考日期比把這個數字當作永恆常數更為重要。
| 輸出欄位 | 反映的內容 | 未涵蓋的內容 |
|---|---|---|
| UTF-8 位元組總計 | 瀏覽器編碼後貼上來源的位元組長度。 | HTTP 回應標頭、gzip 或 Brotli 傳輸大小、所參照檔案的酬載。 |
| 2,000,000 位元組參考值 | 與文件記載的每個 URL Googlebot 2 MB 上限所做的十進位主體比較。 | 在 Google 端同樣計入該容量的標頭位元組。 |
| 內嵌 script 與 style 比例 | 內嵌 script 與 style 元素內文字內容的 UTF-8 位元組數。 | 外部 script src 酬載與連結樣式表的位元組。 |
| 資料 URI 總計 | 支援資源屬性中每個 data: 值的位元組數,只計算一次。 | 解碼後的 Base64 酬載大小,刻意不重複計算。 |
| 外部資源清單 | 依元素類型分組的所參照 URL 有限列表。 | 每個 URL 的實際回應大小、抓取結果與快取行為。 |
舉例來看這個比較的具體讀法:假設標題回報貼上回應主體為 1,847,520 個 UTF-8 位元組。在 2,000,000 位元組主體參考值下,剩餘餘量的算法是 2,000,000 減去 1,847,520,等於 152,480 個位元組的空間。這就是你在畫面上讀到的差距,但它無法告訴你 Googlebot 也會對實際回應標頭計入其自身容量的情況。如需深入了解該限制與標頭但書,請參閱這篇說明為何該參考值無法保證 Googlebot 抓取的文章。
輸出未涵蓋的部分,以及為何這很重要
這個分析器不是網路瀑布圖、不是壓縮計算機、也不是 Core Web Vitals 測試工具;要正確解讀結果,就必須承認它看不到的部分。HTTP 回應標頭、gzip 或 Brotli 傳輸大小、用戶端後期的 DOM 變更,以及任何外部資源的回應大小,全都落在貼上主體量測範圍之外。分析器無法得知伺服器是否會依使用者代理、地區設定、驗證狀態或裝置來變化回應,也不知道被參照的樣式表是 4 KB 還是 400 KB。若需要這些事實,正確的下一步是透過瀏覽器 DevTools 或對經授權的公開回應執行 curl,然後重新貼上實際送達的主體。
另外還有兩個相關限制會影響解讀方式。解析器使用一個獨立的 template 片段與瀏覽器原生 HTML 標記解析器,因此 textarea、title、script、style 及其他原始文字邊界都能正確處理;巢狀 template 內容會保持非作用狀態,且不會列入資源清單。嚴格的輸入上限、共用元素上限,以及有限的 URL 顯示,能防止結果檢視被意外的全站傾印或惡意標記炸掉;因此若分析器對某個計數設上限或修剪某個項目,請將其視為刻意的安全護欄,而不是量測錯誤。如需更完整說明 URL 文字與檔案酬載在結果中的差異,請參閱這篇關於結果中外部檔案大小的解析。
善用結果,但不盲目相信
請把這些數據當作除錯地圖,而不是最終判決。內嵌 script 位元組數很大時,通常指向序列化的應用程式狀態、重複的 hydration 資料,或嵌入的函式庫。內嵌 style 位元組數很大時,通常指向重複的關鍵 CSS。資料 URI 總計很大時,通常代表有 Base64 圖片或字型直接內嵌於標記中,這類內容以獨立可快取檔案託管會更省成本。外部資源清單很長可能顯示出重複的標籤,但參照次數本身不是效能分數,因此優先順序應由位元組加權的欄位決定,而非 URL 清單。
找出熱點後,請做出最小且誠實的修改,並重新量測實際部署的回應。將適合的程式碼移至可快取的外部檔案、移除重複的序列化資料、避免在資料 URI 中嵌入大型二進位酬載,並把關鍵中繼資料與內容放在回應的前段。然後檢查部署後的位元組數、回應標頭、渲染後的頁面與索引證據,不要預設較小的貼上數字就能保證被爬取、索引或排名。這項結果是可靠的主體量測,但它並不是對 Googlebot 的承諾。