應該先導入 gzip 還是 HTTP/3？

如果文字回應尚未壓縮，通常應先檢查 gzip 或 Brotli 等內容壓縮。若壓縮已正確運作，HTTP/3 在有封包遺失或延遲的網路，以及存在大量並行請求時，可能帶來額外改善。不過，真正的優先順序仍取決於 LCP 圖片、會阻礙轉譯的 CSS 或 JavaScript，或 TTFB 是否才是較大的瓶頸。

使用 HTTP/3 後，還需要 gzip 嗎？

需要。HTTP/3 的 QPACK 是 HTTP 標頭的壓縮方式；gzip 則是壓縮 HTML、CSS、JavaScript 與 JSON 等回應主體的內容編碼。兩者適用於不同層級，也可搭配使用。

對圖片套用 gzip 會讓圖片載入更快嗎？

一般不會。JPEG、WebP、AVIF、影片與音訊等已壓縮的檔案，再以 gzip 壓縮通常收益很小，還可能增加處理額外負擔。要改善圖片效能，更重要的是使用合適尺寸與格式，並優先處理必須先載入的圖片。

HTTP/3 一定會縮短每位使用者的載入時間嗎？

不一定。HTTP/3 透過 QUIC 的獨立串流，可減少封包遺失對其他串流的影響範圍，但它無法直接解決伺服器處理緩慢、圖片過大、會阻礙轉譯的資源或 JavaScript 執行時間等問題。應在真實使用者環境中分別衡量 HTTP/2 與 HTTP/3。

可以只提供 Brotli 而不提供 gzip 嗎？

現代瀏覽器普遍支援 Brotli，但伺服器仍須檢查請求中的 Accept-Encoding 標頭，並選擇用戶端可接受的編碼。實務上通常會提供 Brotli，同時保留 gzip 作為相容性備援。

gzip 與 HTTP/3 是什麼？改善網頁載入效能時應優先處理哪一項？

作者 쉬었음.com發布 2026年9月12日

gzip 是透過壓縮網頁文字檔案，減少必須傳輸的資料量的方法；HTTP/3 則是透過 QUIC 傳遞 HTTP，改變多個請求的處理方式與封包遺失的因應方式。兩者都能改善頁面載入，但解決的不是同一種問題。與其問「gzip 和 HTTP/3 哪個更快？」，更準確的問題是先找出目前頁面的瓶頸在哪裡：傳輸位元組數、網路遺失、伺服器回應、圖片、轉譯，還是 JavaScript。www.rfc-editor.org datatracker.ietf.org

實務上最常見的誤解之一，是啟用 HTTP/3 就會自動讓整個網站變快。HTTP/3 可以是重要的基礎改善措施，但無法取代對首屏超大圖片、阻礙轉譯的 CSS 或 JavaScript，或緩慢伺服器回應的解決方案。反過來說，若網站完全沒有壓縮文字回應，只需較小的設定變更，啟用 gzip 或 Brotli 就能明顯減少傳輸量。web.dev developer.mozilla.org

gzip 到底是什麼？

gzip 是 HTTP 廣泛使用的內容編碼（Content-Encoding）。伺服器會先以 gzip 格式壓縮原始 HTML、CSS、JavaScript、JSON、SVG 及類似內容，再傳送給瀏覽器；瀏覽器解壓縮後使用原始內容。HTTP Semantics 規範將 gzip 定義為使用 LZ77 家族壓縮與 32 位元 CRC 的內容編碼。www.rfc-editor.org www.rfc-editor.org

關鍵在於，檔案的邏輯類型不會改變。例如，伺服器即使以 gzip 傳遞 app.js，瀏覽器最終執行的仍是相同的 JavaScript。改變的是經由網路傳輸的位元組數。檔案變小後，在頻寬有限的情況下下載所需時間較短，也可減少使用者的行動數據用量。www.rfc-editor.org developer.chrome.com

瀏覽器與伺服器如何選擇壓縮方式？

瀏覽器透過 Accept-Encoding 請求標頭表明自己可解碼哪些壓縮格式。伺服器會根據該清單及其優先順序選擇適當的表示形式，並在回應中加入 Content-Encoding: gzip 或 Content-Encoding: br 等標頭。br 代表 Brotli。www.rfc-editor.org developer.mozilla.org

如果伺服器或 CDN 會依壓縮方式，針對相同 URL 提供不同回應，通常會傳送 Vary: Accept-Encoding，讓快取能區分這些回應。否則，為某個用戶端儲存的壓縮表示形式，可能會被不適當地重複用於條件不同的請求。www.rfc-editor.org

