[WordPress]如何提升網頁顯示速度

說真的，我掙扎了一段時間要怎麼寫這篇文章
因為一旦要寫出這篇文章的話，勢必也要達成文章所描述的效果

但通常事與願違的是，有時候即使按照以下的一些內容去執行，也不見得能夠達成希望的效果
我現在比較可以確切的說是「同樣的主機，不同的佈景主題也會有極大的差異性」
為什麼會這樣說，我會在後面說明

那麼回到主題，影響網站顯示速度其實算是多方面的，除了下面文章提到的面向外，甚至使用者端的網路環境以及硬體設備等級都有差（講白話點，你如果使用256kbps的網路和使用第一代iPhone來瀏覽上網的話，那根本不用說一定慢到爆）

以下提到是我覺得比較重要的部分（或許還有其他的方式我沒提到，也請前輩不吝指教）

1. 佈景主題（以及編輯器）的選擇 — 付費

其實這裡我有點糾結，這個重要度和下一個主機的影響其實不相上下，但如果在相同的網路環境下，佈景主題（或是編輯器）這個影響的部分會是非常的大，抱歉我手頭上並沒有可以提供跑分的圖片（上面的圖也僅是不同網站，但為同一個主機上）

但我實際上是有接觸到同樣網站內容的設計，只是在不同的狀況下，PageSpeed Insight跑分就差異極大（但我沒辦法貼出該網站的詳細狀況）

1. 使用Avada佈景主題+Elementor
2. 使用Elementor原生的「Hello Elementor」佈景主題

在這種組合下，組合1的Avada+Elementor可說在PageSpeed Insight慘不忍睹，行動裝置不到40分，電腦不到50分…

但組合2用「Hello Elementor」搭配Elementor的狀況下，基本上行動裝置和電腦的PageSpeed Insight可以說是有顯著提升；行動裝置可以到將近60分，而電腦端的跑分接近80分（未嘗試優化的狀況下）

其實我覺得感受最深的就是我在同一台主機（VPS）所架設的不同網站（都我自己的網站）

https://cyrians.com

https://walkwei.com

就如同之前的圖中，可以很明顯看到使用Bricks Builder的網站跑分非常之高（即使是行動裝置亦同），而且就我來看，第二個網站的佈局複雜性可能還比本站還要來的多些（當然本站載入中文字形造成延遲也應該是造成顯示慢的問題之一）

而Avada佈景主題的惡名昭彰（速度慢），我算是之前才正式見識到

Avada我覺得屬於大雜膾，把常見的網頁顯示方式都全部打包進去；但就網路上描述，Avada的網頁撰寫（指HTML的部分）不夠專業太過肥大，造成顯示緩慢

或許在前期真的沒有經驗想法，但如果大略抓到自己網站門面的感覺時，我會建議…快逃啊（使用像是單一Elementor或是Bricks Builder等編輯器）

至於建議的佈景主題（編輯器）有

GeneratePress：WPJohnny推薦的佈景主題，屬於高效能的佈景主題；曾有過終身版，但現在為訂閱制（每年支付），且免費版無網站樣版可參考

Blocksy：本站現在（2025/05/20）正在使用的佈景主題，也同樣為較輕巧的主題，有免費/付費版本，也具有相當的人氣

Astra：本站之前使用的佈景主題，也屬於高效能佈景主題，但最終切換到Blocksy（個人後來偏好Blocksy多些）

Bricks Builder：這個不算是佈景主題（僅是頁面編輯器），比較適合有設計且有良好HTML相關概念的設計師來進行；雖說跟Elementor相較下，Elementor的人氣還是略勝一籌，但是後來居上新秀的它，也在過去的Monster Award的頁面編輯器項目中霸佔前1、2名（2022年後）

2. 主機的影響

主機的影響其實也是相當的大，相信之前有些人應該有經歷過藍色主機之亂…

當然主機的影響包含到

地點 — 付費（因為不管怎樣主機就是一筆固定付費）

如果你的客群在台灣，那勢必主機選擇要在距離台灣比較近的地方，反應才會比較快；例如服務器在新加坡、日本、韓國或者是香港等位置

