Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

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

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

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

如何縮減先前訊息的大小 (至少 200 個字元)？

註解很有趣，但不會影響訊息的意義。傳送訊息時消除。
有許多技術可有效率地編碼標頭。舉例來說，如果您知道所有訊息都有「格式」和「日期」，可以將這些訊息轉換為短整數 ID，然後只傳送這些 ID。但這可能不是事實，因此最好先不要理會。
酬載內容只能是文字。雖然我們不知道實際內容為何 (顯然是使用 "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 程式碼片段，以及其中包含的三種不同內容類型：

HTML 標記。
CSS，可自訂頁面的呈現方式。
JavaScript，用於支援互動和其他進階網頁功能。

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

程式碼註解是開發人員的好幫手，但瀏覽器不需要這些註解！移除 CSS (/* ... */)、HTML () 和 JavaScript (// ...) 註解，可減少網頁及其子資源的總傳輸大小。
「智慧」CSS 壓縮器可能會發現我們使用效率不彰的方式定義 .awesome-container 的規則，並將兩個宣告合併為一個，不會影響任何其他樣式，進而節省更多位元組。如果有一大組 CSS 規則，移除這類多餘項目可能會累積成可觀的節省量，但這可能不是可以積極套用的項目，因為選取器通常必須在不同環境中重複使用，例如在媒體查詢中。
在 HTML、CSS 和 JavaScript 中，空格和分頁是開發人員的便利工具。額外的壓縮器可能會移除所有 Tab 和空格。與其他重複資料刪除技術不同，只要網頁呈現內容時不需要這些空格或分頁符，這類最佳化可以相當積極地套用。舉例來說，您會想保留 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% 的空間。當然，這並不好讀，但也不需要好讀才能使用。此外，現代開發做法可讓您將格式良好且易於閱讀的原始碼版本，與發布至實際工作環境的經過最佳化程式碼分開。搭配來源對應 (以可讀形式呈現轉換後的正式版程式碼，方便您在正式版中排解錯誤)，您就能兼顧良好的開發人員體驗，同時為了使用者體驗而提升效能。

先前的範例說明瞭一個重點：一般用途的壓縮器 (例如用於壓縮任意文字的壓縮器) 可能可以壓縮先前的網頁，但永遠不會知道要移除註解、摺疊 CSS 規則，或進行數十種其他內容專屬的最佳化。因此，前置處理、縮小化和其他情境感知最佳化作業非常重要。

同樣地，上述技術不只適用於以文字為基礎的素材資源，圖片、影片和其他內容類型都包含各自的元資料和各種酬載。舉例來說，使用相機拍攝相片時，檔案通常會內嵌許多額外資訊，例如相機設定、位置等。視應用程式而定，這類資料可能至關重要 (例如相片分享網站)，也可能完全無用。建議您考慮是否值得移除。實際上，每張圖片的中繼資料最多可增加數十 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 和 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 開發人員工具的「網路」面板中。

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

請求數量，也就是網頁載入的資源數量。
所有要求的轉移大小。這項指標反映了套用至網頁任何資源的壓縮效果。
所有要求的資源大小。這項指標反映網頁資源解壓縮後的大小。

對 Core Web Vitals 的影響

如果沒有反映這些改善的指標，就無法衡量效能提升程度。Core Web Vitals 計畫旨在建立並宣傳可反映實際使用者體驗的指標。這與簡單的網頁載入時間等指標不同，因為這些指標無法清楚反映使用者體驗品質。

根據您最佳化的資源和相關指標，將本指南列出的最佳化做法套用至網站資源時，對 Core Web Vitals 的影響可能有所不同。不過，在下列情況下，套用這些最佳化做法可改善網站的 Core Web Vitals：

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

結論

最佳化文字型素材資源的編碼和轉移方式，是效能概念的基礎，但影響卻很大。請務必盡可能確保符合縮減和壓縮資格的資源，都能從這些最佳化做法中獲益。

更重要的是，請務必自動執行這些程序。如要縮減檔案大小，請使用 Bundler 將縮減功能套用至符合資格的資源。請確認網路伺服器設定支援壓縮功能，但更重要的是，請使用最有效的壓縮方式。為盡可能簡化這項作業，請使用 CDN 自動壓縮，因為 CDN 不僅能壓縮資源，還能快速完成這項作業。

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