最佳化文字型素材資源的編碼和傳輸大小

Ilya Grigorik

Jeremy Wagner

除了避免下載不必要的資源，提升載入網頁速度的最佳做法，就是最佳化及壓縮其餘資源，盡可能縮減整體下載大小。

資料壓縮入門

設定網站避免下載任何未使用的資源後，下一步是壓縮瀏覽器必須下載的所有剩餘合格資源。視資源類型 (文字、圖片、字型等) 而定，有許多不同的技術可供選擇：可在網路伺服器上啟用的通用工具、特定內容類型的預先處理最佳化，以及需要開發人員輸入的資源專屬最佳化。

如要達到最佳效能，必須結合下列所有技術：

• 壓縮是指使用較少位元對資訊編碼的程序。
• 消除不必要的資料，一律能獲得最佳結果。
• 壓縮技術和演算法有很多種。
• 您需要使用多種技術，才能達到最佳壓縮效果。

縮減資料大小的程序稱為資料壓縮。許多人貢獻了演算法、技術和最佳化方法，以提高壓縮率、壓縮速度，以及各種壓縮演算法所需的記憶體。

資料壓縮的完整討論已超出本指南的範圍。不過，您必須大致瞭解壓縮的運作方式，以及如何運用相關技術縮減網頁所需各種素材資源的大小。

為說明這些技術的核心原則，請考慮最佳化簡單簡訊格式的程序，該格式是專為本範例而發明：

# Below is a secret message, which consists of a set of headers in
# key-value format followed by a newline and the encrypted message.
format: secret-cipher
date: 08/25/16
AAAZZBBBBEEEMMM EEETTTAAA

1. 訊息可能包含任意註解 (有時稱為「註解」)，並以「#」前置字元表示。註解不會影響訊息的意義或行為。
2. 訊息可能包含「標頭」，也就是出現在訊息開頭的鍵/值組合 (在上述範例中以 ":" 分隔)。
3. 訊息會攜帶文字酬載。

如何縮減前一則訊息的大小 (從 200 個字元開始)？

1. 這則註解很有趣，但不會影響訊息的意思。傳送訊息時，請消除這類內容。
2. 有一些技術可以有效率地編碼標頭。舉例來說，如果您知道所有訊息都有「format」和「date」，可以將這些訊息轉換為短整數 ID，然後只傳送這些 ID。不過，這可能不是真的，所以最好先不要管它。
3. 酬載僅限文字。雖然我們不知道內容究竟是什麼 (顯然是使用 "secret-cipher")，但光看文字就知道其中有很多冗餘。或許您可以計算重複字母的數量，並以更有效率的方式編碼，而不是傳送重複的字母。舉例來說，"AAA" 會變成 "3A"，代表三個 A 的序列。

結合這些技術後，會產生以下結果：

format: secret-cipher
date: 08/25/16
3A2Z4B3E3M 3E3T3A

新訊息長度為 56 個字元，表示您已將原始訊息壓縮 72%。這項降幅相當可觀！

這個範例說明壓縮演算法如何有效減少文字資源的傳輸大小。在實務上，壓縮演算法比上述範例複雜得多，在網路上，壓縮演算法可用來大幅縮短資源下載時間。對文字型素材資源套用壓縮功能後，網頁載入資源的時間就會縮短，使用者也能更快看到這些資源的效果。

壓縮：預先處理和特定情境最佳化

這裡討論的第一種技術是壓縮。雖然壓縮並非嚴格的壓縮演算法，但可以移除原始碼中不必要和多餘的字元，讓使用者更容易閱讀資源。不過，在正式版網站上，原始碼的功能不需具備可讀性，而且可讀性可能會延遲網頁資源的載入。

壓縮是一種內容專屬的最佳化作業，可大幅縮減傳送資源的大小，最好在建構和部署程序中套用。舉例來說，套裝軟體是常用的軟體類型，可在將新的正式版程式碼部署至網站之前，自動壓縮資源。

