網站速度卡住的時候，多數人第一反應是換快取外掛、壓縮圖片、再裝一個最佳化套件。這些都對，但它們都繞過了一件更底層的事：你的網站到底用哪一版 HTTP 協定在傳資料。同一台主機、同一套 WordPress，光是從 HTTP/1.1 換到 HTTP/2，再啟用 HTTP/3，使用者實際感受到的載入速度就會有明顯差距，尤其是手機用戶。

問題在於，HTTP/2 與 HTTP/3 都不是你在 WordPress 後台裝個外掛就能打開的東西，它由主機端決定。更麻煩的是，很多人「以為」自己啟用了，實際上瀏覽器根本沒走到那條連線。這篇會把三件事講清楚：HTTP/2 與 HTTP/3 各自快在哪、對 WordPress 的速度影響到底有多大、以及最重要的——怎麼用一條指令確認你的站台是真的啟用了，而不是自我感覺良好。

HTTP/2 與 HTTP/3 差在哪，為什麼會影響 WordPress 速度

簡單講，這兩版協定改的是「瀏覽器和伺服器之間怎麼搬資料」，而現代 WordPress 頁面正好最吃這一塊。一個首頁載入動輒要抓幾十到上百個檔案，包含 CSS、JavaScript、字型、圖片、外掛塞進來的各種資源，協定效率差一點，疊起來就是好幾秒的差距。

HTTP/1.1 的老問題是「一條連線一次只能好好處理一個請求」。瀏覽器為了同時抓很多檔案，只好對同一個網域開 6 到 8 條 TCP 連線輪流排隊，每條連線都要重新握手、重新建立 TLS 加密，光是這些前置動作就拖慢了第一個位元組送達的時間。

HTTP/2 解決的核心是「多工」（multiplexing）。它用一條連線就能同時送出多個檔案的資料流，彼此不用互相等待，等於把單一收銀台換成多個同時結帳的通道。它還做了兩件事：用 HPACK 壓縮 HTTP 標頭，把重複的 cookie、user-agent 這類資訊壓成精簡的參照；以及讓瀏覽器能告訴伺服器「先送 CSS 跟首屏內容、廣告慢點送」的優先順序控制。對一個資源破百的 WordPress 頁面來說，這些省下來的往返與位元組會直接反映在載入時間上。

HTTP/3 則是把整個傳輸底層從 TCP 換成 QUIC（跑在 UDP 之上）。它要解的是 HTTP/2 還沒解掉的一個痛點——「隊頭阻塞」（head-of-line blocking）。在 HTTP/2 裡，多個資料流雖然共用一條連線，但底層 TCP 一旦掉了一個封包，整條連線的所有資料流都得停下來等重傳。QUIC 把封包遺失隔離在單一資料流，其餘的照流不誤，這在訊號不穩的行動網路上特別有感。

QUIC 還整合了 TLS 1.3，把建立連線和加密握手合併，減少往返次數；回訪的使用者甚至能透過 0-RTT 幾乎立刻開始傳資料。另外它支援連線遷移，手機從 Wi-Fi 切到行動數據時連線不會中斷重來。

HTTP/2 與 HTTP/3 的核心差異一次看清

HTTP/2 與 HTTP/3 對 WordPress 速度的實際影響有多大

先給結論：從 HTTP/1.1 升到 HTTP/2 的提升通常很明顯，再從 HTTP/2 加上 HTTP/3 的提升則比較有條件，主要看你的訪客是誰、在什麼網路環境連進來。不要期待 HTTP/3 一開就讓所有頁面瞬間飛起來，它的價值在「穩定」多過「絕對速度」。

業界普遍觀察到，在一個請求數量落在 60 到 100 個的頁面上，從 HTTP/1.1 換到 HTTP/2 通常能讓最大內容繪製（LCP）與首位元組時間（TTFB）下降一到三成。這個區間的改善幾乎人人有份，因為 WordPress 頁面的資源數量天生就多，多工帶來的並行下載效益很直接。

HTTP/3 疊上去之後，多數情境再多省下約 5% 到 15%，而且它真正的賣點是把尾端延遲（也就是最慢那 5% 到 1% 的連線）拉穩。換句話說，平均載入時間可能只快一點點，但「偶爾特別慢」的那些次數會減少。對以下這幾種站台，這個差別最值得在意：

• 行動裝置流量高的網站：使用者在移動中切換基地台、訊號時好時壞，QUIC 的封包遺失隔離與連線遷移能避免畫面卡住。
• 訪客分布廣、跨國連線多的站：距離主機遠、延遲高的連線，握手次數的節省會被放大。
• WooCommerce 商店與互動頻繁的站：商品頁、購物流程牽涉大量並行請求與 API 呼叫，並行傳輸越順，互動延遲越低。

