HTML 頁面權重分析器會測量您所提供的 HTML 回應主體的位元組大小，並將該數字與透明的參考值(例如 Googlebot 目前的每個 URL 抓取上限 2,000,000 位元組)進行比較。測量會在本地對您貼到頁面中的文字執行，而不是對實際運作的 URL，因此結果會精確反映您提供的內容，而不是估計的傳輸量。標題數字是 UTF-8 位元組計數，而不是 JavaScript 字串長度，這一點很重要，因為 ASCII 字元佔一個位元組，而帶腔字母、CJK 文字和表情符號會佔用更多。分析器還會區分行內指令碼和樣式所佔的比例、任何嵌入的 data URI 的權重，以及外部資源參考的有限清單，因此您可以區分出一個本身就很龐大的文件，以及一個只是指向龐大檔案的文件。將該主體權重與 2 MB 參考值進行比較，即可保守地繪出文件本身距離 Google 公開紀錄上限有多近，同時將 HTTP 標頭、另外抓取的資源，以及任何用戶端 DOM 變更明確排除在計算之外。
為什麼首次執行對 HTML 頁面權重很重要
頁面權重或頁面大小分析器會告訴您，文件本身對搜尋引擎或瀏覽器接收到的內容貢獻了多少位元組。許多效能問題的根源在於文件本身很龐大，而非文件所參考的檔案，因此先測量回應主體，就能在追逐網路瀑布圖或 Core Web Vitals 之前獲得一個乾淨的基準。執行一次分析器，是確認您的 HTML 是小、适中，還是逐漸逼近搜尋引擎針對抓取預算和渲染預算所紀錄的上限，最便宜的方式。
當首次執行顯示文件遠低於 2 MB 參考值時，您就可以繼續進行其他最佳化工作。當首次執行顯示文件接近或超過參考值時，行內指令碼、行內樣式和 data URI 的細項會指出權重實際所在的位置。這個早期訊號能節省時間，因為您可以在原始碼中修正最大的熱點，而不是猜測哪一個外部請求才是緩慢頁面背後的真正元凶。
這個分析器實際計算與略過的內容
HTML 頁面權重分析器會測量您貼上的原始碼。它會使用瀏覽器的 TextEncoder API 回報該文字的確切 UTF-8 位元組長度，再加上 Unicode 碼點數、行內指令碼和樣式元素內部的位元組比例、data URI 屬性值所佔的位元組，以及外部資源參考的有限清單。所有運作都在瀏覽器中完成。HTML 不會被上傳、當作頁面抓取，或執行。
這個範圍有一組對應的排除項目值得在首次執行前了解。HTTP 標頭、gzip 或 Brotli 傳輸大小、伺服器設定、快取行為、較晚發生的用戶端 DOM 變更、頁面所參考的外部檔案大小、執行成本，以及 Google 實際索引的內容，都排除在此計算之外。2,000,000 位元組的比較，被明確標示為對應 Google 現行文件的十進位參考值，而非保證 Googlebot 會接收整個頁面。如果您需要的是那些被排除的事實，瀏覽器 DevTools 或針對已部署回應的授權 curl 擷取，才是合適的工具。
為首次貼上選擇最佳來源
首次執行中最重要的單一決定，就是要餵給分析器什麼內容。分析器只能測量它收到的內容，因此乾淨的輸入會產生有用的數字，而被竄改過的輸入則會產生誤導性的數字。當您想要獲得真實的 HTML 頁面大小讀數時，有兩種擷取方法明顯優於其他方法。
| 輸入來源 | 擷取內容 | 為何適用於此分析器 |
|---|---|---|
| 瀏覽器檢視原始碼 | 原始未壓縮的回應主體 | 符合 JavaScript 執行前伺服器送出的內容 |
| 授權的 curl 擷取 | 傳送給用戶端的確切位元組 | 在進行任何解碼前儲存時，符合線路傳輸的承載 |
| JavaScript 執行後的 Elements 面板 | 變更後的即時 DOM | 包含伺服器從未送出的變更，並省略原始碼細節 |
| 儲存的瀏覽器快取檔案 | 可能已壓縮的承載 | 位元組計數不再符合分析器所需的回應主體 |
如果伺服器會依使用者代理、語言環境、驗證或裝置而改變其回應，請針對每個變體分別擷取具代表性的回應。在錯誤的輸入上進行首次執行，會迫使您在已部署的位元組真正重要時重做分析，並失去讓工具發揮作用的執行間比較。
執行您的首次 HTML 權重分析
以下是使用 HTML 頁面權重分析器 進行完整首次執行的步驟。
- 從檢視原始碼、授權的 curl 執行，或其他能回傳實際送出位元組的方法，擷取原始未壓縮的 HTML 回應主體。
- 將擷取到的文字貼到分析器的輸入區域。不要貼上 JavaScript 執行後從 Elements 面板取得的快照。分析器會強制執行嚴格的輸入上限，以避免過大的貼上內容阻斷主執行緒，因此非常大的文件可能會在任何分析執行前就被拒絕。
- 執行分析並檢視 UTF-8 位元組總數、2,000,000 位元組主體參考值、行內指令碼與樣式所佔比例、data URI 位元組總計，以及有限的外部資源清單。
- 找出最大的原始碼層級熱點。細項會告訴您權重是落在行內指令碼、行內樣式、嵌入的 data URI，還是單純落在重複的標記中。
- 對原始碼進行最小且誠實的修改，重新部署頁面，並重新測量新的回應主體。在假設最佳化生效前，請先在實際送出的頁面上確認新的位元組計數。
首次執行不需要做到鉅細靡遺。擷取文件、執行分析、讀取標題數字即可。詳細細項只有在那些數字之一指向意料之外之處時(例如 data URI 總計大於所有外部參考加總)才會變得重要。
將您的數字與 2 MB 參考值進行比較
介面會顯示您貼上的位元組總數與 2,000,000 位元組參考值之間的差異，並顯示 HTTP 標頭的相關警告。遠低於參考值的文件，其主體權重仍有餘裕，您可以專注於其他最佳化。落在參考值最後大約一百 KB 範圍內的文件，則是一個訊號，表示任何進一步的成長，都可能失去已被公開紀錄限制消耗給標頭的位元組。
光是在主體位元組上就超過參考值的文件，是最明確的首次執行警告。由於 2,000,000 位元組的額度已根據 Google 目前的技術文件 將 HTTP 標頭納入計算，因此主體已超過參考值的文件，在抓取預算中就不會留下任何標頭空間。這是主體參考值，而非抓取保證，因此正確的下一步是縮減文件本身，而不是假設 Googlebot 會抓取超出部分。
修正最大的熱點並重新測量
將首次執行的細項視為一張除錯地圖。龐大的行內指令碼位元組，通常指向序列化後的應用程式狀態、重複的水合資料，或應屬於可快取外部檔案的內嵌程式庫。龐大的行內樣式位元組，通常指向可以去除重複或精簡的重複關鍵 CSS。龐大的 data URI 總計，通常指向直接內嵌於標記中的 Base64 圖片或字型，這類內容通常可以移至具有適當快取標頭的外部檔案。
修正一個熱點之後，請重新測量已部署的回應，而不是單獨測量這項變更。值得信賴的真實數字，是變更上線後來自即時回應的新位元組計數。貼上的輸入若不再反映伺服器送出的內容，是失去對分析信心最快的途徑;只要輸入擷取方法保持一致，分析器就能讓各次執行之間的比較變得輕而易舉。
測量範圍之外的內容
了解分析器不做什麼，是入門的一部分。它不是網路瀑布圖、壓縮計算機，也不是 Core Web Vitals 測試。它不會知道 gzip 或 Brotli 傳輸大小、伺服器標頭、快取行為、較晚發生的用戶端 DOM 變更、參考檔案的回應大小、執行成本、渲染成本，或 Google 實際索引的內容。若需要這些事實，瀏覽器 DevTools 或針對授權公開回應的 curl，仍是合適的工具。
會扭曲首次讀數的常見陷阱，包括貼上隱藏重複的正式環境已壓縮回應、在水合指令碼注入內容後複製 Elements 面板，以及將正式環境中較小的數字視為正式環境中較小數字的證明。扭曲您 HTML 頁面大小分析器結果的常見錯誤 一文會更詳細地說明這些模式。
使用分析器的首次執行，應該會為您留下三件事:原始 HTML 回應主體的誠實 UTF-8 位元組計數、權重在該主體內分布的清晰圖像，以及文件是舒適地落在、接近，或超出公開紀錄的 2 MB 邊界的穩定參考。從那時起，之後的每次測量都會是一種比較而非猜測，而每次原始碼變更也都會成為可驗證的最佳化，而非寄望式的調整。
若想進一步了解，請參閱 從 HTML 提取連結:來源、基礎 URL 與計數。