以下為概念流程：

瀏覽器宣告支援的格式，例如 Accept-Encoding: br, gzip。
伺服器或 CDN 在檔案的 Brotli、gzip 或未壓縮版本中選擇一種。
它會在回應主體旁以 Content-Encoding 標示所選格式。
瀏覽器在接收期間或接收後解壓縮回應，接著繼續 HTML 剖析、CSS 套用與 JavaScript 執行。

gzip 在這個過程中可縮短傳輸時間，但不會消除瀏覽器剖析及執行 JavaScript 所花費的時間。壓縮只是效能的一環，不是所有延遲來源的解方。developer.chrome.com web.dev

哪些檔案適合從 gzip 受益？

gzip 特別適合包含大量重複字串與結構的文字。HTML 標籤、CSS 選取器、JavaScript 識別字與語法，以及 JSON 欄位名稱等具有大量重複的資料，壓縮後的傳輸大小可大幅縮小。一般網站效能指引也建議對文字資源套用壓縮，並排除本身已經壓縮的資產。developer.mozilla.org web.dev

資產類型	gzip 的一般評估	應優先檢查的項目
HTML	通常適合	伺服器回應時間、快取、文件大小
CSS	通常適合	移除未使用的 CSS、管理關鍵 CSS
JavaScript	通常適合	程式碼分割、移除未使用程式碼、執行時間
JSON 與 API 回應	通常適合	回應設計、快取、移除不必要欄位
SVG	通常適合	清理並簡化 SVG
JPEG、WebP、AVIF	通常不適合	圖片尺寸、格式、回應式傳遞
MP4 與音訊	通常不適合	位元率、串流、延遲載入

對於 JPEG、WebP、AVIF、影片、音訊與壓縮封存檔等本身已進行壓縮的格式，再套用 gzip 的效益可能很小。小檔案也是如此。web.dev 說明，小於約 1 KiB 的資源可能壓縮效率不佳，或無法帶來有意義的節省。developer.mozilla.org web.dev

此處重要的區分是傳輸大小與原始大小。在開發者工具的 Network 面板中，可以比較壓縮後的下載大小與未壓縮大小，也可查看 Content-Encoding 回應標頭，驗證是否確實套用了壓縮。developer.chrome.com

gzip 與 Brotli 有何不同？

Brotli 並不是 gzip 的後繼者，而是可與 gzip 並列選用的另一種 HTTP 內容壓縮演算法。在現代網路上，常見做法是優先對文字資產提供 Brotli，同時也為無法使用 Brotli 的用戶端提供 gzip。由於瀏覽器會傳送 Accept-Encoding 且伺服器會協商結果，因此相同 URL 可依用戶端傳送不同的壓縮表示形式。developer.mozilla.org developer.mozilla.org

一般而言，Brotli 對網頁文字可產生比 gzip 更小的結果。但這不一定代表整體體感頁面速度會等比例改善。若節省的位元組不多，或瓶頸在於圖片、伺服器處理或 JavaScript 執行，從 gzip 改為 Brotli 的影響可能有限。對於動態壓縮的伺服器，提高壓縮率的設定也可能增加 CPU 使用量與回應延遲。因此，靜態資產應在建置或 CDN 階段預先壓縮；動態回應則應根據實際負載調校。web.dev web.dev

換句話說，選擇標準更接近以下原則，而非「Brotli 永遠更好」：

若文字資產很大，且首次訪客很多，可考慮同時提供 Brotli 與 gzip。
若 CDN 已提供合適的壓縮，請勿在應用程式中再次壓縮相同內容。
對伺服器 CPU 受限的動態服務，應衡量壓縮等級與 TTFB 的平衡。
若圖片與影片占頁面很大比例，媒體最佳化可能應排在文字壓縮之前。

HTTP/3 改變了什麼？

HTTP/3 是一項標準，在保留 HTTP 請求—回應語意的同時，以 QUIC 取代 TCP 作為傳輸基礎。QUIC 運作於 UDP 之上，但並不只是「透過 UDP 傳送 HTTP」而已。它提供連線建立、加密、可靠性、壅塞控制及多工串流等功能，HTTP/3 則使用這些功能傳遞 HTTP 訊息。datatracker.ietf.org developer.mozilla.org

HTTP/1.1 在單一連線上處理請求有顯著限制，因此平行使用多個 TCP 連線的做法一度相當普遍。HTTP/2 則透過在一條 TCP 連線上多工處理多個請求來改善此問題。然而，TCP 保證接收資料依序交付；當連線上有封包遺失時，後續抵達的資料必須等到遺失資料恢復後，才能依序交給應用程式。在 HTTP/2 中，這種 TCP 層級的延遲可能影響多個 HTTP 串流。datatracker.ietf.org www.rfc-editor.org