性能 — 付費（同樣取決於你想要的等級，也是有等級差距費用）

當主機效能較高時，能更快處理請求、產生網頁內容，並將資料迅速傳送給用戶端，這會直接縮短伺服器回應時間（影響如TTFB），如果主機性能不佳，如主機資源不足或負載過高，會導致伺服器處理請求變慢，TTFB 增加，網站顯示速度也會變慢

VPS線路測試一覽.xlsx（470MB，有相當多的測試截圖，建議下載確認）

就以我綜合評估下來（從配備等級、速度、價格），最終選了Hetnzer這間廠商

我自己選擇的方案是CPX 11方案（€4.5/月，約155 NTD），含2VC（2個虛擬CPU）、2G Ram和40G空間、1TB的網路流量

3. 減少網頁讀取內容的大小

一個網頁的內容包含的不外乎：HTML、CSS、JS、圖片、字型，當然還有一些有牽扯到後端資料部份就不算這次主要討論內容就先跳過

而其中一個網頁裡先撇除字型的部分後，體積最大的就是圖片（畢竟一個網頁裡沒有圖片就很無趣）

圖片的體積優化

JPG、PNG的優化 — 免費

圖片的體積優化部份，可以參考以前的文章

大略提之前的文章針對原本要上傳的圖片先做處理，可以把尺寸（解析度）、JPG或是PNG格式做優化，甚至轉換成webp或是avif格式圖片

如果屬於照片類型網站（攝影師、婚攝之類），對於影像非常要求的，也務必做優化讓體積降下來（畢竟體積越大讀取時間會越重）

SVG的優化 — 免費

有時候網站會採用SVG的圖片，最主要還是因為相較於同樣解析度的圖片（特別是JPG、PNG的檔案），SVG屬於向量圖不管放大或縮小都是同樣體積，唯獨就是僅適合比較簡單線條（如沒有太多的圖片漸層）

然後如果SVG檔案比較偏大的話（不是那種PNG隨便轉SVG的服務，是要真正的放大也不會失真的才是真的SVG），例如超過50 KB時，可以再透過

https://optimize.svgomg.net

這個服務，基本上還可以減少體積（就我使用的感覺，如果是正常的SVG透過這個服務，基本上都可以再減少30％左右的體積）

字型的傳遞優化方式（包含自管字體搭配CDN） — 免費/付費

如果是採用中文字體且非Google字體的話，這個部份同樣要請參考以前的文章

但必須要講的是，只要牽扯到自訂的中文字體想要套用在自己網站上，一定多少得犧牲顯示效能（而且瓶頸還會卡在用戶端顯示夠不夠力快速渲染整個網頁）

之所以會有免費/付費的部分是因為CDN這部份，會有免費（Cloudflare）和付費（例如BunnyCDN）的差別；免費的CDN是Cloudflare要綁A位置後還要是橘雲狀態，但有些特殊狀況會不得已無法使用狀況下，這時候就可以考慮付費的CDN

減少不必要的外掛數量/盡量使用輕量化的外掛 — 免費/付費

這部份我很難說哪些是不必要的外掛，但如果說我個人推薦的話，那就是Admin and Site Enhancements (ASE)這個外掛吧

一個外掛打數個外掛

關於外掛的輕巧與否，可參考Compare Plugins(WP Hive)來確認外掛的資源消耗狀況

啟用GZip、Brotli或是Zstd壓縮功能

Brotli 和 Gzip 主要針對 HTML、CSS、JS、JSON、SVG 等文字型檔案壓縮，一般來講，如果說使用Cloudflare的話，預設狀況下就已經啟用這些壓縮協定

Zstd壓縮雖然去年Cloudflare有提出，但我依據去「壓縮規則」設定，似乎也還不能設定（或許我該去開個Ticket回報）

Zstd壓縮和Brotli壓縮比較下來，壓縮稍微差一點，但壓縮、解壓縮時間也比Brotli快，這也代表到用戶端可以快點顯示

目前Cloudflare啟用壓縮時對應的格式有