要特別講清楚的是，協定升級不會取代快取與內容傳遞網路（CDN）。HTTP/3 把資料搬得更快，但前提是「資料已經準備好可以送」。如果你的 HTML 每次都要回主機端重新由 PHP 跟資料庫產生，那 TTFB 的瓶頸在主機運算，不在傳輸協定。正確的順序是：先把靜態資源跟 HTML 用快取、邊緣快取處理好，再讓 HTTP/2、HTTP/3 把這些已備妥的內容更有效率地送到瀏覽器，兩者是互補不是二選一。

WordPress 怎麼啟用 HTTP/2 與 HTTP/3，要看你的主機類型

最關鍵的觀念先記住：HTTP/2 與 HTTP/3 都不能在 WordPress 內部啟用。你裝不到外掛、改不了哪段 wp-config.php 就能打開它，它由你的網頁伺服器（Apache、Nginx、LiteSpeed）或前面的 CDN 決定。所以「怎麼啟用」這個問題，實際上要先回答「你的主機架構長什麼樣」。

HTTP/2 的門檻其實很低，幾乎只剩一個前提：你的網站要有 SSL 憑證、跑在 HTTPS 上。協定本身規格上不強制加密，但 Chrome、Firefox、Safari 這些主流瀏覽器都只在 HTTPS 連線上啟用 HTTP/2，所以實務上 SSL 等於必要條件。多數採用近年版本伺服器軟體的主機，只要你裝了 SSL，HTTP/2 通常是預設就開的。

HTTP/3 因為要動到傳輸底層，情況分成幾種，依你的主機類型對號入座。

用 Cloudflare 之類的 CDN：在儀表板開一個開關

這是台灣中小型 WordPress 站最常見、也最簡單的路徑。重點觀念是：使用者連到的是 Cloudflare 邊緣節點，而不是你的主機，所以你的主機端不需要支援 QUIC，訪客一樣享受得到 HTTP/3。Cloudflare 邊緣會用 HTTP/3 跟瀏覽器溝通，再用它支援的協定回你的主機。

操作上，先確認該網域的 DNS 記錄是橘色雲朵（代理模式），灰色雲朵只做 DNS 解析，邊緣功能全部不會生效。接著到 SSL/TLS 設定把 TLS 1.3 打開，再到網路（Network）設定把 HTTP/3（with QUIC）切成開啟。回訪加速可以再開 0-RTT。SSL 模式建議設為完整（嚴格）（Full Strict），讓邊緣到主機這段也維持端對端加密。

用 LiteSpeed 或 OpenLiteSpeed 主機：原生支援，在虛擬主機層開

如果你的主機跑的是 LiteSpeed Enterprise 或 OpenLiteSpeed（很多支援 LSCache 的台灣主機商屬於這類），那它原生就支援 HTTP/3，不需要再疊一層 CDN。通常是在虛擬主機（vhost）設定裡把 Enable QUIC 設為 Yes，並確認跑的是較新版本。

這裡有個容易踩的雷：LiteSpeed 的 QUIC 不能跟前面的 Cloudflare 反向代理同時運作。如果你想用 LiteSpeed 自家的 QUIC，得把反向代理模式的 CDN 關掉，否則瀏覽器看到的是 CDN 的協定，不是 LiteSpeed 的。兩者擇一即可，不要疊。

自己管 VPS 或實體主機：要自己配伺服器與防火牆

如果你掌控自己的伺服器（Nginx 或 Apache），就得自己把這條鏈路配起來。大方向是：用近年版本、原生支援 HTTP/3 的伺服器建置，確認 TLS 1.3 與 ALPN 已啟用、ALPN 要把 h3 一起廣播出去，並且——這條最常被忘記——在防火牆與雲端安全群組放行 UDP 的 443 埠。QUIC 跑在 UDP 上，只開 TCP 443 是不夠的，UDP 443 沒放行，HTTP/3 就完全連不上。最後透過 Alt-Svc 標頭讓瀏覽器知道你支援 h3，它才會在下一次連線升級過去。

不管走哪條路，瀏覽器端都是自動協商的。支援 HTTP/3 的瀏覽器（近年版本的 Chrome、Edge、Firefox、Safari）會優先嘗試新協定，連不上就自動退回 HTTP/2 或 HTTP/1.1，舊瀏覽器與企業防火牆後的使用者不會因此打不開你的網站。也因為這個自動退回機制，HTTP/2 即使在 HTTP/3 普及之後仍然是必備的安全網，不能因為開了 HTTP/3 就不管 HTTP/2。

怎麼確認 WordPress 真的啟用了 HTTP/2 或 HTTP/3

開了開關不等於生效。最常見的狀況是：儀表板顯示 HTTP/3 已開啟，但瀏覽器實際連線走的還是 HTTP/2，因為 Alt-Svc 標頭沒正確送出、或 UDP 443 被擋。所以啟用之後一定要驗證，這裡給三個由淺到深的方法。

用瀏覽器開發者工具看 Protocol 欄位