HTTP/3 的 QUIC 會針對每個串流管理可靠且有序的資料交付。因此，某個串流上的資料遺失不一定也要讓無關串流停止。RFC 9000 說明，封包遺失時，只有包含該封包資料的串流會在等待重傳期間遭到阻塞，其他串流仍可繼續運作。www.rfc-editor.org

「消除隊頭阻塞」這種說法有多準確？

HTTP/3 主要處理的是整條連線上的傳輸層隊頭阻塞。將此理解為所有等待都會消失並不正確。

首先，單一串流內仍須維持順序。若同一串流中較前段的內容遺失，例如 HTML 文件主體或一張大型圖片，該串流後續資料要在所需順序恢復前，無法完整使用。其次，若多個串流的資料包含在同一個 QUIC 封包中，該封包遺失仍可能同時延遲其中數個串流。www.rfc-editor.org

因此，HTTP/3 的效益在有封包遺失或重新排序的網路上可能特別明顯。相對地，若是在低延遲、低遺失的有線網路上檢視小型頁面，與 HTTP/2 的差異可能很小，或會因測量條件而異。這是因為 HTTP/3 並非能神奇減少位元組的技術；它是一種降低傳輸期間等待擴散範圍的架構。datatracker.ietf.org www.rfc-editor.org

HTTP/3 的 QPACK 與 gzip 有何不同？

HTTP/3 包含名為 QPACK 的標頭壓縮機制。這可能讓人誤以為 HTTP/3 內含 gzip，但兩者壓縮的目標不同。QPACK 的設計目的是有效表示 HTTP 請求與回應中的標頭欄位，例如 Cookie、Content-Type 與 Cache-Control。gzip 與 Brotli 則是壓縮 HTML、CSS、JavaScript 等回應主體的內容編碼。datatracker.ietf.org www.rfc-editor.org

HTTP/2 的 HPACK 仰賴標頭壓縮狀態會依序傳遞的前提，但這個前提難以原封不動套用至 QUIC 的獨立串流架構。QPACK 使用獨立的單向串流管理動態表格狀態，讓實作可以在壓縮效率與標頭阻塞風險之間取得平衡。datatracker.ietf.org datatracker.ietf.org

從實際頁面效能的角度，可將其角色理解如下：

gzip 與 Brotli：減少文字主體的傳輸量。
QPACK：改善請求與回應標頭的傳輸效率。
HTTP/3 與 QUIC：降低多個請求及遺失情況下，傳輸延遲擴散到其他請求的範圍。
快取：避免已接收過的資源再次傳輸。
圖片與程式碼最佳化：減少原本就必須下載及處理的工作量。

它們不是互相競爭、只能擇一的選項，而是因應不同瓶頸的互補方法。

網頁體感速度中更大的瓶頸有哪些？

使用者感受到的載入速度不是單一數字。伺服器送出第一個位元組前的時間、首屏主要內容可見前的時間，以及按鈕和輸入欄位開始回應前的時間，都可能因不同原因而延遲。尤其是 LCP（Largest Contentful Paint，最大內容繪製）代表視窗內最大的圖片、文字區塊或影片完成轉譯的時間點，因此適合用來評估初始頁面體驗。web.dev

LCP 緩慢不一定表示網路壓縮是原因。web.dev 建議在診斷 LCP 時，分開檢視 TTFB、資源載入延遲、資源載入時間及元素轉譯延遲。例如，即使圖片下載很快，大型 CSS 仍可能阻礙轉譯；或者主執行緒忙於長時間 JavaScript 工作，無法顯示圖片。web.dev

首屏圖片是瓶頸時

最大的首屏元素通常是圖片，例如商品詳情頁的大型商品照、新聞首頁的主視覺，或旅遊頁的橫幅。在此情況下，啟用 gzip 對 JPEG、WebP 或 AVIF 檔案本身幫助不大。更有效的方法是以符合顯示尺寸的大小提供圖片、使用適當的現代格式，並避免透過 loading="lazy" 延遲 LCP 圖片。必要時可用 fetchpriority="high" 提供優先順序提示，但若不加區別地為許多圖片設定高優先權，反而可能造成競爭。web.dev web.dev

CSS 與 JavaScript 是瓶頸時