text/html
text/richtext
text/plain
text/css
text/x-script
text/x-component
text/x-java-source
text/x-markdown
application/javascript
application/x-javascript
text/javascript
text/js
image/x-icon
image/vnd.microsoft.icon
application/x-perl
application/x-httpd-cgi
text/xml
application/xml
application/rss+xml
application/vnd.api+json
application/x-protobuf
application/json
multipart/bag
multipart/mixed
application/xhtml+xml
font/ttf
font/otf
font/x-woff
image/svg+xml
application/vnd.ms-fontobject
application/ttf
application/x-ttf
application/otf
application/x-otf
application/truetype
application/opentype
application/x-opentype
application/font-woff
application/eot
application/font
application/font-sfnt
application/wasm
application/javascript-binast
application/manifest+json
application/ld+json
application/graphql+json
application/geo+json

可以在

https://toolsaday.com/seo/check-gzip-compression

這裡測試網站是否支援Brotli/Gzip

4. 活用快取減輕源伺服器端的負擔

使用CDN — 免費/付費

使用CDN，可以減輕對源伺服器的負擔，而且CDN是把源伺服器上的資料在世界各地都有個相同內容，然後在靠近使用者附近的伺服器推送資料給使用者

一般來講，免費的就如Cloudflare，而付費的我個人推薦BunnyCDN（最低1美金/月，亞太地區流量大約33 GB用量）

使用伺服器端等級快取

使用伺服器等級快取如ESI（Edge Side Includes，邊緣側包含）、Varnish（NginX專用），這個是僅次於CDN的快取等級。但是LiteSpeed Server才有支援ESI功能，OpenLiteSpeed Server（OLS，免費版的LiteSpeed Server）並沒有這功能

使用快取外掛

使用快取外掛的主要目的是將網站頁面或資料預先生成並儲存（通常是靜態 HTML 檔案），當訪問者再次請求同一頁面時，直接提供這些已生成的快取內容，而不必每次都從資料庫重新查詢、組合資料、執行 PHP 程式碼。這樣能大幅減少伺服器負擔、降低資料庫查詢次數，提升網站回應速度與效能

物件快取（Object Cache）的外掛安裝必要性？

主要針對的是動態快取，也就是例如購物網站的話，這會有幫助，除此之外就還好

快取外掛的推薦 — 免費/付費

個人推薦的話，基本上就以下幾個

WP Rocket – 目前最有名的快取，詳細就不多做介紹，為訂閱制

FlyingPress – 同樣也和WP Rocket不相上下（甚至以上的表現），價格比WP Rocket更有競爭力，為訂閱制

SwiftPerformance – 相較前面兩個，就比較沒有太大出名，但是有無限網站且有LTD，個人覺得其實也有不少可以調整的地方，有訂閱制也有買斷制

LiteSpeed Cache – 前面三個都是付費外掛，但這個是免費的，而且可以結合Quic.Cloud他們自己的CDN，但能夠發揮最大效能的，還是必須是LiteSpeed Server（OLS就可惜欠缺了ESI功能）才能發揮最大效率

相關可參考下面這篇文章

所以就以快取效率來講：瀏覽器快取（這個其實才是最快的，但這對本篇並沒有太大幫助就是）>CDN>伺服器端快取>快取外掛

5. 移除不必要的CSS，將JS Defer（如Google相關第三方等的解析服務）延後執行 — 免費/付費

其實這部份算是很困難的部分，雖然基本上靠上面的外掛號稱也可以達成，但比較詳細的設定可以靠以下幾個外掛達成

Perfmatters – 大概是目前市面上最有名的

Asset CleanUp: Page Speed Booster – 有免費版本，亦有訂閱制的付費版本

WP-Shifty – 個人目前在使用的，有終身版本

這類外掛最主要就是測試將在該頁面使用不到的CSS和JS一一排除後並試錯後降低主機執行負荷

6. 更新PHP到最新版本

這是比較容易被忽略的部分，但事實上也是有幫助的

7. 使用Preload和Preconnect/Prefetch來加快讀取的圖片

Preload主要針對該頁面的讀取優先度，而Preconnect/Prefetch則是對於其他頁面（指目前頁面的其他頁面連結）的讀取優先度

這裡比較常會忽略的部分就是首頁的Hero Banner（就是最大區塊的圖片）

FB社團WP Speed Matters有人提到不要使用CSS當背景圖