壓縮多餘或不必要資料的最佳方法是將其刪除。不過，您無法任意刪除資料。不過，在某些情況下，如果我們對資料格式及其屬性有特定內容的知識，就有可能大幅縮減酬載的大小，而不會影響其實際意義或功能。

<html>
  <head>
    <style>
      /* awesome-container is only used on the landing page */
      .awesome-container {
        font-size: 120%;
      }

      .awesome-container {
        width: 50%;
      }
    </style>
  </head>
  <body>
    <!-- awesome container content: START -->
    <div>
      This is my awesome container, and it is <em>so</em> awesome.
    </div>
    <!-- awesome container content: END -->
    <script>
      awesomeAnalytics(); // Beacon conversion metrics
    </script>
  </body>
</html>

請參考先前的 HTML 程式碼片段，以及其中包含的三種不同內容類型：

1. HTML 標記。
2. CSS：自訂網頁呈現方式。
3. JavaScript：用於支援互動和其他進階網頁功能。

每種內容類型都有不同的規則，用來定義有效內容、指定註解等。不過，接下來的問題是「如何縮減這個網頁的大小？」

• 程式碼註解是開發人員的好幫手，但瀏覽器不需要！移除 CSS (/* ... */)、HTML (<!-- ... -->) 和 JavaScript (// ...) 註解，可減少網頁及其子資源的總傳輸大小。
• 「智慧型」CSS 壓縮器可能會注意到我們使用低效率的方式定義 .awesome-container 的規則，並將兩個宣告合併為一個，而不影響任何其他樣式，進而節省更多位元組。在大量 CSS 規則中，移除這類冗餘內容可以累積，但可能無法積極套用，因為選取器通常必須在不同情境中重複，例如在媒體查詢中。
• 空格和 Tab 鍵是開發人員在 HTML、CSS 和 JavaScript 中使用的便利工具。額外的壓縮器可以去除所有分頁和空格。與其他簡化技術不同，只要這類空格或定位點並非網頁呈現所必需，這類最佳化作業可以相當積極地套用，例如，您會想要保留 HTML 文件中文字執行中的空格，因為它們可確保使用者實際看到的內容可讀性。

<html><head><style>.awesome-container{font-size:120%;width:50%}</style></head><body><div>This is my awesome container, and it is <em>so</em> awesome.</div><script>awesomeAnalytics()</script></body></html>

套用上述步驟後，網頁字元數從 516 減少到 204，約減少 60%。雖然可讀性不高，但只要能用就行。現代開發做法也允許您將格式良好且可讀的原始碼版本，與您提供給實際工作環境的最佳化程式碼分開。搭配來源對應 (提供可讀取的轉換後正式版程式碼，讓您更輕鬆地排解正式版中的錯誤)，您就能享有良好的開發人員體驗，同時最佳化效能，提升使用者體驗。

注意：雖然上例未提及，但 SVG 圖片也是文字型資源。您可以使用 SVGO 等工具，以有損方式壓縮及最佳化 SVG。

上述範例說明瞭一個重要觀點：通用壓縮器 (例如專為壓縮任意文字而設計的壓縮器) 在壓縮上述範例中的網頁時，可能會有相當不錯的表現，但它永遠不會知道要移除註解、收合 CSS 規則，或進行其他數十種內容專屬的最佳化。因此，預先處理、壓縮和其他內容感知最佳化功能非常重要。

注意：舉例來說，熱門架構的未壓縮開發版本，比用於實際工作環境的版本大得多。舉例來說，Angular 1.8.3 的開發版本將近 1.4 MB。正式版為 177 KB。這清楚展現了這些最佳化作業的潛力！

同樣地，上述技術也可以延伸到文字以外的素材資源。圖片、影片和其他內容類型都包含各自形式的中繼資料和各種酬載。舉例來說，每當您使用相機拍照時，相片檔案通常會嵌入許多額外資訊，例如相機設定、位置等。視應用程式而定，這類資料可能非常重要 (例如相片分享網站)，也可能完全無用。請考慮是否值得移除。實際上，每張圖片的中繼資料最多可達數十 KB。

簡而言之，如要最佳化素材資源效率，第一步是建立不同內容類型的清單，並考慮可套用哪些內容專屬的最佳化設定，以縮減其大小。接著，在找出這些最佳化項目後，將其新增至建構和發布步驟，以自動執行這些最佳化項目，確保每次發布至正式版時都能一致套用最佳化項目。

使用壓縮演算法壓縮文字

縮減文字素材資源大小的下一步，是對這些素材資源套用壓縮演算法。這項技術更進一步，在將文字型酬載傳送給使用者之前，會積極搜尋可重複的模式，並在酬載到達使用者瀏覽器時解壓縮。結果是進一步大幅減少這些資源，並縮短下載時間。

• gzip 和 Brotli 是常用的壓縮演算法，最適合用於文字型素材資源：CSS、JavaScript、HTML。
• 所有新式瀏覽器都支援 gzip 和 Brotli 壓縮，並會在 Accept-Encoding HTTP 要求標頭中，宣告支援這兩種壓縮方式。
• 伺服器必須設為啟用壓縮功能。網路伺服器軟體通常會預設啟用模組，壓縮文字型資源。
• gzip 和 Brotli 都可以微調，透過調整壓縮等級來提高壓縮率。如果是 gzip，壓縮設定範圍為 1 到 9，9 為最佳。Brotli 的範圍是 0 到 11，11 為最佳。不過，壓縮設定越高，所需時間越長。對於動態壓縮的資源 (即在要求時壓縮)，中等範圍的設定通常能在壓縮率和速度之間取得最佳平衡。不過，您可以使用靜態壓縮，也就是預先壓縮回應，因此可以針對每種壓縮演算法，使用最積極的壓縮設定。
• 內容傳遞網路 (CDN) 通常會自動壓縮符合條件的資源。CDN 也能為您管理動態和靜態壓縮，讓您少一項需要擔心的壓縮問題。

gzip 和 Brotli 是常見的壓縮工具，可套用至任何位元組串流。在幕後，它們會記住先前檢查過的檔案內容，然後嘗試以有效率的方式尋找並取代重複的資料片段。

注意：如要深入瞭解壓縮的運作方式，請觀看這部影片，其中詳細說明瞭 gzip。如要嘗試文字壓縮，請試用我們的 gzip 和 Brotli 程式碼實驗室。

在實務上，gzip 和 Brotli 在文字內容上的成效最佳，大型檔案的壓縮率通常可達 70% 至 90%。不過，如果對已使用其他演算法壓縮的素材資源 (例如大多數使用無損或有損壓縮技術的圖片格式) 執行這些演算法，則幾乎不會有任何改善。

所有新式瀏覽器都會在 Accept-Encoding HTTP 要求標頭中，宣傳對 gzip 和 Brotli 的支援。不過，代管服務供應商有責任確保網路伺服器設定正確，以便在用戶端要求時提供壓縮資源。

檔案	演算法	未壓縮時的大小	壓縮後的大小	壓縮比
angular-1.8.3.js	Brotli	1,346 KiB	256 KiB	81%
angular-1.8.3.js	gzip	1,346 KiB	329 KiB	76%
angular-1.8.3.min.js	Brotli	173 KiB	53 KiB	69%
angular-1.8.3.min.js	gzip	173 KiB	60 KiB	65%
jquery-3.7.1.js	Brotli	302 KiB	69 KiB	77%
jquery-3.7.1.js	gzip	302 KiB	83 KiB	73%
jquery-3.7.1.min.js	Brotli	85 KiB	27 KiB	68%
jquery-3.7.1.min.js	gzip	85 KiB	30 KiB	65%
lodash-4.17.21.js	Brotli	531 KiB	73 KiB	86%
lodash-4.17.21.js	gzip	531 KiB	94 KiB	82%
lodash-4.17.21.min.js	Brotli	71 KiB	23 KiB	68%
lodash-4.17.21.min.js	gzip	71 KiB	25 KiB	65%

上表顯示 Brotli 和 gzip 壓縮技術可為幾個知名 JavaScript 程式庫節省的空間。節省幅度介於 65% 到 86% 之間，具體取決於檔案和演算法。供參考：Brotli 和 gzip 的每個檔案都套用了最大壓縮等級。盡可能優先使用 Brotli，而非 gzip。

重要事項：上表清楚顯示，在壓縮和縮減等最佳化作業上套用壓縮，可進一步節省費用。壓縮不一定會讓縮減效果變得毫無意義，而是一種附加最佳化。

啟用壓縮功能是最簡單有效的最佳化做法之一。如果網站未善用這項功能，就等於錯失提升使用者體驗的大好機會。幸好，許多網路伺服器都提供預設設定，可啟用這項重要最佳化功能，尤其是 CDN，在實作這項功能時，能有效平衡壓縮速度和比率。

如要快速查看壓縮功能，請開啟 Chrome 開發人員工具，開啟「Network」(網路) 面板，載入您選擇的頁面，然後觀察網路面板的最底部。

所有網頁資源的傳輸大小 (即壓縮後) 與實際大小的比較圖，如 Chrome 開發人員工具的網路面板所示。

如上圖所示，您應該會看到以下項目的細目：

• 要求數量，也就是為網頁載入的資源數量。
• 所有要求的傳輸大小。這反映了對網頁資源套用壓縮的效果。
• 所有要求的資源大小。這反映了網頁資源解壓縮「後」的大小。

注意：有時壓縮演算法可能會增加資產的大小。這通常發生在未壓縮的素材資源非常小，且演算法的負擔高於壓縮節省的空間，或資源已妥善壓縮時。為避免這個問題，部分伺服器允許您指定檔案大小下限門檻，通常小於 4 或 5 KB。

對 Core Web Vitals 的影響

除非有指標能反映成效提升，否則無法評估成效提升。Core Web Vitals 計畫旨在建立並提升對反映實際使用者體驗指標的認識。這與簡單的網頁載入時間等指標不同，後者無法清楚反映使用者體驗品質。

當您按照本指南所述，對網站資源進行最佳化調整時，Core Web Vitals 的成效可能會因最佳化資源和涉及的指標而異。不過，在某些情況下，套用這些最佳化設定可以改善網站的 Core Web Vitals：

• HTML 資源經過縮減和壓縮後，可加快 HTML 載入速度，並提高子資源的曝光度，進而加快載入速度。這有助於提升網頁的最大內容繪製 (LCP)。雖然 rel="preload" 等資源提示可用來影響資源的曝光度，但使用過多提示可能會導致頻寬爭用問題。確保導覽要求的 HTML 回應經過壓縮，預先載入掃描器就能盡快發現其中的資源。
• 部分 LCP 候選元素也可以透過壓縮技術加快載入速度。舉例來說，如果 SVG 圖片是 LCP 候選項目，可以透過文字壓縮減少資源載入時間。這與您對其他圖片類型進行的最佳化不同，其他圖片類型本質上是透過其他壓縮方法壓縮，例如 JPEG 圖片使用有損壓縮。
• 此外，文字節點也可能是 LCP 候選項目。本指南所述技術的使用方式，取決於您是否在網頁上使用網頁字型。如果您使用的是網路字型，則適用網路字型最佳化最佳做法。不過，如果您「不」使用網頁字型，而是使用系統字型，則顯示時不會產生任何資源載入時間，因此縮減及壓縮 CSS 可縮短這段時間，這表示潛在 LCP 文字節點的算繪作業可以更快完成。

結論

如何最佳化文字型素材資源的編碼和傳輸，是基本的效能概念，但影響很大。請務必盡可能確保符合縮減和壓縮資格的資源，都能從這些最佳化作業中受益。

更重要的是，請務必自動化這些程序。如要壓縮，請使用套件組合器，將壓縮套用至符合資格的資源。請確認網路伺服器設定支援壓縮功能，並使用最有效的壓縮方式。為了盡可能簡化這項作業，請使用 CDN 自動壓縮，因為 CDN 不僅能為您壓縮資源，而且速度非常快。

將這些基準效能概念融入網站架構，可確保效能最佳化工作有良好基礎，後續最佳化作業也能以良好的基準做法為基礎。