CSS 具有阻礙轉譯的特性，因為它會避免內容以未套用樣式的狀態出現。然而，過大的 CSS、初始畫面不需要的 CSS，以及同步載入的指令碼，都可能延遲主要內容顯示。即使傳輸已完成，大型 JavaScript bundle 仍會占用瀏覽器主執行緒進行剖析、編譯與執行，因此只透過 gzip 縮小下載大小可能不夠。developer.chrome.com web.dev

因此，JavaScript 效能應與壓縮分開檢視。可考慮移除未使用程式碼、延遲載入初始畫面不需要的功能、拆分長工作，以及盡可能使用伺服器端轉譯或預先轉譯，讓初始 HTML 能揭露核心內容與可發現的資源。不過，伺服器端轉譯也可能增加伺服器處理時間並影響 TTFB，因此架構變更應透過測量評估。web.dev

伺服器回應與快取是瓶頸時

當 TTFB 很長時，瀏覽器在收到 HTML 前難以發現後續資源。常見原因包括伺服器距離遙遠、冗長的資料庫處理與個人化作業、不必要的重新導向，以及未善用的快取機會。HTTP/3 在此情況下可以改善傳輸階段的一部分，但無法直接縮短伺服器產生第一個回應所需的時間。web.dev

快取與其他效能改善的性質不同。gzip 以較小的形式傳送相同資料，HTTP/3 改變傳遞資料所用的連線特性，而快取則在符合條件的重複造訪時避免再次傳送資料。對重複訪客占比高的服務，適當的快取政策可能比更換壓縮演算法帶來更大的體感差異。然而，對於經常變動或依使用者而異的回應（例如 HTML），快取策略必須更審慎設計。www.rfc-editor.org developer.chrome.com

依體感影響排序的實務效能改善優先順序為何？

不存在適用於每個網站的固定排名。結果會隨頁面組成、首次與重複訪客比例、使用者網路、伺服器位置及既有設定而不同。不過，對於內容、電商與服務類型的典型頁面，若主要瓶頸仍存在，以下順序適合作為調查起點。

找出延遲首屏核心內容的原因。 先檢查 LCP 圖片的大小、發現時間與優先順序；阻礙轉譯的 CSS；同步 JavaScript；以及不必要的用戶端轉譯。web.dev
檢視伺服器回應時間與快取。 檢查 TTFB、重新導向、CDN 佈點、靜態資產快取，以及後端處理延遲。web.dev www.rfc-editor.org
檢查 HTML、CSS、JavaScript 與 JSON 的文字壓縮。 若尚未壓縮，套用 gzip 或 Brotli 是高優先事項。若已正確壓縮，在相同領域的額外收益可能有限。developer.mozilla.org developer.chrome.com
降低總傳輸量並最佳化請求組成。 清理過大的圖片、指令碼與第三方資源，並將請求延後到實際需要時才發出。大型網路酬載與較長載入時間有關。developer.chrome.com developer.chrome.com
提供 HTTP/3、保留 HTTP/2 備援，並以真實流量驗證。 比較變更前後的結果，特別是在行動裝置、高延遲與有封包遺失的環境，以及有大量並行請求的頁面上。datatracker.ietf.org www.rfc-editor.org

此排名有重要例外。若應用程式有大於 1 MB 且未壓縮的文字回應，步驟 3 套用 gzip 或 Brotli 可能是短期內最大的改善。相反地，若主視覺圖片有數 MB，而文字已經以 Brotli 壓縮，圖片最佳化應優先處理。若伺服器需要數秒才能產生 HTML，後端與快取工作應先於 HTTP/3。developer.mozilla.org web.dev developer.chrome.com

若只比較 gzip 與 HTTP/3

若只在這兩項技術之間選擇，決策相對直接。

文字尚未壓縮時：通常 gzip 或 Brotli 應優先處理。它會減少必須傳輸的資料量，因此在每條支援的連線上都可期待效益。
壓縮已正確運作時：HTTP/3 的相對價值會提高。不過，實際改善仍取決於網路品質與請求結構。
圖片與影片比重高的頁面：單靠 gzip 或 HTTP/3 都不太可能解決較大的問題。應先進行媒體最佳化。
大型 JavaScript 應用程式：gzip 只是起點。還必須檢查傳輸後的執行成本，才能持續改善體感。
重複造訪很多的服務：快取命中率可能比改變壓縮方式更是關鍵變數。

因此，「gzip 一定比 HTTP/3 優先」和「HTTP/3 較新，所以一定較優先」這兩種結論都不準確。更精確的說法是：對未壓縮文字而言，內容壓縮是基準優先事項；HTTP/3 則是一項基礎最佳化，可依傳輸條件與請求模式帶來額外效益。