最直覺。用 Chrome 或 Edge 開啟你的網站，按 F12 打開開發者工具，切到「Network（網路）」分頁，重新整理頁面。在請求列表的欄位標題上按右鍵，把「Protocol（協定）」欄位勾選出來。然後看你的主文件那一列：顯示 h2 代表走 HTTP/2，顯示 h3 代表走 HTTP/3。如果只看到 http/1.1，表示前面的設定還沒生效。

要注意瀏覽器對 HTTP/3 通常是「第二次連線才升級」。第一次拜訪可能先走 HTTP/2，瀏覽器透過 Alt-Svc 得知支援 h3 後，下次才改用。看不到 h3 時可以先用 CTRL + SHIFT + R 強制重新整理，或關掉分頁重開再看一次。

用 curl 指令一行確認，最不會騙人

開發者工具方便，但它受快取與連線重用影響。要最乾淨地確認伺服器到底回應什麼協定，用 curl 從命令列直接問。

檢查 HTTP/2，看回應的狀態列開頭是不是 HTTP/2：

curl -I --http2 https://你的網域.com/

檢查 HTTP/3，要 curl 版本本身有編進 HTTP/3 支援：

curl -I --http3 https://你的網域.com/

成功回應就代表伺服器接受了 QUIC 連線並完成 TLS 1.3 握手。想更嚴格地排除退回機制，可以用 --http3-only 強制只走 QUIC、禁止退回，連不上就會直接報錯，藉此確認是真的 h3 在運作，而不是悄悄退回了 HTTP/2。

檢查 Alt-Svc 標頭，看升級機制有沒有對

如果瀏覽器死活不肯升級到 HTTP/3，問題往往出在 Alt-Svc 標頭。這個標頭就是伺服器告訴瀏覽器「我這裡支援 h3，下次走這條」的廣告，沒有它或內容不對，瀏覽器就不會主動嘗試 HTTP/3。檢查方式是抓回應標頭，找有沒有 alt-svc 這一行、裡面有沒有 h3：

curl -sI https://你的網域.com/

回應裡若出現類似 alt-svc: h3=":443" 的內容，代表升級廣告正常。沒看到就回頭檢查伺服器或 CDN 的 HTTP/3 設定。

除了指令，也有現成工具可用。免費的線上 HTTP/3 檢測工具輸入網址就會告訴你 QUIC 與 HTTP/3 是否支援，並附上連線細節；Chrome 與 Firefox 也有顯示協定的擴充套件，在工具列用顏色標示目前連線走的是 HTTP/2 還是 HTTP/3，適合平常隨手確認。

升級協定之後，還要回頭清掉哪些 HTTP/1.1 時代的老作法

啟用 HTTP/2、HTTP/3 只是把地基換新，如果上面還堆著為 HTTP/1.1 設計的最佳化手法，反而會抵銷新協定的好處。這一步最容易被略過，卻是讓升級真正見效的關鍵。

網域分片（domain sharding）要拿掉。過去為了繞過 HTTP/1.1「每個網域連線數有限」的限制，常把資源拆到多個子網域分散下載。在 HTTP/2、HTTP/3 之下，多工本來就讓一條連線同時搬多個檔案，額外的網域反而逼瀏覽器多開連線、多做握手，把多工的好處抵銷掉。

過度把 CSS、JavaScript 內嵌進 HTML 的作法要收斂。HTTP/1.1 時代為了少幾個請求會把樣式、腳本直接寫死在 HTML 裡，但這會讓 HTML 變肥、無法被瀏覽器獨立快取，反而拉高 TTFB。協定升級後，分開的檔案能各自被快取、被並行抓取，效益更好。

HTTP/2 Server Push 現在多半不建議用。它原本想讓伺服器在瀏覽器開口前就主動推送資源，但實務上常推送了瀏覽器其實已經快取的檔案，浪費頻寬又難控制，目前用 preload、prefetch 這類資源提示通常表現更好也更可控。

壓縮也值得順手調整。文字類資源建議啟用 Brotli（保留 Gzip 作為退回），但壓縮等級不要拉到最高，過高的等級會吃掉 CPU、反而拖慢，4 到 6 級通常是兼顧壓縮率與運算成本的合理區間。同時把靜態資源的快取標頭設長一點、HTML 配合內容更新頻率設較短的 TTL 並做好失效，讓快取與新協定一起發力。

換協定不是按一個開關就結束的事。把它想成一條鏈路：主機或 CDN 端打開 HTTP/2 與 HTTP/3、確認 SSL 與 TLS 1.3 到位、UDP 443 放行，接著用 curl 與開發者工具實際驗證瀏覽器真的走在新協定上，最後回頭清掉網域分片、過度內嵌這些舊習慣。前面三步決定使用者連得上新協定，最後一步決定新協定能不能發揮全部實力。先把驗證做確實，再談下一步要不要疊 CDN 或調快取，速度的進步才量得出來、守得住。