講簡單點就是Section的部分你跳到Style的地方然後加入背景圖（這應該不少人都這樣做），這樣就是透過CSS來載入背景圖

這樣的缺點就是無法特定圖片來做讀取的優先度，而且是先執行CSS後才執行圖片的部分，所以就會有些Delay

※CSS的功用是做控制網頁的視覺表現與布局，並不像是做為Img這樣的單一功用

所以像是以下影片用Elementor來解決這問題，但Bricks Builder也類似同樣概念（使用Absolute和Z-index搭配）

8. 其他細項

CSS硬體加速語法 — 免費

以下的語法是讓一些過渡動畫平滑處理（而不是瞬間展示），比較屬於顯示效果優化

/* 讓屬性變化時有平滑過渡，提升視覺體驗(GPU加速) */
.smooth-transition {
  will-change: transform, opacity;
  transform: translateZ(0);
  opacity: 1;
  transition: transform 0.3s ease-out, opacity 0.3s ease-out;
}

.smooth-transition:hover {
  transform: scale(1.1);
  opacity: 0.8;
}

移除不必要的Autoload資料欄位（移除前務必備份！） — 免費/付費

WordPress 會將網站設定、外掛與主題設定等資料儲存在 wp_options 資料表中，我們可以透過phpMyAdmin進入

該表的 autoload 欄位用來決定某個選項是否會在每次頁面請求時自動載入到伺服器端執行 PHP 的記憶體中

當 autoload 設為 yes 時，這些選項會被一次性載入到記憶體，無論該次請求是否實際需要這些資料。這樣設計的目的是讓常用設定能夠被快速存取，減少資料庫查詢次數；但若自動載入的資料過多，則會增加伺服器記憶體消耗，進而影響網站效能

除了透過phpMyAdmin外，也可以透過外掛的Advanced DB Cleaner（需付費）達成

不管哪個方式，都務必要先備份再處理

尤其是有些東西不小心刪除後會造成整個WordPress系統崩潰，所以務必先備份後再處理

9. 究極處理方式 – Headless WordPress — 免費/付費

傳統的 WordPress 架構是前端與後端緊密結合，並且核心依賴 PHP。由於 PHP 在大多數情況下是單線程運作，每個請求都需要一個 PHP worker 處理，這限制了伺服器同時處理多個請求的能力，可能導致網站回應速度較慢

而採用 Headless WordPress 後，前端與後端分離，WordPress 僅負責內容管理與 API 提供，前端則可用現代 JavaScript 框架（如 React、Vue.js、Angular 等）打造。這些框架能利用非同步資料載入、元件化設計與 Web Workers 等技術，讓前端渲染更快、更流暢，並減少伺服器負擔，進而提升整體網站效能

採用 Headless WordPress 後，內容編輯者雖然仍可在 WordPress 後台進行內容管理，但前端顯示介面需完全由開發者以現代框架自行打造，無法像傳統 WordPress 那樣直接透過主題或可視化編輯器即時預覽。若要實現所見即所得或即時預覽功能，則需額外開發前端專屬的編輯介面，開發難度與成本相對提高。可以說，除了原本的內容資料可以沿用外，前端外觀介面幾乎等同於從零開始設計與開發算是最大的問題

但採用了這種方式的話，速度和安全方面可以算是有保證性的提升就是；如果說你有相當毅力，不妨可以自己嘗試，但如果真的想要追求效能，不妨去付錢來打造這種高效能的網站（但不便宜就是…）

以上為[WordPress]如何提升網頁顯示速度，希望能夠對你有所幫助

參考資料

11 Ways to Speed Up WordPress Website in 2024

字體優化（英文字型部份，但中文的部分有一部份可流用參考）

使用 Headless WordPress 釋放您網站的潛力

幾個提升網站速度的小技巧

1. PHP版本更新到8以上
2. 安裝優化以及快取外掛（是否要優化CSS和JS要依據狀況調整，有時候不調整反而比較好，但最基本的Minify處理，基本上會影響的可能性較小，但還是會有影響的時候；最終都是要花時間一一確認版面以及效果是否正常）
3. 圖片的優化（減少體積）