導入 HTTP/3 時應考慮哪些限制？

若要提供 HTTP/3，伺服器、CDN、負載平衡器、防火牆及可觀測性工具都必須能適當處理 QUIC 與以 UDP 為基礎的流量。由於部分用戶端或傳輸路徑可能無法使用 HTTP/3，通常適合採取同時提供 HTTP/2 或 HTTP/1.1 的漸進式部署。HTTP/3 標準以 QUIC 為基礎，並定義用戶端發現 HTTP/3 伺服器後建立 QUIC 連線的流程。datatracker.ietf.org

從營運角度來看，重要的是不要只根據協定切換來判斷成敗。應一併監控 HTTP/3 連線占比、失敗與重試率、TTFB、LCP、錯誤率及 CPU 使用量。尤其當 CDN 或 Proxy 位於來源伺服器前方時，來源伺服器看到的協定可能與終端使用者瀏覽器實際使用的協定不同，因此也應納入用戶端觀測。developer.chrome.com developer.chrome.com

壓縮有安全性考量嗎？

有。即使使用 HTTPS，若攻擊者可控制的輸入與機密值在相同壓縮內容脈絡中一起壓縮，攻擊者可能藉由觀察密文長度差異推測機密內容。HTTP Semantics 與 HTTP/3 規範警告，不應將敏感資料和攻擊者可控制的資料一起壓縮，並指出對敏感資料停用壓縮或分離壓縮內容脈絡是最可靠的緩解方式。www.rfc-editor.org www.rfc-editor.org

這不表示每個 gzip 回應都有危險。關鍵問題是，反射的使用者輸入、驗證相關機密，以及攻擊者可反覆發出請求並觀察回應大小的條件，是否同時存在。登入、付款與帳戶復原等敏感流程，不應機械式地套用與一般靜態資產相同的壓縮政策；應與安全設計一併檢視。www.rfc-editor.org datatracker.ietf.org

我的網站應測量什麼？

與單一實驗室分數相比，透過真實使用者體驗驗證效能改善更可靠。Lighthouse 有助於快速找出潛在問題，但無法代表不同網路、裝置、快取狀態與地區中的所有真實使用者。將開發者工具與真實使用者監測搭配使用，更容易區分假設與結果。developer.chrome.com developer.chrome.com

可依以下順序檢視效能：

檢查目前的傳輸狀態。 在 Network 面板中，檢視重要 HTML、CSS、JS 與 JSON 回應的 Content-Encoding、傳輸大小及原始大小。developer.chrome.com
檢查協定。 在 Protocol 欄中確認實際請求使用的是 h3、h2 還是 http/1.1。
區分重要使用者指標。 比較首次與重複造訪、行動裝置與桌面裝置、地區及網路類型的 TTFB、LCP 與互動指標。web.dev web.dev
一次只變更一項。 若同時部署 gzip 啟用、Brotli 支援、圖片替換、JavaScript 分割與 HTTP/3 啟用，很難辨識是哪項變更產生效果。
也記錄副作用。 同時監控伺服器 CPU、錯誤率、快取命中率，以及 HTTP/3 連線失敗或降級率。

例如，若將未壓縮的 JavaScript bundle 改為 gzip 後，傳輸大小下降但 LCP 幾乎不變，下一個瓶頸可能是大型圖片、CSS 或 JavaScript 執行，而非壓縮。相反地，若採用 HTTP/3 後，行動網路使用者的 LCP 長尾表現改善，除了平均值之外，也可辨識出它在高遺失與高延遲環境中的效益。這類結論應從測得的瓶頸開始，而不是從技術名稱開始。web.dev www.rfc-editor.org

總結：將 gzip 與 HTTP/3 視為互補角色，而非排名競賽

gzip 與 HTTP/3 都有助於網站效能，但比較兩者的基礎不同。gzip 可減少文字回應的傳輸位元組；HTTP/3 則可透過基於 QUIC 的多工串流，減少網路遺失對多個請求造成的影響。HTTP/3 的 QPACK 是標頭壓縮，無法取代 gzip 與 Brotli 處理的主體壓縮。www.rfc-editor.org datatracker.ietf.org datatracker.ietf.org

最實務的優先順序，是先在 LCP、TTFB、轉譯阻塞、JavaScript、圖片與快取之中找出實際瓶頸；若缺少文字壓縮，將它補足作為基準；然後在真實使用者條件下驗證 HTTP/3。效能不在於加入一項最新技術，而在於縮短使用者必須等待的最長路徑。web.dev developer.chrome.com