WordPress網站速度優化終極指南

多年來，我們釋出了許多WordPress速度優化教程，其中包含優化和加速WordPress的方法。但有時試圖在一個地方找到您需要的一切可能會令人困惑。因此，今天我們將與您分享我們所知道的關於WordPress渦輪增壓的所有知識，超過15年的經驗和吸取的慘痛教訓，所有這些都在一本終極指南中。無論您是剛開始使用WordPress還是經驗豐富的開發人員，我們保證您會在本指南中找到有用的東西！

超過43.0%的網路現在由WordPress提供支援。雖然這很棒，但這也意味著有成千上萬種不同的主題、外掛和技術必須共存。對於日常的WordPress使用者來說，當他們的網站開始出現瓶頸並且他們不知道為什麼甚至不知道從哪裡開始故障排除時，這很快就會變成一場噩夢。

在我們之前的頁面速度指南中，我們討論了許多效能的基礎知識以及它如何對您的業務成功產生巨大影響。但今天我們將深入探討您現在可以採取的適用步驟，以檢視您自己的WordPress網站的改進。我們還將分享一些對我們來說非常寶貴的資源。

1. 執行速度測試
2. 優化Core Web Vitals
3. WordPress網站型別：靜態或動態
4. 選擇高效能WordPress主機
5. 選擇離訪問者最近的伺服器
6. 高階DNS優於免費DNS
7. 您的WordPress主題很重要
8. WordPress外掛的祕密
9. 最佳WordPress設定
10. 為什麼快取如此重要
11. 影象優化是必須的
12. 微調您的資料庫
13. 使用內容交付網路 (CDN)
14. 需要時解除安裝媒體和電子郵件
15. 如何找到瓶頸和緩慢的外掛
16. 後端優化建議
17. 前端優化和外部服務的技巧
18. 始終以移動為先進行優化

執行速度測試

當您發現自己的網站出現滯後現象時，首先要做的就是進行速度測試，測量網站的速度和效能。你可以使用 GTmetrix、Pingdom 和 Google 的 Page Speed Insights 等工具。

為了演示這一過程，我們將引導您使用 GTmetrix 執行掃描。將網站 URL 複製並貼上到文字欄位 (1)，然後點選 test your site (2)。

掃描需要幾分鐘才能完成。一旦完成，你就會明白為什麼你的網站效能不佳。GTmetrix 可測量效能、結構、最大內容繪製、總阻塞時間和累積佈局偏移：

結果分解

通過下面的截圖，我們可以看到測試網站存在一些問題。在 “performance” 選項卡中，我們可以看到網站的最大內容繪製得分高於建議值，頁面索引速度為 5.1。這意味著載入我們的頁面需要 5.1 秒，其中最大的元素需要 7.8 秒才能完全載入。一般來說，網站的載入時間應少於 3 秒，這樣才能留住訪客。

我們可以在 structure 選項卡上深入瞭解導致網站載入緩慢的原因。如您所見，我們有幾張圖片過大，導致頁面載入緩慢。此外，由於 javascript 檔案佔用了資源，還存在一些大的網路有效負載問題。

您所看到的結果將因您網站的需求而異，但正如您所看到的，GTmetrix 將為您提供所有必要的資訊，以便您採取措施加快 WordPress 的執行速度。

優化Core Web Vitals

如前所述，您應該熟悉 Google 的核心網路指標以及每個指標的含義。這些指標對您的網站在搜尋結果中取得成功至關重要，因此必須時刻關注這些指標。為了幫助您瞭解每項指標的作用，以下是每項指標的簡單定義：

• 最大內容繪製 (LCP)： 載入頁面上最大圖片或文字所需的時間。
• 首次輸入延遲 (FID)： 測量從使用者第一次點選到瀏覽器開始處理響應的時間。
• 累積佈局偏移 (CLS)： 測量頁面上意外的佈局偏移。當可見元素從一幀到下一幀的位置發生變化時（佈局偏移）。
• 首次內容繪製 (FCP)： 測量第一個元素（文字、影象、視訊等）載入後載入頁面所需的時間。
• 互動到下一步繪製 (INP)： 評估頁面對使用者互動（點選、輕觸等）的整體響應。
• 首位元組載入時間（TTFB）： 計算從請求資源到載入第一個位元組資訊所需的時間。

推薦閱讀：如何優化網站以符合谷歌的Core Web Vitals標準

WordPress網站型別：靜態或動態

在我們深入研究WordPress速度優化之前，首先要了解並非所有WordPress站點都相同，這一點很重要。這就是許多使用者遇到問題的原因，因為您無法以相同的方式解決所有問題。我們總是給WordPress網站一個分類：靜態或動態。因此，讓我們首先探討這兩種型別的網站之間的差異。

主要是靜態站點

靜態通常包括部落格、小型企業網站、低容量新聞網站、個人、攝影網站等網站。靜態是指這些WordPress網站上的資料不經常更改 （可能每天更改幾次）。甚至我們閃電博網站的大部分內容也會被視為靜態網站。

這變得非常重要，因為可以以閃電般的速度直接從伺服器上的快取中處理許多請求！別擔心；我們將在下面深入探討快取的主題。這意味著他們將有更少的資料庫呼叫，並且不需要那麼多資源來實現谷歌效能。

高度動態的站點

另一方面，我們擁有高度動態的網站。其中包括電子商務（WooCommerce或Easy Digital Downloads）、社羣、會員、論壇（bbPress或BuddyPress）和學習管理系統 (LMS) 等網站。動態，我們的意思是這些WordPress站點上的資料經常變化 （伺服器事務每隔幾分鐘甚至每秒發生一次）。這意味著並非所有對伺服器的請求都可以直接從快取中得到服務，並且需要額外的伺服器資源和資料庫查詢。

這些站點通常也有大量的併發訪問者和會話。在大部分是靜態的資訊或企業WordPress網站上，訪問者可能會停留5或10分鐘，直到找到他們需要的東西（這是一個很大的數字，通常跳出率要高得多）。在動態網站上，情況正好相反。訪問者通常來到該網站是為了與某事或某人互動。如果他們正在學習線上課程，那麼他們待上幾個小時並不罕見。

你可以看到這是怎麼回事。連線到您的WordPress主機的併發訪問者增加得很快。更糟糕的是，除了“無法快取的內容”問題之外，還有大量併發訪問者。

選擇高效能WordPress主機

WordPress主機是一家儲存您網站所有資料的公司。您註冊了一個計劃，您的所有影象、內容、視訊等都位於位於主機資料中心的伺服器上。WordPress主機為您提供了一種訪問資料、管理資料並將其路由給訪問者的簡單方法。很簡單吧？嗯，不完全是。

您會在網路上遇到三種非常不同型別的 WordPress 主機。讓我們深入探討每種方法的優缺點。從一開始就選擇正確的方法很重要，否則，您只會讓自己頭疼並浪費時間。

1. 共享WordPress主機

第一種也是最受歡迎的WordPress託管型別是我們所說的“共享託管”。其中包括業內最大的主機，例如Bluehost和HostGator等EIG公司，以及Siteground、GoDaddy、Media Temple、OVH、GreenGeeks和InMotion Hosting等提供商。他們通常使用cPanel，普通客戶通常每月支付3至25美元。

任何使用此類託管的人都會在某個時候體驗緩慢，這只是時間問題。為什麼？因為共享主機往往會伺服器人滿為患，這反過來又會影響您站點的效能。站點暫停或頻繁出現 500 錯誤是您經常遇到的事情，因為它們必須限制一切並整合資源才能生存。或者更糟糕的是，網站停機時間。即使您不知道，您的WordPress站點很可能與200多個其他人位於同一臺伺服器上。其他網站出現的任何問題都可能滲透到您的網站。

WordPress託管共享主機

無論您如何計算，扣除費用後，每月3美元都不會為託管公司帶來任何收入。尤其是當您將支援歸因於此時。只是一個小的共享主機訂單，他們必然處於虧損狀態。他們賺大錢的方式是追加銷售和隱藏費用。這些追加銷售包括遷移、域註冊、SSL證書等。另一種常見的策略是提供巨大的註冊折扣。但是，一旦續訂到來，您就會得到真正的賬單。

這些主機中的大多數都提供他們所謂的“無限資源”計劃。你可能都看到了這一點。好吧，現實世界中沒有無限資源這樣的東西。主機在幕後所做的是限制客戶端消耗大量資源。反過來，這最終會導致那些憤怒的客戶離開，為更多不使用大量資源的客戶騰出空間。最後，您將陷入一個惡性迴圈，即託管公司推出廉價計劃並註冊他們希望不會使用大量資源並會購買追加銷售的客戶。

由於站點數量與支援代表相比，共享主機的客戶服務和支援幾乎總是低於標準。共享主機必須將自己分散得很細才能盈利，這通常會給客戶帶來不愉快的體驗。

2. VPS主機

第二種型別是VPS主機，或“在虛擬專用伺服器上自己動手”。這群人通常由引導初創公司和具有更多開發、伺服器管理和WordPress經驗的使用者組成。他們是DIY人群。這些人通常仍在努力省錢，但他們通常也關心績效並意識到績效對他們業務成功的重要性。Commons設定可能包括使用第三方VPS提供商，例如Digital Ocean、Linode或Vultr；以及像ServerPilot這樣的工具來更輕鬆地管理它。

DigitalOcean的小型VPS起價為每月5美元，ServerPilot的流行計劃起價為每月10美元。因此，根據您的設定，您可能會看到每月5到15美元或更多的費用。DIY方法可以降低成本，但這也意味著如果出現問題，您需要負責並優化伺服器的效能。

DIY方法可能很棒，但如果您不小心，它也會適得其反。如果您不精通技術或只是因為您想修補，請不要走這條路！你的時間很值錢，你應該把它花在發展你的業務上。

3. WordPress託管主機

第三種型別專業WordPress託管主機。這些型別的主機為您處理所有與後端伺服器相關的任務，並在您需要時提供支援。它們通常經過微調以與WordPress配合使用，並且通常包括一鍵暫存環境和自動備份等功能。由於他們每天專注於一個平臺，因此他們的支援團隊在瞭解他們繞過CMS的方式時將更加了解。

託管WordPress託管的計劃通常從每月25美元到150美元不等，甚至更多，具體取決於您網站的大小和需求。jQuery、Intuit、Plesk、Dyn、Nginx甚至白宮等大公司都在使用WordPress來託管他們的網站。您可能熟悉或目前正在使用的一些流行的託管WordPress主機包括WP Engine、Flywheel、Pressable、Media Temple、Pressidium和Pagely。

PHP 7或更高版本以獲得最佳效能

PHP是一種開源的伺服器端指令碼和程式語言，主要用於Web開發。大部分核心WordPress軟體都是用PHP編寫的，以及您的外掛和主題，這使得PHP成為WordPress社羣非常重要的語言。您應該確保您的WordPress主機至少提供PHP 7或更高版本。

您的主機將在您的伺服器上為您提供不同版本的PHP，較新的PHP 7.3提供了巨大的效能改進。

事實上，在我們最近的PHP基準測試中，如果將PHP 7.3與PHP 5.6進行比較，它每秒可以處理3倍的請求（事務）！PHP 7.3也比PHP 7.2平均快9%。這也會影響您的WordPress管理儀表板響應能力。

WordPress 5.0 PHP基準測試

並警惕任何提供HHVM作為PHP替代品的WordPress主機。HHVM不再是WordPress託管的合適解決方案。

選擇使用Nginx的主機

在幕後，每個WordPress主機都使用網路伺服器來支援您的WordPress網站。最常見的選擇是Nginx和Apache。

我們強烈建議使用使用Nginx的主機，因為它的根源在於規模下的效能優化。Nginx在基準測試中的表現往往優於其他流行的Web伺服器，尤其是在靜態內容或高併發請求的情況下。

一些使用Nginx的知名公司包括 Autodesk、Atlassian、Intuit、T-Mobile、GitLab、DuckDuckGo、Microsoft、IBM、Google、Adobe、Salesforce、VMWare、Xerox、LinkedIn、Cisco、Facebook、Target、Citrix Systems、Twitter、Apple 、英特爾等等。（來源）

據W3Techs稱，Apache為所有網站的44.0%提供支援，使其成為使用最廣泛的選項。但是，如果您檢視高流量網站中最受歡迎的Web伺服器（前10,000個），Nginx為其中的41.9%提供支援，而Apache僅提供18.1%的支援。現有的一些資源最密集的網站都在使用它，包括Netflix、NASA，甚至WordPress.com。

在我們的Web伺服器對比文章閱讀更多：Nginx與Apache。

您主機的網路很重要

在選擇WordPress主機時，您甚至可能不會考慮詢問或研究他們使用的網路，但您應該這樣做。網路會對您網站的效能甚至WordPress儀表盤的快速性產生巨大影響。許多主機將把這排除在他們的營銷之外，因為他們會選擇最便宜的網路來降低成本。

以下是您應該問的幾個問題：

• 您通過哪些網路傳輸資料？ 其中大部分是通過公共ISP網路還是私有基礎設施（例如Google或Microsoft）？這些大型提供商擁有專為低延遲和速度而構建和優化的網路。他們甚至在海底擁有自己的網際網路電纜！
• 您使用的網路是否冗餘？如果電纜被意外切斷會怎樣？這種情況發生的頻率比你想象的要高。

早在2017年，谷歌就宣佈了其標準層網路，這是一種速度較慢但成本較低的網路。

據谷歌稱，高階網路通過減少公共網際網路上的旅行時間來提高網路效能；資料包進入（和離開）谷歌的網路儘可能靠近使用者，然後在到達虛擬機器之前在谷歌的主幹上傳播。標準層通過公共交通 (ISP) 網路而非Google網路將GCP的出站流量傳送到網際網路。

谷歌雲平臺高階網路（圖片來源：谷歌）

換一種可能更容易理解的方式：

• 高階資料包在Google的網路上花費更多的時間，更少的反彈，因此效能更好（但成本更高）。
• 標準層資料包在Google網路上花費的時間更少，而在公共網路上花更多的時間玩燙手山芋，因此效能更差（但成本更低）。

這有多大影響？好吧，對於跨大陸傳輸的資料，高階層網路平均比標準層網路快41%。對於傳輸到附近地區（同一大陸）的資料，高階層的速度大約快8%。雖然網路只佔頁面總載入時間的一小部分，但每一毫秒都會加起來！

冗餘也是關鍵，這就是為什麼Google在Google網路上的任意兩個位置之間使用至少三個獨立路徑（N+2冗餘）的原因，以幫助確保即使在發生中斷的情況下，流量也能在兩個位置之間繼續流動。

正如您現在可能知道的那樣，在網路方面，幕後正在發生很多事情。確保您的WordPress主機使用的是信譽良好的主機，並且不會選擇較低的級別來降低成本。

HTTP/2是必備的

HTTP/2是2015年釋出的一種網路協議，旨在加快網站的交付速度。由於瀏覽器支援，它需要HTTPS (SSL)。如果您的WordPress主機不支援HTTP/2，您應該開始尋找新的提供商。隨著整個網路遷移到HTTPS，這不再只是一個很好的功能；這是必需品。

HTTP/2的效能提升是由於多種原因，例如支援更好的多路複用、並行性、使用Huffman編碼的HPACK壓縮、ALPN擴充套件和伺服器推送。在通過HTTPS執行時，曾經有相當多的TLS開銷，但現在由於HTTP/2和TLS 1.3少了很多。

HTTP/2的另一大優勢是，對於大多數WordPress站點，您不再需要擔心連線（組合檔案）或域分片。這些現在是過時的優化。

選擇離訪問者最近的伺服器

託管WordPress網站時，您應該做的第一件事就是確定您的大多數訪問者或客戶來自哪裡。為什麼這很重要？因為您託管網站的位置在確定您的整體網路延遲和TTFB方面起著重要的作用。它還會影響您的SFTP速度和WordPress管理儀表盤響應能力。

網路延遲：這是指通過網路傳輸資料所涉及的時間和/或延遲。換句話說，一個資料包從一個點到另一個點需要多長時間。如今，這通常以毫秒為單位。但是，這可能是幾秒鐘，具體取決於網路。越接近零越好。

TTFB：這代表第一個位元組的時間。簡而言之，這是衡量瀏覽器在從伺服器接收第一個位元組資料之前必須等待的時間。獲取該資料所需的時間越長，顯示您的頁面所需的時間就越長。同樣，越接近零越好。

檢視我們關於TTFB的深入文章。

我們不會在這篇文章中詳細介紹所有技術細節，您只需要知道您希望網路延遲和TTFB儘可能低。實現此目的的最簡單方法之一是選擇離訪問者最近的伺服器。您可以按照以下提示確定最佳位置。

Tip 1 – 在Google Analytics中檢查訪問者的地理位置

您可以做的第一件事就是在Google Analytics（或者其他統計工具）中檢視訪問者的地理位置。您可以在“Audience → Geo → Location”下找到它。

在下面的這個示例中，您可以看到超過90%的流量來自美國。因此，在大多數情況下，您希望將WordPress網站放在美國的伺服器上。您還可以將資料進一步過濾到城市。如果您是本地公司，這一點尤其重要。但通常我們會推薦像美國愛荷華州這樣的中心位置。

谷歌分析地理定位

Tip 2 – 檢查電子商務資料

如果您經營電子商務商店，請確保還檢查您的客戶來自哪裡。這當然是您產生收入的方式，因此這些是您最重要的訪問者。這應該與您上面的流量一致；然而，這並非總是如此。如果您在Google Analytics中有電子商務資料設定或目標，您可以輕鬆地將該資訊疊加在地理位置資料之上，以做出更明智的決定。或者檢查儲存在電子商務平臺資料庫中的位置資訊。

Tip 3 – 進行快速延遲測試

有很多方便的免費工具可以為不同的雲提供商測量您當前位置的延遲。這可以幫助您快速評估哪個區域可能是您站點的最佳選擇。

• GCP Ping（測量到Google Cloud Platform區域的延遲）
• CloudPing.info（測量到Amazon Web Services區域的延遲）
• Azure延遲測試（測量到Azure區域的延遲）

在下面的這個例子中，我們可以看到美國俄勒岡州 (us-west1) 是我們所在位置最快的。但是，如果您為整個美國的客戶提供服務，最好選擇美國愛荷華州 (us-central1) 以確保來自西海岸和東海岸的訪客的延遲低。

測量Google Cloud Platform延遲

減少延遲和TTFB的其他方法

除了選擇一個靠近的伺服器位置之外，這裡還有其他一些減少延遲的方法。

• 在您的WordPress網站上實施快取。在我們的測試中，快取使我們的TTFB減少了90%！
• 利用內容交付網路 (CDN) 為來自全球POP的快取資產提供服務。這有助於消除可能不在您的主機伺服器附近的訪問者的網路延遲。
• 藉助並行化，利用HTTP/2協議最大限度地減少往返次數。
• 減少外部HTTP請求的數量。每個都可以根據其伺服器的位置增加自己的延遲。
• DNS在TTFB中發揮作用，因此您應該使用具有快速查詢時間的優質DNS提供商。
• 在頁面載入時利用預取和預渲染在後臺執行任務。

別擔心；我們將在這篇文章的下面進一步介紹上面提到的所有建議。

SFTP速度和WordPress管理儀表盤

您的訪客和客戶應該始終是您的首要任務。但許多人沒有談論的另一個方面的績效是其中一些決定如何影響您的日常工作。您選擇的資料中心位置會影響您的SFTP下載和上傳速度（使用FTP客戶端傳輸檔案）的速度，以及您的WordPress管理儀表盤的響應能力。

因此，雖然您想確保並選擇最適合訪問者的位置，但也要記住它會影響站點管理。當您的站點託管在離您更近的資料中心時，諸如將檔案上傳到 WordPress 媒體庫之類的任務會更快。

高階DNS優於免費 DNS

DNS是域名系統的縮寫，是網路環境中最常見但最容易被誤解的元件之一。簡而言之，DNS通過將域名與實際的Web伺服器連線來幫助引導Internet上的流量。從本質上講，它需要一個人性化的請求——一個像wbolt.com這樣的域名——並將它轉換成一個對計算機友好的伺服器IP地址——比如216.58.217.206。

DNS的工作原理

您可以找到免費DNS和高階DNS，比如DNSpod。

除主機託管外，還要選擇信譽良好的域名註冊商，如 Namecheap，他們提供高階域名系統 (DNS)。高階 DNS 是 DNS 提供商為提高網站域名解析過程的效能、安全性和可靠性而提供的付費服務。基本上，DNS 將人類可讀的域名（如 wbolt.com）轉換為 IP 地址，計算機使用 IP 地址來定位網際網路上的伺服器。

與免費 DNS 服務相比，高階 DNS 具有一些優勢，如更快的效能、更強的安全性、更好的可靠性、DDoS 保護和更多的自定義選項。高階 DNS 提供商通常擁有更廣泛的伺服器網路，這些伺服器戰略性地分佈在世界各地。這有助於縮短使用者請求得到解決的時間，從而加快載入速度。

選擇優質DNS的一大原因是速度和可靠性。查詢DNS記錄和引導流量需要時間，即使只是幾毫秒的時間。

通常，您從域名註冊商處獲得的免費DNS相對較慢，而高階DNS通常提供更好的效能。例如，在我們的測試中，我們發現免費的NameCheap DNS比Amazon Route 53高階DNS慢33%。此外，高階DNS可以提供更好的安全性和可用性，尤其是當您受到DDoS攻擊時。

您可以使用SolveDNS速度測試等工具  來檢查您的DNS查詢時間。DNSPerf還提供了所有頂級DNS提供商的出色效能資料。

為了在您的域註冊商提供的免費DNS和高階DNS之間取得良好的中間立場，Cloudflare DNS是一項免費服務，它仍然提供高階DNS的許多好處。而且它們在全球範圍內的平均響應時間都在20毫秒以下（如下所示）。

Cloudflare免費DNS速度測試

但是，Cloudflare的一個警告是，它的停機時間也比許多其他提供商更長。如果您主要為美國的訪問者提供服務，那麼DNS Made Easy是您可能想要檢視的另一家優質DNS提供商。在過去十年中，他們以提供一些最佳DNS正常執行時間而聞名。

在過去30天內，DNSPerf顯示這些提供商的以下正常執行時間：

• DNS Made Easy：99.99%，相當於每月400萬23.0秒的停機時間。
• Amazon Route 53：99.88%，相當於每月5200萬35.7秒的停機時間。
• Cloudflare：99.85%，相當於每月1h5m44.6s停機時間。

停機時間對DNS提供商來說有那麼重要嗎？答案是肯定的，也不是。DNS通常使用DNS記錄上的生存時間值 (TTL) 與ISP一起快取。因此，如果DNS提供商宕機10分鐘，您很可能不會注意到任何事情。但是，如果提供商持續出現較長時間和頻繁的中斷，或者您的ISP和DNS記錄都使用非常低的TTL值，那麼停機時間確實很重要。

您的WordPress主題很重要

每個人都喜歡一個全新的WordPress主題，但在你出去之前要小心，抓住一個具有所有新的閃亮功能的主題。關於效能，您在主題中看到的每個元素都會對您網站的整體速度產生一些影響。不幸的是，有成千上萬的主題在野外，有好的也有壞的。

那麼你應該如何知道選擇哪一個呢？我們建議使用以下兩個選項之一：

• 一個快速輕量級的WordPress主題，僅包含您需要的功能，僅此而已。
• 功能更豐富的WordPress主題，但您可以禁用未使用的功能。

諸如Google字型、Font Awesome圖示、滑塊、畫廊、視訊和視差指令碼等。如果您不使用它們，這些只是您應該能夠關閉的眾多功能中的一小部分。您不想在事後嘗試手動調整這些。我們不會向您展示 50 種不同的剝離方法。相反，您應該開始或切換到從一開始就輕量級或為您提供這些選項的WordPress主題。

以下是我們推薦的幾個WordPress主題，您不會出錯！相信我們，你以後會感謝我們的。

下面提到的每個主題都與WooCommerce和Easy Digital Downloads、WPML、BuddyPress和bbPress完全相容。我們使用以下配置對每個主題執行一些速度測試：

• 執行WordPress 4.9.8
• PHP 7.3和SSL (HTTPS)
• CDN
• Imagify用於自動壓縮影象。

GeneratePress

GeneratePress是一個快速、輕量級（壓縮後小於1MB）、移動響應的WordPress主題，在構建時考慮了速度、搜尋引擎優化和可用性。由加拿大開發商Tom Usborne建造。它正在積極更新並得到很好的支援。

有免費和高階版本可用。如果您檢視WordPress主題庫，免費版本目前有超過200,000次活躍安裝、2+百萬次下載。

GeneratePress

GeneratePress的一大優點是所有選項都使用本機WordPress定製器，這意味著您可以在按下發布按鈕之前立即看到所做的每項更改。這也意味著您不必學習新的主題控制面板。

它有多快？我們重新安裝了GeneratePress，在Pingdom中進行了五次速度測試，並取了平均值。總載入時間為305毫秒，總頁面大小僅為16.8KB。進行基線測試以瞭解主題在原始效能方面的能力總是好的。

GeneratePress全新安裝速度測試

然後，我們使用GeneratePress站點庫中的一個預構建主題執行了另一組測試。這包含影象、背景、新部分等。 GeneratePress的一個優勢是它有很多不需要頁面構建器外掛的預構建主題。您可以看到它的時鐘仍然低於400毫秒。

GeneratePress全網站速度測試

當然，在現實環境中，您可能會執行其他東西，例如Google Analytics、Facebook remarketing pixel、Hotjar等。但是您應該能夠輕鬆地將目標鎖定在1秒以內。在woorkup上檢視對GeneratePress的深入評價。

我們將在下面向您展示更多優化和加速WordPress的方法。

OceanWP

OceanWP主題是輕量級和高度可擴充套件的。它使您能夠建立幾乎任何型別的網站，例如部落格、作品展示、商業網站或WooCommerce店面，設計精美且專業。由Nicolas Lecocq構建，它也得到了積極的更新和良好的支援。

就像GeneratePress一樣，有免費版和高階版。如果您檢視WordPress主題庫，免費版本目前有超過400,000次活躍安裝。

OceanWP

它有多快？我們重新安裝了OceanWP，在Pingdom中進行了五次速度測試，並取了平均值。總載入時間為389毫秒，總頁面大小僅為230.8KB。OceanWP中的指令碼稍大，但沒有什麼可寫的。

OceanWP全新安裝速度測試

然後，我們使用OceanWP站點庫中的一個演示主題執行了另一組測試。這包含影象、背景、新部分和所需的Elementor頁面構建器外掛。您可以看到它的時鐘仍然低於600毫秒。

OceanWP全站速度測試

Astra

Astra是一個快速、完全可定製且美觀的主題，適用於部落格、個人作品集、商業網站和WooCommerce店面。它非常輕巧（前端小於50KB）並提供無與倫比的速度。由Brainstorm Force團隊構建，它得到了積極的更新和良好的支援。您可能會認為他們是流行的All In One Schema Rich Snippets外掛的建立者，該外掛已經存在多年。

就像GeneratePress和OceanWP一樣，有免費和高階版本可用。如果您檢視WordPress主題庫，免費版本目前有超過400,000次活躍安裝、1.6+萬次下載。

WordPress主題-Astra

它有多快？我們重新安裝了Astra，在Pingdom中進行了五次速度測試，並取了平均值。總載入時間為243毫秒，總頁面大小僅為26.6KB。

Astra全新安裝速度測試

然後，我們使用Astra Starter套件站點庫中的一個演示主題執行了另一組測試。這包含影象、背景、新部分和所需的Elementor頁面構建器外掛。您可以看到它的時鐘仍然低於700毫秒。注意：這個演示中的影象是完全壓縮的，但他們從一開始就選擇了非常高解析度的影象。

Astra全站速度測試

重要的是要對這三個主題的速度測試之間的差異持保留態度。問題是幾乎不可能進行完全準確的並排比較。我們想向您展示的重要一點是，所有這些WordPress主題都非常快速，無論是開箱即用還是完整演示！

關於頁面構建器的警告

您可能已經注意到，OceanWP和Astra都要求頁面構建器使用他們的站點庫主題。在使用頁面構建器外掛時，請記住以下幾點：

• 某些頁面構建器可能會增加您網站的載入時間。這是因為他們必須載入額外的CSS和JS才能在沒有程式碼的情況下為您工作。魔法就是這樣發生的！我們始終建議  在安裝頁面構建器之前和之後對您的WordPress網站進行速度測試。
• 您正在提交併將自己鎖定在該頁面構建器中進行設計。確保您選擇一個定期更新並擁有長期所需的一切。

話雖如此，我們仍然是Elementor和Beaver Builder等頁面構建器的忠實粉絲。在大多數情況下，它們的開發都考慮到了效能，只增加了一點點開銷。對於大多數人來說，功能和可用性是值得的，因為這些外掛允許您建立任何您能想到的東西！在某些情況下，它們也可能更快，因為它們可能會替代5個以上的其他外掛，否則您將不得不使用它們。

但是，如果您不需要頁面構建器外掛，無論如何，不​​要只安裝一個就可以了。看看新的古騰堡編輯器將如何在未來幾年的網站設計中發揮作用也很有趣。

WordPress外掛的祕密

現在是關於WordPress外掛的獨家新聞。您可能被告知不應安裝太多外掛，否則會降低WordPress網站的速度。雖然有時確實如此，但這並不是最關鍵的因素。外掛的數量不如外掛的質量重要。 在那裡，我們說了。

就像主題一樣，外掛的開發方式以及它是否在構建時考慮了效能都很重要。有許多客戶正在執行30-40個外掛，他們的網站仍然可以在不到一秒的時間內載入。

雖然向您的網站新增程式碼很有趣，但由於以下原因，這並不總是可行的：

1. 您必須自己維護程式碼並隨著標準的變化保持更新。人們都很忙，為什麼不依靠比大多數人更瞭解標準的優秀開發人員呢？
2. 大多數情況下，編碼良好的外掛不會引入比程式碼本身更多的開銷。
3. 您必須記住，大多數WordPress社羣不像開發人員那樣精通技術。外掛是幫助解決問題的解決方案。

話雖如此，當然糟糕的外掛是您想要遠離的。相信我們，程式碼編寫亂七八糟的外掛都直接導致了效能問題。

Francesco有一篇有趣的文章，他深入研究了WordPress外掛的負載測試，以瞭解它們在WordPress站點的後端（在大多數情況下未快取）上的效能如何。我們將在下面深入探討如何在您的網站上找到不良外掛。

然而，不容忽視的是，人們喜歡WordPress的一大原因是其龐大的第三方外掛庫。但是，僅WordPress.org就列出了56,000多個免費外掛，其他地方還列出了數千個，因此很難找到您需要的一個外掛。談論大海撈針！

我們只嘗試分享我們每天使用的東西。是的，我們和其他人一樣在我們的網站上使用WordPress外掛。

WordPress外掛的一大問題

WordPress外掛的一大問題是解除安裝過程。每當您安裝WordPress外掛或主題時，它都會將資料儲存在資料庫中。問題在於，當您使用其中一種標準方法刪除外掛時，它通常會在資料庫中留下表和行。隨著時間的推移，這可能會增加大量資料，甚至會開始減慢您的網站速度。在我們的示例中，我們解除安裝了Wordfence安全外掛，它在我們的資料庫中留下了24個表（如下所示）。如果它們遺留一些資料在wp_options表，那就更糟了。

WordFence資料表

除了資料庫之外，很多外掛還會留下額外的資料夾和檔案。根據我們的經驗，這在建立用於日誌記錄的額外目錄的安全和快取外掛中很常見。例如，刪除Wordfence外掛後，我們在wp-content目錄中留下了一個“wflogs”資料夾。我們並不是刻意要說Wordfence，市場上的大多數外掛和主題都是這樣工作的。

WordFence日誌

開發人員為什麼要這樣做？

所以你可能想知道，為什麼開發人員在解除安裝和刪除外掛時沒有自我清理選項？嗯，他們確實如此。但是，這裡有幾個原因，為什麼它們可能不那麼明顯。

1. 他們希望保留使用者的設定。如果您刪除WordPress外掛並決定稍後再試，您的所有設定和資料仍將存在。雖然這非常方便，但並不是最有效的方式。
2. 他們不在乎效能。一些開發人員可能會爭辯說，留下表不會影響效能。但想象一下，一個網站在過去十年中使用了數百個外掛，可能生成了數千行或表格。資料庫查詢對您的WordPress站點的效能有重大影響， 如果開發人員不小心， 外掛可能會發出大量此類請求。通常，一個編寫良好的外掛應該只查詢它所關聯的表或行，但是，情況並非總是如此。由於wp_options表中不必要的自動載入資料而導致網站長資料庫查詢  被遺留下來。
3. 他們犯了一個錯誤。WordPress外掛手冊甚至說：“缺乏經驗的開發有時會用失活鉤用於此目的的錯誤。”

好訊息？有一些方法可以正確清理和刪除外掛。檢視我們的以下教程：

• 如何解除安裝WordPress外掛
• 如何手動清理遺留的表

最佳WordPress設定

現在繼續優化WordPress設定。您可以進行以下幾項更改，以幫助加快WordPress網站的速度。其中許多是非常微妙的變化，但一切都有幫助！

更改您的WordPress登入URL

預設情況下，您的WordPress站點的登入URL是domain.com/wp-admin/. 這樣做的問題之一是所有的機器人、黑客和指令碼都知道這一點。通過更改URL，您可以減少自己的目標，更好地保護自己免受暴力攻擊，並減少重複訪問此URL的機器人使用的頻寬。

更改您的WordPress登入URL還有助於防止諸如“429 Too Many Requests”之類的常見錯誤。這不是萬能的解決方案，它只是一個小技巧，可以幫助保護您並減少該頁面上的負載。

要更改您的WordPress登入URL，我們建議使用以下外掛之一：

• WPS Hide Login（免費）
• Perfmatters（高階版，但包括其他效能優化設定。）

在Perfmatters中更改WordPress登入URL

禁用或調整外掛和主題更新

緩慢的WordPress管理儀表盤可能會受到網路、資料中心位置甚至PHP版本的影響。但另一個很少有人談論的因素是在後臺執行的WordPress更新檢查器。這是擁有大量WordPress外掛和主題可能會傷害您的一種情況。WeFoster有一篇關於此的很棒的部落格文章，他們創造了“第三方外掛更新檢查綜合症”或TPPUCS這一短語。

本質上，問題在於內建的WordPress更新檢查器在幕後發出外部GET請求 ( https://third-party-plugin/update-check.php)。有時這可能是週期性的或非常頻繁的。如果它一直髮生，這可能會使您的管理儀表板陷入困境。

這更多是WordPress中的更新檢查器構建方式的問題。如果您正遭受WordPress管理儀表盤載入時間緩慢的困擾，您可能想嘗試一下。補救措施是禁用自動更新。警告：僅當您打算手動檢查更新時才這樣做。許多更新包括安全性和錯誤修復。

要禁用更新，我們建議使用以下外掛之一：

• Disable All WordPress Updates：完全免費，無需設定。做它說的很好。
• Easy Updates Manager：提供對選擇性更新的更多控制。核心版本是免費的。

您可以輕鬆地為自己設定日曆提醒，每週禁用一次外掛，檢查更新，然後重新啟用它。

禁用Pingback

Pingback是被建立時，另一個部落格連結到你的自動化評論。當您連結到自己部落格中的文章時，也可以建立Self-Pingbacks。

我們建議您簡單地禁用它們，因為它們會在您的網站上生成毫無價值的查詢和額外的垃圾郵件。請記住，您的WordPress網站呼叫越少越好，尤其是在高流量網站上。更不用說在您自己的網站上進行pingback非常煩人的事實。請按照以下步驟禁用pingback。

步驟 1 – 禁用來自其他部落格的Pingback

在您的WordPress儀表盤中，單擊“設定 → 討論”。在“討論設定”部分下，取消選中“ 允許其他部落格傳送連結通知（Pingback和Trackback）到新文章”選項。

在WordPress中禁用pingback

第 2 步 – 禁用Self-Pingbacks

在禁用Self-Pingbacks時，您有幾種選擇。您可以使用免費的No Self Pings外掛。或者你可以使用像Perfmatters這樣的高階外掛 。

使用Perfmatters禁用自pingback

或者，您也可以通過將以下程式碼新增到您的WordPress主題functions.php檔案來禁用Self-Pingbacks 。警告，如果操作不當，編輯WordPress主題的源可能會破壞您的網站。提示，您可以使用免費的程式碼片段外掛輕鬆新增這樣的PHP片段。這意味著您永遠不必觸及您的主題。

function wpsites_disable_self_pingbacks( &$links ) {
foreach ( $links as $l => $link )
if ( 0 === strpos( $link, get_option( 'home' ) ) )
unset($links[$l]);
}
add_action( 'pre_ping', 'wpsites_disable_self_pingbacks' );

限制Feed專案及頁面文章數量

無論您的部落格Feed設定為主頁還是網站的另一個頁面，您都不需要同時載入50個縮圖。對於那些執行高流量部落格的人來說，您的主頁是您網站中最重要的頁面，您希望它能夠快速載入。請求和媒體越少，效能就越好。

此外，這正是發明分頁的原因（如下所示）。分頁是您在部落格Feed末尾看到的內容，可讓您瀏覽到下一頁。通常這些是數字，或者他們可能使用“下一個/上一個”文章。您的WordPress主題很可能已經內建了自定義分頁。

分頁

預設情況下，WordPress將新WordPress安裝的限制設定為10，但我們已經看到這種變化太多次了，我們已經數不清了。因此，請務必仔細檢查您使用的值。我們推薦8到12之間的某個值。

您可以在WordPress管理儀表盤的“設定 → 閱讀”下找到此選項。然後，您可以更改“最多顯示部落格頁面”的值。

WordPress限制列表文章數量設定

為什麼快取如此重要

到目前為止，快取是加速WordPress最重要和最簡單的方法之一！ 但在我們向您展示如何使用快取之前，必須首先了解它的工作原理以及可用的不同型別的快取。

說到加快 WordPress 網站的速度，新增快取外掛肯定會有所幫助。每次使用者登陸網站時，瀏覽器都會向網站伺服器傳送請求以檢視頁面。根據圖片、視訊和其他元素的數量，這可能會耗費大量時間。使用快取外掛後，您網站的檔案將被臨時儲存，並以更快的速度提供給訪問者。大多數託管 WordPress 託管提供商都會在託管計劃中提供快取功能，但對於那些沒有這種選項的人來說，WP Rocket 等外掛是一個很好的選擇。

什麼是快取？

簡而言之，在您的WordPress站點上訪問的每個網頁都需要向伺服器發出請求，由該伺服器進行處理（包括資料庫查詢），然後將最終結果從伺服器傳送到使用者的瀏覽器。結果是您的網站，包含所有檔案和元素，使其看起來像它的樣子。

例如，您可能有一個標題、影象、一個選單和一個部落格。由於伺服器必須處理所有這些請求，因此將完整的網頁交付給使用者需要一些時間——尤其是對於笨重或較大的網站。

這就是WordPress快取外掛發揮作用的地方！快取指示伺服器將一些檔案儲存到磁碟或RAM，具體取決於配置。因此，它可以記住並複製過去提供的相同內容。基本上，它減少了生成頁面檢視所需的工作量。因此， 您的網頁載入速度更快，直接從快取中載入。

快取的其他一些好處包括：

• 您的伺服器使用更少的資源——這與速度有關，因為資源越少，網站速度就越快。但是，它也減輕了您伺服器的壓力。這對於高度動態的站點（例如會員站點）以及確定可以和不可以從快取中提供的內容非常重要。
• 你會看到更低的TTFB -快取是降低你的最簡單的方法之一TTFB。事實上，在我們的測試中，快取通常會將TTFB減少多達90%！

快取型別

對於快取型別，常用的有兩種不同的方法：

1. 伺服器級快取
2. 使用外掛快取

1. 伺服器級快取

到目前為止，伺服器級別的快取對於終端使用者來說是最簡單的方法之一。這意味著WordPress託管服務提供商會為您處理。您可以使用以下四種型別的快取，它們都是在軟體或伺服器級別自動完成的：

• 位元組碼快取
• 物件快取
• 頁面快取
• CDN快取

這意味著您無需擔心弄亂任何複雜和令人困惑的快取外掛。

頁面快取配置為與標準WordPress一起開箱即用。你什麼都不用做！只需啟動您的WordPress網站，頁面快取就會開始發生。

您還可以為WooCommerce和Easy Digital Downloads等電子商務網站制定了快取規則。預設情況下，某些不應該被快取的頁面，例如購物車、我的賬戶和結帳，被排除在快取之外。當做伺服器快取時，必須設定一些cookie及使用者操作規則，以便於使用者觸發規則時自動繞過快取，以確保結帳過程順利且同步。

如果做伺服器級別的快取策略，最好能夠有快速清理快取的路徑，比如在WordPress儀表盤新增清理快取入口，或者一鍵清除快取的命令列等等。

2. 使用外掛快取

如果您的託管服務提供商不提供快取，您可以使用第三方WordPress快取外掛。根據我們的經驗，我們建議以下之一：

1. WP Rocket (付費)
2. Cache Enabler (免費)
3. W3 Total Cache (免費)

您還可以在我們關於WordPress快取外掛的深入文章中檢視一些其他選項。

無快取與快取

快取有多大幫助？

下面是做與不做伺服器級快取的一些速度測試，因此您可以看到它在整體速度和TTFB方面的差異。

無快取

我們首先在沒有啟用快取的情況下在Pingdom上執行了五個測試並取了平均值。

無快取速度測試

無快取TTFB

同樣重要的是要注意TTFB沒有快取和有快取的區別。Pingdom中的TTFB由黃色的“等待”欄表示。如您所見，沒有快取的TTFB為192毫秒。您可以看到它不是從快取中提供的，因為x-kinsta-cache標頭顯示的是MISS。

TTFB無快取

啟用快取

然後我們啟用伺服器級快取並在Pingdom上執行五次測試並取平均值。

快取啟用速度測試

如您所見，伺服器級快取將我們的頁面載入時間減少了33.77%！ 這不需要任何額外的工作。我們測試的這個站點也經過了相當的優化，因此較大的未優化站點必然會看到更大的差異。

啟用快取的TTFB

現在，如果我們檢視啟用快取的TTFB，我們可以看到它低於35毫秒。您可以看到它是從快取中提供的，因為x-kinsta-cache標頭顯示了HIT。

帶快取的TTFB

CDN快取也與來自WordPress主機的快取同樣重要。我們將在下面進一步深入研究CDN。

快取和會員站點的問題

會員網站包含許多無法快取的內容和不斷變化的頁面。諸如社羣成員的登入頁面（根據站點的大小可能會不斷被點選）、數字商品或課程的結帳頁面以及討論板等內容是常見的罪魁禍首和痛點，因為這些通常無法快取。

然而，它還不止於此。在標準WordPress站點上，WordPress儀表盤也不會為“登入”使用者快取。當您只有少數作者和管理員時這很好，但是當您突然有數千名成員使用儀表板時，這會立即導致效能問題，因為它無法從伺服器上的快取中提供服務。這意味著您需要幕後的力量和架構來支援它。在這些情況下，共享主機提供商通常會癱瘓。

高動態站點的物件快取

對於WordPress會員站點，您的常用快取設定通常是不夠的，因為它們並不總是充分利用它。這就是物件快取發揮作用的地方。

物件快取儲存資料庫查詢的結果，以便下次需要特定位的資料時，無需查詢資料庫即可從快取中傳送。這加快了PHP的執行時間並減少了資料庫的負載。這對於會員網站變得非常重要！使用WordPress，您可以通過幾種不同的方式實現物件快取：

1. 第三方快取解決方案，例如W3 Total Cache
2. Redis（推薦）
3. 記憶體快取

分析快取

還記得x-kinsta-cache 我們上面提到的那個標題嗎？根據您的託管服務提供商或快取解決方案，標頭的名稱可能略有不同。每次從您的WordPress站點發出請求時，標頭都有一個值，例如HIT、BYPASS、MISS和EXPIRED。這使您可以檢視快取的執行情況。

提高WordPress網站的快取命中率很重要，因為您希望儘可能多的網站從快取中獲得服務。您可以分析快取日誌中的資料， 以確定是否存在可以快取的快取BYPASSing GET請求或可以消除的POST請求。

快取元件堆疊（如下所示）讓您可以檢視每個請求的狀態，無論是HIT、BYPASS、MISS還是EXPIRED。您可以按過去24小時、7天或30天過濾資料。

快取元件棧

快取元件圖表讓您一目瞭然您的快取比率。您從快取中提供的請求越多越好。正如您在下面的示例中看到的，這個WordPress站點的HIT快取率為 96.2%。哪個好！

快取元件圖

頂部快取繞過部分可讓您檢視哪些請求未從快取中提供。通常，這些可能包括CRON作業、admin-ajax請求、電子商務結帳頁面、查詢字串和UTM引數等。

WordPress頂級快取繞過

影象優化是必須的

WordPress 最大的速度障礙之一就是圖片。如果尺寸不正確，它們會破壞您的 TTFB。它們還會損害搜尋引擎優化和您在 SERP 中的排名。為了避免這種情況，請始終確保圖片大小正確。雖然您可以手動操作，但擁有成百上千張照片的網站需要一個更實用的解決方案：圖片優化外掛。這些外掛可以調整現有圖片的大小，並自動調整上傳圖片的大小。Ewww Image Optimizer 就是一個不錯的選擇，它可以在上傳圖片時調整圖片大小，移除嵌入的後設資料，並使用懶載入功能壓縮圖片。此外，它還能將網站上的圖片轉換為 WebP 格式，從而大大減小圖片檔案大小。

影象優化是您可以做的另一件簡單的事情，它會對您的整體頁面載入時間產生重大影響。這不是可選的；每個網站都應該這樣做！

大影象會減慢您的網頁速度，從而導致不太理想的使用者體驗。優化影象是使用外掛或指令碼減小檔案大小的過程，從而加快頁面的載入時間。有損和無失真壓縮是常用的兩種方法。

根據HTTP Archive，截至2019年8月，影象平均佔網頁總重量的34%。因此，在難以優化的視訊之後，影象是您應該首先開始的地方！它比JavaScript、CSS和字型更重要。具有諷刺意味的是，良好的影象優化工作流程是最容易實現的事情之一，但許多網站所有者卻忽略了這一點。

每頁平均位元組數 (KB)

早在2017年12月，影象平均佔頁面總重量的54%。因此，整個網路似乎在影象優化方面變得越來越好！但34%仍然是一個不容忽視的數字。如果您的網站上沒有任何視訊內容，影象可能仍然是您的頁面權重的第一痛點。

找到平衡點（檔案大小和質量）

格式化影象的主要目標是在最小檔案大小和可接受的質量之間找到平衡。執行幾乎所有這些優化的方法不止一種。最基本的方法之一是在上傳到 WordPress 之前壓縮它們。通常，這可以在Adob​​e Photoshop或Affinity Photo等工具中完成。或者使用來自Google的新的線上Squoosh應用程式。但是，這些任務也可以使用外掛自動執行，我們將在下面詳細介紹。

需要考慮的兩個主要事項是檔案格式和您使用的壓縮型別。通過選擇正確的檔案格式和壓縮型別組合，您可以將影象大小減少多達5倍。您必須對每種影象或檔案格式進行試驗，以瞭解哪種格式效果最好。

在開始修改影象之前，請確保您選擇了最佳檔案型別。您可以使用多種型別的檔案：

• PNG  – 生成更高質量的影象，但也具有更大的檔案大小。被建立為無損影象格式，儘管它也可能是有損的。
• JPEG  – 使用有損和無損優化。您可以調整質量級別以獲得質量和檔案大小的良好平衡。

理想情況下，您應該對具有大量顏色的影象使用JPEG（或JPG），對簡單影象使用PNG。

您還應該考慮在您的網站上使用WEBP圖片。

GIF呢？動畫GIF總是很有趣，但它們會扼殺網路效能。許多GIF的大小超過1MB。我們建議為社交媒體和Slack保留這些。如果您的部落格文章中有一個您離不開它，請檢視如何壓縮GIF動畫。

壓縮質量與大小

這是一個示例，說明過度壓縮影象會發生什麼。第一種是使用非常低的壓縮率，從而獲得最高質量（但檔案更大）。第二種是使用非常高的壓縮率，這會導致影象質量非常低（但檔案大小較小）。注意：未修改的原始影象為2.06MB。

低壓縮（高質量）JPG – 590KB

高壓縮（低質量）JPG – 68KB

如您所見，上面的第一張圖片是590KB。對於一張照片來說，這是相當大的！通常最好將網頁的總重量保持在1或2MB 以下。590 KB已經是四分之一。第二張圖片看起來很可怕，但它只有68KB。您想要做的是在您的壓縮率（質量）和檔案大小之間找到一個合適的媒介。

所以我們再次以中等壓縮率拍攝影象，如下所示，現在質量看起來不錯，檔案大小為151KB，對於高解析度照片來說是可以接受的。這幾乎比低壓縮率的原始照片小4倍。我們儘量將大部分影象保持在100KB 標記以下以獲得最佳效能。

中等壓縮（高質量）JPG – 151KB

有損與無損優化

瞭解您可以使用兩種型別的壓縮也很重要，有損和無損。

有失真壓縮涉及消除影象中的一些資料。因此，這意味著您可能會看到效能下降（質量下降或某些人稱之為畫素化）。所以你必須小心你減少了多少影象。不僅是因為質量，還因為你無法逆轉這個過程。當然，有失真壓縮的一大好處以及為什麼它是最流行的壓縮方法之一是您可以將檔案大小減少相當多。

有失真壓縮比較

與有失真壓縮不同，無失真壓縮不會降低影象質量。這怎麼可能？它通常通過刪除不必要的後設資料（由捕獲影象的裝置生成的自動生成的資料）來完成。但是，這種方法的最大缺點是您不會看到檔案大小的顯著減小。換句話說，它會隨著時間的推移佔用大量磁碟空間。

您將想要嘗試最適合您的方法。但是對於大多數使用者， 我們建議使用有失真壓縮， 因為您可以輕鬆地將影象壓縮70%以上（有時甚至超過90%！）而不會造成太大的質量損失。將此乘以頁面上的15張影象，它將在減少您網站的載入時間方面發揮重要作用。

影象壓縮外掛

好訊息是，您可以使用一些出色的WordPress影象壓縮外掛來自動化整個過程。以下是我們推薦的一些外掛：

• Imagify  （有損和無損——從外部優化影象）
• WP Smush  （有損和無損——從外部優化影象）
• Optimole（有損和無損——從外部優化影象）
• EWWW Cloud（有損和無損 – 從外部優化影象）
• ShortPixel  （有損和無損——從外部優化影象）

選擇影象優化外掛時最重要的事情是使用它在其伺服器上從外部壓縮和優化影象。反過來，這會減少您網站上的負載。以上都是這樣做的。

您可以嘗試下Imagify外掛（國內伺服器不太好用，速度慢）。當我們將影象上傳到WordPress媒體庫時，它會自動壓縮影象。所以我們永遠不必擔心任何事情。隨著時間的推移，您可以瞭解要使用的影象壓縮級別。它提供Normal, Aggressive和Ultra三種模式。

我們使用Aggressive模式 ，通常會根據影象節省60-70% 。注意：我們使用的PNG比JPEG多得多，因為我們的大多數影象都是圖示和插圖，而不是照片。

影象壓縮檔案節省

如果您使用影象壓縮，您的WordPress網站會快多少？這完全取決於原始影象的大小以及壓縮後的大小。但是，我們進行了一些速度測試，發現高質量的影象壓縮解決方案可以將頁面載入時間減少80%以上！

延遲載入

如果你有很多圖片，你可以考慮延遲載入它們。這是一種優化技術，可載入可見內容，但會延遲出現在首屏下方的內容的下載和呈現。

檢視我們的指南，瞭解如何在WordPress中實現延遲載入。這對於包含來自評論的大量gravatar圖示的部落格文章尤其重要。Google也剛剛釋出了他們對延遲載入的建議。

其他影象優化技巧

這裡有一些最終的影象優化技巧可供選擇。

• 上傳大小僅為列或DIV寬度的影象的時代已經結束。響應式影象在WordPress中開箱即用（自 4.4 版起），並將自動向移動使用者顯示較小的影象尺寸。
• SVG可以是使用影象的另一種很棒的替代方法。SVG 的檔案大小通常要小得多，但並非總是如此。檢視我們的教程， 瞭解如何在您的WordPress網站上使用SVG。
• 使用圖示字型而不是在影象中放置文字——它們在縮放時看起來更好，佔用的空間更少。如果您使用字型生成器，則可以進一步優化它們。

微調您的資料庫

接下來是有關如何微調WordPress資料庫的一些提示。就像汽車一樣，您的資料庫需要維護，隨著時間的推移它會變得臃腫。

會員站點尤其使它變得棘手，因為它們通常會生成更復雜的查詢，這反過來會增加從MySQL資料庫檢索資訊的額外延遲。這在很大程度上是由於所有額外的移動部件和大量資料站點所擁有的。這也可能是由嚴重依賴搜尋查詢進行導航或使用的站點引起的 WP_Query。

更不用說，您還有大量併發使用者不斷查詢資料庫。

加快 WordPress 執行速度的另一種方法是保持網站資料庫的清潔。隨著時間的推移，帖子修訂、評論和其他無主資料可能會堆積起來，使網站資料庫變得臃腫，增加不必要的工作量。為確保資料庫快速、無雜亂，可以考慮安裝一個資料庫優化外掛，如 WP-Optimize。

WP-Optimize 是清理資料庫、壓縮圖片、精簡笨重的 CSS 和 JS 檔案的一體化解決方案。對資料庫進行優化後，可以限制可能出現的錯誤，同時控制圖片和指令碼檔案的大小。在優化資料庫之前，請務必先進行備份。否則會導致資料庫錯誤，從而破壞網站檔案和資料庫之間的連線。

但如果你要更全面，更深入地優化您的 WordPress 網站資料庫，請繼續閱讀以下內容：

使用MySQL儲存引擎InnoDB

許多較舊的站點仍在其資料庫中使用MyISAM儲存引擎。近年來，InnoDB表現得更好 ，更可靠。

以下是InnoDB相對於MyISAM的幾個優勢：

• InnoDB具有行級鎖定。MyISAM只有完整的表級鎖定。這使您的查詢處理速度更快。
• InnoDB具有所謂的參照完整性，它涉及支援外來鍵 (RDBMS) 和關係約束，而MyISAM沒有 (DMBS)。
• InnoDB支援事務，這意味著您可以提交和回滾。MyISAM沒有。
• InnoDB更可靠，因為它使用事務日誌進行自動恢復。MyISAM沒有。

所以現在你可能想知道，你執行的是InnoDB還是MyISAM？如果您在一個較新的WordPress站點上執行，您很可能已經在使用MySQL儲存引擎InnoDB。但是對於較舊的WordPress網站，您可能需要快速檢查一下。一些站點甚至可能混合並匹配了MyISAM和InnoDB表，您可以通過將它們全部轉換來看到改進。

請按照以下這些簡單的步驟進行檢查。

第1步

登入到phpMyAdmin並單擊您的MySQL資料庫。

phpMyAdmin資料庫

第2步

快速掃描或對“Type”列進行排序，您就可以看到您的表正在使用哪些儲存引擎型別。在下面的這個示例中，您可以看到其中兩個表仍在使用MyISAM。

MyISAM資料庫表

如果您找到了一些，那麼可能是時候將它們移動到InnoDB了。我們始終建議您聯絡您的房東並詢問他們是否可以為您執行此操作。

但是您始終可以按照以下這些教程手動將MyISAM錶轉換為InnoDB：

• 使用phpMyAdmin將MyISAM轉換為InnoDB
• 使用WP-CLI將MyISAM轉換為InnoDB

刪除和限制頁面併發布修訂

每當您在WordPress中儲存頁面或文章時，它都會建立所謂的修訂版本。這發生在草稿和已更新的已釋出文章中。如果您需要恢復到以前版本的內容，WordPress修訂版本可能會有所幫助。

WordPress修訂版本

但是，修改也會損害WordPress網站的效能。在大型站點上，這可能會很快增加到資料庫中數千行不一定需要的行。並且您擁有的行數越多，您的資料庫的大小就越大， 這會佔用儲存空間。雖然索引是為此目的而建立的，但我們仍然看到這個問題削弱了WordPress網站。您可以做幾件事。

1. 刪除舊版本

如果您有一個包含大量頁面和文章的舊WordPress網站，可能是時候進行快速清理並刪除那些舊的修訂版了。您可以使用MySQL執行此操作，但是由於網路上到處都是錯誤的程式碼片段，我們建議您備份您的站點並使用免費外掛，例如WP-Sweep。

另一個我們最喜歡的外掛WP Rocket也有一個資料庫優化功能來清除修訂。

WP Rocket資料庫優化

如果您使用WP-CLI很方便，那麼您可以使用幾個命令。

通過SSH登入到您的伺服器並執行以下命令以獲取和檢視資料庫中當前的修訂數量。

wp revisions list

WP-CLI修訂列表

如果出現錯誤，您可能需要先 使用以下命令安裝wp-revisions-cli包：

wp package install trepmal/wp-revisions-cli

然後，您可以執行以下命令來清理修訂：

wp revisions clean

2. 限制修訂

另一個好策略是限制每個文章或頁面可以儲存的修訂數量。即使將其設定為10左右，也可以防止修訂失控，尤其是在進行大量更新時。

要限制修訂，您可以將以下程式碼新增到您的wp-config.php檔案中。下面的程式碼需要插入到 ‘ABSPATH’ 上方，否則將無法工作。您可以將數量更改為要在資料庫中儲存的修訂數量。

define('WP_POST_REVISIONS', 10);

限制wp-config.php中的後期修訂

或者您可以使用Perfmatters之類的外掛來限制修訂。

使用Perfmatters外掛限制後期修訂

3. 禁用修訂

最後但並非最不重要的一點是，您還可以完全禁用站點上的修訂。如果您要走這條路線，我們強烈建議您按照上面的第一個選項刪除修訂，然後再禁用它們。這樣您的資料庫就完全沒有所有舊的修訂版，並且不會再新增新的修訂版。

要禁用修訂，您可以將以下程式碼新增到您的wp-config.php檔案中。下面的程式碼需要插入到 ‘ABSPATH’ 上方，否則將無法工作。

define('WP_POST_REVISIONS', false);

在wp-config.php中禁用後期修訂

或者您可以使用Perfmatters之類的外掛來禁用修訂。

使用Perfmatters外掛禁用後期修訂

清理您的wp_options表和自動載入的資料

當談到整體WordPress和資料庫效能時，wp_options表經常被忽視。特別是在較舊的大型網站上，由於第三方外掛和主題遺留的自動載入資料，這很容易成為您網站上查詢時間緩慢的罪魁禍首。相信我們; 我們每天都看到這個！

wp_options表包含您的WordPress站點的各種資料，例如：

• 站點URL、主頁URL、管理員電子郵件、預設類別、每頁文章、時間格式等
• 外掛、主題、小工具的設定
• 臨時快取的資料

WordPress資料庫中的wp_options表

該表包含以下欄位（列）：

• option_id
• option_name
• option_value
• autoload（這是我們在效能方面關心的）

自動載入資料

瞭解wp_options表的重要事項之一是autoload欄位。這包含yes或no值（標誌）。這基本上控制它是否由wp_load_alloptions() 函式載入 。自動載入的資料是在WordPress網站的每個頁面上載入的資料 。就像我們向您展示瞭如何禁止某些指令碼在站點範圍內載入一樣，同樣的想法在這裡也適用。預設情況下，開發人員的自動載入屬性設定為“yes”，但並非每個外掛理論上都應該在每個頁面上載入他們的資料。

WordPress網站可能遇到的問題是wp_options表中有大量自動載入的資料。這通常是以下原因造成的：

• 當資料應該設定為“no”時，外掛會自動載入資料。一個很好的例子就是聯絡表單外掛。它需要在每個頁面上載入資料還是隻在聯絡頁面上載入資料？
• 外掛或主題已從WordPress站點中刪除，但它們的選項仍留在wp_options表中。這可能意味著每次請求都會查詢不必要的自動載入資料。
• 外掛和主題開發人員正在將資料載入到wp_options表中，而不是使用他們自己的表。這方面存在爭議，因為一些開發人員更喜歡不建立額外表的外掛。但是，wp_options表也​​不是為容納數千行而設計的。

太多自動載入的資料是多少？這當然可以變化，但理想情況下，您希望它在300KB到1MB之間。一旦開始接近3-5 MB範圍或更多，很可能可以優化或刪除自動載入的內容。任何超過10MB 的內容都應該立即解決。這並不總是意味著它會導致問題，但這是一個很好的起點。

因為這是一個這樣的問題，我們有一個完整的單獨教程，您需要閱讀有關如何對自動載入的資料進行故障排除以及如何清理它的內容。

清理瞬態

除非您使用物件快取，否則WordPress會在wp_options表中儲存臨時記錄。通常這些都有一個過期時間，應該會隨著時間的推移而消失。然而，情況並非總是如此。我們已經看到一些資料庫中有數千條舊的臨時記錄。事實上，在一個站點中，我們處理了一些損壞的臨時記錄，其中在wp_options表中生成了超過695,000行。

wp_options表中的損壞瞬態

同樣重要的是要注意瞬態預設情況下不會自動載入。您可以使用如下查詢來檢視是否有任何自動載入的瞬態資料。

SELECT * 
FROM `wp_options` 
WHERE `autoload` = 'yes'
AND `option_name` LIKE '%transient%'

更好、更安全的選擇是使用免費外掛，如Transient Cleaner 或Delete Expired Transients，它們只能從您的wp_options表中清除過期的瞬態。但是，現在WordPress中似乎有一個函式，新增在4.9中，用於儲存過期的瞬態。。所以希望這會在您的網站上自動發生。

WP Rocket還能夠在其資料庫優化選項中清除瞬態。

使用WP Rocket清理瞬變

清理WordPress會話

我們看到的另一個常見問題是有時cron作業不同步或不能正確觸發，因此會話沒有得到清理。您可能會在資料庫中獲得大量_wp_session_行。在下面的這個例子中，有問題的站點在他們的 wp_options表中結束了超過300萬行。並且該表的大小已增長到600 MB以上。

具有數百萬行的wp_options表

您可以使用如下所示的查詢來檢視您是否遇到此問題：

SELECT *
FROM `wp_options`
WHERE `option_name` LIKE '_wp_session_%'

wp_session行

在大多數情況下，您可以使用以下命令安全地刪除這些（作為cron作業應該具有的）：

DELETE FROM `wp_options`
WHERE `option_name` LIKE '_wp_session_%'

清理完所有剩餘的 _wp_session_行後，該表只有不到1,000行，大小減少到11MB。

WP會話已清理

它還修復了站點在MySQL中出現的峰值。

MySQL網路事務

新增索引以自動載入

如果清理你的wp_options表還不夠，你可以嘗試在自動載入欄位中新增一個“index”。這基本上可以幫助它更有效地搜尋。10up的出色團隊在wp_options表上執行了一些測試場景，其中包含典型數量的自動載入記錄，以展示向wp_options查詢新增自動載入索引如何提高效能。

wp_options查詢時間 (Img src:  10up )

我們還建議您從WP Bullet檢視這兩個額外的資源：

• 如何將MySQL索引新增到wp_options表
• 使用WP-CLI清理wp_options表

使用Redis作為WordPress的持久物件快取

Redis是一種開源的記憶體資料結構儲存。在WordPress的上下文中，Redis可用於 持久儲存WordPress的本機物件快取生成的值， 以便可以在頁面載入之間重用快取的物件。

使用持久物件快取（如Redis）允許重用快取的物件， 而不需要為同一物件第二次查詢MySQL資料庫。結果是Redis可以減少網站MySQL資料庫的負載，同時減少網站的響應時間並提高網站擴充套件和處理額外流量的能力。

不能很好地利用頁面快取的高度動態的網站（WooCommerce、會員網站、論壇、討論板、具有非常活躍的評論系統的部落格）是持久物件快取選項（如 Redis）的潛在候選者。

使用Elasticsearch加速WordPress搜尋

Elasticsearch是一個開源的全文搜尋引擎。它用於索引資料並以驚人的速度搜尋該資料。

在WordPress的上下文中，Elasticsearch可用於加速WordPress資料庫的查詢。這是通過構建站點資料庫內容的索引，然後使用Elasticsearch比MySQL查詢能夠執行相同搜尋更快地搜尋該索引來完成的。

如果您有時間和能力，可以由知識淵博的WordPress和Elasticsearch開發人員將Elasticsearch與WordPress站點整合。如果您的站點相對標準地使用WP_Query，也可以通過安裝ElasticPress來整合Elasticsearch  ，這是一個來自10up的免費WordPress外掛， 可從WordPress.org獲得，它會自動與WP_Query物件整合以使用Elasticsearch而不是MySQL生成查詢結果。

任何大量使用WP_Query的站點都可以從Elasticsearch中受益。可以從Elasticsearch中受益的站點示例：

• 以搜尋為主要導航方式的網站。
• 具有大量訂單的WooCommerce站點，站點管理員需要能夠定期搜尋訂單列表。
• 任何擁有大量帖子的站點，其中MySQL查詢會產生令人無法接受的緩慢結果。

禁用資料庫密集型的非關鍵功能

這可能看起來有點明顯，但如果您禁用資料庫密集型的非關鍵外掛和主題功能，它會產生很大的不同。

• 流行的和/或相關的文章小部件和外掛很糟糕。他們通常有大量的站點範圍內的查詢。
• 使用您的伺服器壓縮影象的影象優化外掛。您應該始終使用從外部優化影象的影象優化外掛。

比如文章末尾，所謂的“精選”相關文章。這些如果由我們手動選擇並分配給文章。這將查詢減少到幾乎沒有，並且不會損害整個站點的效能。需要做更多的工作嗎？是的，但它可以更好，因為您可以選擇希望讀者看到的內容。

WordPress相關文章

如何做到這一點的呢？我們使用了驚人的高階自定義欄位外掛，然後將這些欄位分配給我們的部落格文章型別。這允許我們搜尋和分配我們想要的任何相關內容到我們的每篇部落格文章（如下所示）。

分配相關文章

我們還建議您遠離為您的網站新增檢視/釋出計數器的外掛，除非您絕對需要它。例如，避免在論壇帖子中使用者頭像旁邊出現“792個文章”或在列出論壇帖子時出現“5,243 次瀏覽”之類的內容。當您進行長時間的討論時，這些計數器將對您的資料庫造成巨大損失。一般來說，儘量減少計數器的使用，只在必要時使用它們。

這也適用於許多社交櫃檯。例如，在下面的這個站點上，您可以看到流行的Social Warfare外掛的響應時間是它下面的下一個外掛的30倍。快取已啟用，但顯然，此外掛對效能造成了相當大的損失。禁用站點上的外掛後，載入時間立即得到改善，WordPress管理儀表盤的響應能力得到改善。

social-warfare載入時間

使用內容交付網路 (CDN)

如果您正在尋找加快 WordPress 執行速度的方法，那麼使用內容分發網路（CDN）是一個極佳的選擇。CDN 是用於儲存網站檔案的計算機伺服器集合。它通常包括世界各地的伺服器，根據訪問者的位置向他們提供網站檔案。通過從離網站訪問者最近的地方向他們提供檔案，網站的載入速度會更快。CDN 還能起到故障保護作用。例如，如果存放檔案的一臺伺服器宕機，另一臺伺服器就能及時趕到，確保網站正常執行。根據您的主機提供商，您可能已經可以訪問免費的 CDN。大多數信譽良好的託管服務提供商，如 SiteGround，都會向客戶提供免費的 CDN，作為託管套餐的一部分。

CDN是內容分發網路的簡稱。這些是遍佈全球的伺服器網路（也稱為POP）。它們旨在託管和交付WordPress站點的靜態（有時是動態）內容的副本，例如影象、CSS、JavaScript和視訊流。

首先，您不想讓CDN與您的WordPress主機混淆。這些是完全獨立的服務。CDN不是您的託管服務提供商的替代品，而是提高網站速度的另一種方式。

CDN的工作原理

CDN究竟是如何工作的？好吧，例如，當您使用一個固定的資料中心託管您的網站時，您必須選擇物理資料中心位置，例如美國、歐洲、亞太地區或南美洲。

假設您選擇美國中央。這意味著您的網站實際上位於愛荷華州康瑟爾布拉夫斯的“主機伺服器”上。當歐洲的人們訪問您的網站時，載入時間比來自德克薩斯州達拉斯的人訪問它的時間更長。

為什麼？因為資料必須傳輸更遠的距離。這就是所謂的延遲。延遲是指通過網路傳輸資料所涉及的時間和/或延遲。距離越遠，延遲越大。

CDN的型別

有兩種不同型別的內容交付網路：

1. 傳統拉式CDN
2. 反向代理CDN

傳統的拉式CDN會快取您所有內容和媒體的副本，但來自客戶端的請求仍會直接傳送給您的託管服務提供商。KeyCDN和CDN77是傳統CDN的示例。

反向代理CDN略有不同。雖然它仍然像CDN一樣，但它會攔截所有傳入的請求並充當客戶端和主機之間的中間伺服器。Cloudflare和Sucuri是反向代理CDN的示例。這就是為什麼您必須將DNS直接指向這些提供商而不是您的主機的原因之一。

這些的好處是因為它們充當中間伺服器，它們可以提供強大的Web應用程式防火牆，可以幫助阻止不良流量訪問您的WordPress站點和/或託管服務提供商。這樣做的一個缺點是，與傳統的拉式CDN相比，它們在效能方面確實帶來了一些額外的開銷。但是有了額外的效能和安全功能，這可以說是微不足道的。

以下是在客戶站點上啟用Sucuri後發生的情況的示例。正如您所看到的，它對通過的不良流量產生了巨大影響。最後，這些型別的服務可以幫助您節省託管成本。

Sucuri WAF之後的資源

CDN速度測試

早些時候我們談到了WordPress快取的巨大好處。嗯，CDN快取也超級強大。這是因為CDN通常比託管提供商擁有更多的伺服器位置。這意味著他們可以將您的所有資產（影象、JS、CSS）快取在離訪問者更近的地方，並以閃電般的速度提供服務。

讓我們進行一些快速測試，看看您的網站使用CDN可以提高多少。

沒有CDN

我們的測試網站託管在美國一伺服器，實際位於美國愛荷華州的資料中心。我們首先在Pingdom中進行了五次速度測試（未啟用CDN），並取平均值。重要提示：我們正在使用Pingdom的歐洲 – 英國 – 倫敦位置來展示CDN的真正力量。總載入時間為1.03 秒。

沒有CDN的速度測試

有CDN

然後我們啟用了我們的CDN並在Pingdom中執行了五個額外的速度測試。 從歐洲-英國-倫敦Pingdom測試地點，我們的總載入時間現在是585毫秒。因此，通過使用CDN，我們能夠將頁面載入時間減少43.2%！

使用CDN進行速度測試

造成如此巨大差異的原因是因為CDN在倫敦有一個資料中心。這意味著所有資產都快取在該位置並準備好以最小的延遲提供服務。

沒有CDN的TTFB

請記住，Pingdom中的黃色條代表等待時間，即到第一個位元組的時間 (TTFB)。在我們沒有CDN的速度測試中，資產的平均TTFB大約為98毫秒。

沒有CDN的TTFB

帶CDN的TTFB

啟用CDN後，資產的平均TTFB下降到平均15毫秒。因此，通過使用CDN，我們的平均TTFB下降了84.69%。這主要是因為資產是直接從CDN的快取中提供的。

帶CDN的TTFB

如何啟用CDN

在您的WordPress網站上啟用CDN並不難，它很容易！只需按照以下步驟操作即可。

第1步

選擇CDN提供商並訂閱他們的服務。這些通常按月計費或按資料使用量計費。大多數提供商都會有一個計算器來估算您的費用。

• 如果您正在考慮自己部署KeyCDN，我們建議您閱讀這篇關於CDN for dummies的文章 。每個CDN提供商還應該有幫助您入門的文件。
• 如果您的網站海外並且面向海外使用者，可以考慮安裝Cloudflare或者安裝Sucuri。

第2步

如果您使用的是傳統的拉式CDN，您可以使用免費外掛（如CDN Enabler、  WP Rocket或Perfmatters）將其與您的 WordPress站點整合。這些外掛會自動將您的資產連結到CDN。您無需做任何工作即可將您的內容放到 CDN 上；這都是放手的！反向代理 CDN 通常不需要任何外掛，儘管有時它們可​​以啟用附加功能。

使用Perfmatters在WordPress中啟用CDN

額外的CDN優化

以下是您可能想要檢視或考慮的一些其他CDN優化。

• 如果你有很多評論，gravatars可以產生很多請求。他們從secure.gravatar.com. 檢視本教程，瞭解如何從CDN載入Gravatar  。
• 您可以從CDN託管自定義Web字型，甚至可以在 CDN 上託管 Google 字型。檢視我們關於本地字型的深入教程。
• 確保從CDN載入您的網站圖示。儘管它很小，但每個請求都很重要！

需要時解除安裝媒體和電子郵件

生成請求的所有內容都會以某種方式影響您網站的效能。對於託管數十萬個檔案或大型媒體的站點，完全解除安裝它可能是明智的。解除安裝與通過CDN提供服務不同。使用CDN時，原始資料仍駐留在您的主機上，CDN只是擁有它的多個副本。

當您的CDN資源上的快取過期時，它會重新查詢您的主機以獲取檔案的最新副本。CDN旨在長時間快取檔案。但由於它們有如此多的POP，當快取在不同區域過期時，可能會進行大量重新查詢。

當您解除安裝媒體或檔案時，這意味著實際上將它們的原始物理位置從您的託管服務提供商處移開。因此，雖然看起來檔案是從您的站點提供的，但它們實際上完全位於其他地方。除了減少對主機的額外查詢之外，第一個原因顯然也是節省磁碟空間。

將媒體遷移至Amazon S3

最流行的儲存解決方案之一是Amazon S3。 Amazon S3是一種儲存解決方案，並且是Amazon Web Services許多產品的一部分。通常這用於需要額外備份或提供大檔案 （下載、軟體、視訊、遊戲、音訊檔案、PDF等）的大型站點 。亞馬遜擁有非常可靠的良好記錄，並且由於其龐大的基礎設施，它們可以提供非常低的儲存成本。S3的部分客戶包括Netflix、Airbnb、SmugMug、Nasdaq等。

因為它們完全處理大容量儲存，所以您幾乎可以保證定價會比您的WordPress主機便宜。將媒體儲存到AWS是一種省錢的好方法，並且第一年免費（最多5GB儲存）。此外，由於對您的媒體的請求是直接從亞馬遜提供的，這會減少您的WordPress網站的負載，這意味著更快的載入時間。

國內站長當然可以考慮將媒體遷移至如阿里雲的OSS和騰訊雲的COS。

將媒體遷移到Google Cloud Storage

另一種流行的儲存解決方案是Google Cloud Storage。由於Google的龐大基礎設施以及它們處理批量儲存的事實，它們可以提供非常低的儲存成本。他們的一些客戶包括Spotify、Vimeo、可口可樂、飛利浦、Evernote和摩托羅拉。

解除安裝事務和營銷電子郵件

無論您是否認為，電子郵件確實會對您的伺服器和伺服器資源產生影響。對於某些主機，尤其是共享主機，濫用此功能甚至可能導致您被暫停。對於那些試圖傳送大量電子郵件的人來說，這尤其成為一個問題。這就是為什麼存在第三方交易電子郵件提供商以及為什麼許多託管提供商完全阻止標準埠上的電子郵件傳送的原因。我們從不建議使用您的託管服務提供商傳送電子郵件。

如果您要傳送時事通訊或批量電子郵件，我們始終建議您使用以下替代方法以獲得最佳效果：

• 使用 不屬於WordPress的第三方專業電子郵件營銷軟體
• 使用事務電子郵件服務提供商 （HTTP API或SMTP）和WordPress

使用第三方服務的其他優勢包括：

• 更好的電子郵件送達率。讓電子郵件提供商做他們最擅長的事情！
• 被列入黑名單的機會更少。
• 可能並不總是可以與您的託管服務提供商設定DMARC記錄。

電子郵件營銷工具

營銷電子郵件的一些示例包括時事通訊、產品和功能公告、銷售、活動邀請、入職提醒等。以下是我們推薦的一些電子郵件營銷工具：

• MailChimp
• Mailerlite
• Drip

事務性電子郵件服務

事務性電子郵件的一些示例包括來自WooCommerce或EDD的購買收據、帳戶建立通知、送貨通知、應用程式錯誤訊息、密碼重置等。 依靠第三方SMTP提供商來確保高送達率. 但根據您的數量，我們始終建議將其移至異地。以下是我們推薦的一些交易電子郵件服務：

• SendGrid
• Mailgun – 瞭解如何在WordPress中配置Mailgun。
• Sparkpost

如何找到瓶頸和緩慢的外掛

現在，我們將深入探討有關如何在您的WordPress網站上找到瓶頸以及您可以採取哪些措施的一些技巧。

使用New Relic識別慢速外掛和資料庫查詢

市場上有一些很棒的工具可以幫助您查明和識別耗時的資料庫查詢和外掛。New Relic是一個PHP監控工具，可用於獲取網站上的詳細效能統計資訊。

但是，請謹慎使用New Relic，因為它會影響站點效能。它將JavaScript新增到您的網站。我們建議您在需要對效能進行故障排除時啟用它，然後再禁用它。

尋找緩慢的外掛

當WordPress外掛導致整體緩慢時，症狀會根據外掛執行的活動而有所不同。但是，在許多情況下，您會發現一個緩慢的外掛會影響WordPress網站的每個頁面。對於您在下圖中看到的資料的站點，在站點的每個前端頁面上都觀察到整體緩慢。以下是New Relic對網站外掛效能的評價。

緩慢的外掛

您可以立即看到adinjector外掛消耗的時間是下一個最慢外掛的15倍以上。

當您看到這樣的資料時，很容易立即將外掛視為編碼不佳或以某種方式無效而不予理會。雖然有時是這種情況，但並非 總是 如此。外掛配置錯誤、資料庫緩慢或響應緩慢的外部資源可能會導致外掛消耗大量時間。

因此，當您看到響應緩慢的外掛時，最好檢查New Relic中的其他幾個螢幕以查詢其他資訊。在決定停用外掛是最好的還是唯一的方法之前，應該檢查事務、資料庫和外部資源。

資料庫不堪重負導致整體緩慢

優化不當的資料庫可能會導致WordPress網站的整體執行緩慢。早些時候，我們討論了很多不同的事情你可以做來解決這個問題。在New Relic中，這種與資料庫相關的緩慢很可能會出現在兩個地方：

• 首先，您將在概覽中看到大量的MySQL活動。
• 其次，您會在資料庫選項卡中看到一個或多個資料庫表佔用了大量時間。

從概覽螢幕開始，一個有困難資料庫的站點可能看起來像這樣：

網路事務時間

要更好地處理導致問題的資料庫表或查詢，請前往資料庫選項卡。

MySQL概述

資料庫選項卡將指出表和消耗最多時間的查詢型別。如果您選擇列表中的條目之一，您可以看到更多詳細資訊，包括一些示例查詢。

慢查詢 – wp_options表

在這種情況下，資料指向wp_options表中自動載入的資料。請記住，我們之前已經討論過了。果然，對該wp_options表的快速分析證實，從該表自動載入了近250MB的資料，使該站點成為資料庫維護和優化的明顯候選站點。

請務必檢視我們關於如何使用New Relic除錯WordPress網站效能問題的深入教程。

使用免費查詢監視器外掛

您還可以使用免費的WordPress外掛Query Monitor。使用它來識別和除錯緩慢的資料庫查詢、  AJAX呼叫、REST API請求等等。此外，該外掛還會報告網站詳細資訊，例如指令碼依賴項和依賴項、在頁面生成期間觸發的WordPress鉤子、託管環境詳細資訊、當前頁面滿足的條件查詢標籤等等。

查詢監視器外掛中的WordPress查詢

該外掛由John Blackbourn開發， 他是WordPress的核心提交者，目前是Human Made的一名開發人員，之前曾受僱於WordPress VIP — 換句話說，他是一位對WordPress非常瞭解的人。Query Monitor於 2013年被新增到WordPress外掛目錄中 ，目前擁有超過10,000次活動安裝——對於開發外掛來說，這是一個令人印象深刻的總數。該外掛的使用者評分為五顆星，這有助於解釋它在開發人員中的受歡迎程度。

檢視我們關於如何使用Query Monitor的完整教程。

在不涉及生產的情況下利用臨時站點

我們不知道沒有暫存環境我們會做什麼。在解決效能問題時，這些是非常寶貴的。如果您的WordPress主機不提供登臺環境，您也可以使用WP Staging之類的外掛 ，儘管這並不容易。

在您啟動並執行臨時站點後，您可以做的第一件事就是禁用所有外掛。由於這是您實時站點的副本，因此您不必擔心會破壞任何內容。這是迄今為止縮小問題範圍的最簡單方法之一。只需轉到外掛，選擇所有外掛，然後從批量選項中選擇“停用”。

禁用所有WordPress外掛

執行此操作後，您可以在New Relic或Query Monitor中監控響應時間，看看會發生什麼。在下面的這個例子中，網站上的響應時間立即回落到正常，所以我們知道這是導致問題的外掛之一。然後，您可以一一重新啟用它們，重複相同的過程，直到找到罪魁禍首。

正常響應時間

以下是我們啟用導致問題的外掛時發生的情況的示例。載入時間（網路事務時間）立即回升。

再次響應時間長

找到導致執行緩慢的外掛後該怎麼辦？以下是我們的建議：

1. 如果您還沒有將您的外掛和主題更新到最新版本。
2. 聯絡外掛或主題的開發人員並尋求他們的幫助。
3. 找到可以提供相同功能的替代外掛。
4. 也許您的PHP版本導致了問題。將您的PHP引擎更改為較低版本，然後檢視外掛或主題是否有效。

您還可以聘請WordPress開發人員來解決該問題。如果它與效能有關，我們必須向WP Bullet的Mike Andreason發出個人呼聲。他是一名專攻效能優化的全職Codeable開發人員，他幫助很多WordPress網站提升到一個新的水平。

WP Bullet之前和之後

檢查您的錯誤日誌

檢查錯誤日誌從來都不是一件有趣的事情，但可以揭示很多關於WordPress外掛的效能問題。如果您是寶塔面板，則可以直接從儀表盤-安全管理-Web日誌管理，輕鬆檢視錯誤日誌、快取日誌和訪問日誌。

寶塔面板中的錯誤日誌

您還可以通過向wp-config.php 檔案中新增一些程式碼來啟用錯誤日誌 。首先，您需要通過SFTP連線到您的站點。然後下載您的， wp-config.php 以便您可以對其進行編輯。注意：始終先備份此檔案！

下載wp-config.php檔案

找到/* That's all, stop editing! Happy blogging. */ 前面說的那一行 ，新增以下內容（如下所示）：

define( 'WP_DEBUG', true );

WP_DEBUG

如果上述程式碼已存在於您的 wp-config.php 檔案中但設定為“false”，只需將其更改為“true”。這將啟用除錯模式。注意：如果存在，您還會在WordPress管理員中看到警告或錯誤。

然後，您可以通過在WP_DEBUG行之後新增以下程式碼來啟用除錯日誌以將所有錯誤傳送到檔案（如下所示）：

define( 'WP_DEBUG_LOG', true );

WP_DEBUG_LOG

儲存您的更改並將其重新上傳到您的伺服器。然後錯誤將記錄到 debug.log 您 /wp-content/ 資料夾中的檔案中。如果由於某種原因你沒有看到這個檔案，你總是可以建立一個。

您的網站可能被黑客入侵

如果您在跟蹤效能問題時遇到困難，很可能是您的網站遭到黑客攻擊、感染了惡意軟體或遭受了DDoS攻擊。這可能會影響您網站的速度，甚至會影響WordPress管理盤錶板的響應能力。在這些情況下，我們建議如下：

1. 實施代理伺服器和WAF，例如Cloudflare或Sucuri。
2. 使用上述服務阻止惡意IP地址。
3. 您還可以實施地理封鎖。有些國家在產生的流量質量方面確實很糟糕。如果您受到攻擊，您可能需要暫時或永久封鎖整個國家/地區。

使用錯誤程式碼（HTTP 狀態程式碼）進行故障排除

HTTP狀態程式碼就像來自Web伺服器的簡短註釋，它被新增到網頁的頂部。它不是網頁的一部分。相反，它是來自伺服器的訊息，讓您知道當伺服器收到檢視頁面的請求時事情的進展情況。當涉及到故障排除時，這些是無價的！

雖然有40多種不同的狀態程式碼，但以下是我們看到WordPress使用者苦苦掙扎的常見狀態程式碼。

429：“請求太多。” 當使用者在給定時間內傳送過多請求時由伺服器生成（速率限制）。這有時可能是由於機器人或指令碼試圖訪問您的網站而發生的。在這種情況下，您可能想嘗試更改WordPress登入URL。

429請求過多

500：“伺服器出現錯誤，請求無法完成。”  一個簡單的意思是“內部伺服器錯誤”的通用程式碼。伺服器出現問題，請求的資源未交付。此程式碼通常由第三方外掛、錯誤的 PHP 甚至與資料庫的連線中斷生成。檢視我們的教程，瞭解如何修復建立資料庫連線的錯誤以及解決500內部伺服器錯誤的其他方法 。

建立資料庫連線時出錯

502：“錯誤閘道器。”此錯誤程式碼通常表示一臺伺服器收到了來自另一臺伺服器的無效響應。有時查詢或請求會花費太長時間，因此它會被伺服器取消或終止，並且與資料庫的連線中斷。檢視我們關於如何修復502 Bad Gateway錯誤的深入教程 。

瀏覽器中的502 Bad Gateway

503：“伺服器現在無法處理此請求。”  現在無法完成請求。此程式碼可能由無法處理其他請求的過載伺服器返回。

504：“作為閘道器的伺服器超時等待另一臺伺服器響應。”  當有兩臺伺服器參與處理請求，並且第一臺伺服器超時等待第二臺伺服器響應時返回的程式碼。閱讀有關如何修復504錯誤的更多資訊 。

瀏覽器中的504閘道器超時錯誤

後端優化建議

現在我們將深入探討一些可以通過優化後端來加速 WordPress 的方法。後端通常涉及完全由伺服器處理的任何內容，例如PHP、HTTP快取標頭、GZIP壓縮等。

 建立輕量級404頁面

我們親眼目睹了高度動態的站點通常會產生大量404錯誤。您的網站生成的內容可能比您想象的要多！

404錯誤

這些錯誤之所以不好，是因為許多404頁面非常佔用資源。對於高度動態的WordPress站點，您需要避免使用繁重的404頁面。建立一個 簡單的404模板 ，儘可能避免進一步查詢資料庫。當然，花一些時間來修復404錯誤，因為這不僅會佔用大量資源，而且對使用者體驗也很不利。

除了使用輕量級404頁面之外，我們還建議為404頁面實施特殊的頁面快取規則。如果我們的Web伺服器檢測到已建立與快取的404頁面具有相同URL的新頁面，我們將自動清除快取。如果您的WordPress站點沒有可快取的404頁面，我們建議您與您的主機一起將此功能新增到您的Web伺服器。

增加PHP Worker

PHP Worker可能是一個您從未聽說過的術語，但它們是處理限制請求的主機數量（而不是通過CPU或RAM來限制您，這通常是共享主機提供商所做的）。

PHP Worker確定您的站點在給定時間可以處理多少個併發請求。簡而言之，您網站的每個未快取請求都由PHP Worker處理。例如，如果您有4個請求同時到達您的站點，並且您的站點有2個PHP Worker，那麼其中兩個請求將得到處理，而另外兩個將不得不在佇列中等待，直到前兩個請求完成加工。

請記住，我們之前討論過，WordPress會員站點的最大問題之一是所有未快取的請求。這就是PHP worker變得非常重要的原因，因為他們必須為每個請求工作。因此，這些站點通常需要額外的PHP Worker來確保每個請求都得到及時處理併成功完成。

如果你不斷地最大化你的PHP Worker，會發生什麼？基本上，佇列開始推出較舊的請求，這可能會導致您網站上出現500個錯誤。

使用GZIP壓縮

儘管有快取和影象優化工具，但在網站上啟用 GZIP 壓縮功能可以進一步提高網站速度。GZIP 是一種壓縮技術，通過在傳輸前壓縮網頁、樣式表和 JavaScript 檔案等資源，從而減小其大小。這樣可以最大限度地減少資料傳輸，從而加快載入速度。當瀏覽器請求頁面時，伺服器會檢查是否支援 GZIP。如果支援，伺服器會在傳送前壓縮檔案。收到檔案後，瀏覽器會解壓縮並顯示內容。GZIP 不僅能加快 WordPress 的速度，還能提高頻寬效率和搜尋引擎優化。一些快取外掛（如 WP Rocket）會自動啟用 GZIP。其他外掛，如 WP-Optimize，提供 GZIP 功能，但需要手動啟用。

GZIP是一種檔案格式，是一種用於檔案壓縮和解壓的軟體應用程式。GZIP壓縮在伺服器端啟用，並允許進一步減小HTML、樣式表和JavaScript檔案的大小。

當Web瀏覽器訪問網站時，它會通過檢視content-encoding: gzipHTTP標頭是否存在來檢查Web伺服器是否啟用了GZIP 。如果檢測到標頭，它將提供壓縮的和較小的檔案。如果沒有，它將提供未壓縮的檔案。如果您沒有啟用GZIP，您很可能會在Google PageSpeed Insights和GTmetrix等速度測試工具中看到警告和錯誤 。

內容編碼：gzip

啟用GZIP壓縮有助於減小網頁的大小，這可以顯著減少下載資源的時間，減少客戶端的資料使用量，並縮短首次呈現頁面的時間。這在大多數託管服務提供商中現在是非常標準的，但在這一點上沒有什麼讓我們感到驚訝的了。

啟用盜鏈保護

盜鏈的概念非常簡單。您可以 Internet上的某處找到影象，然後直接在您的站點上使用影象的 URL。此圖片將顯示在您的網站上，但將從原始位置提供。這對盜鏈者來說非常方便，但實際上是盜竊，因為它在使用盜鏈網站的資源。這就像我們上車開走我們從鄰居車裡吸走的汽油一樣。

盜鏈可能會大量消耗目標伺服器的資源。想象一下，如果您在共享的WordPress主機上，而赫芬頓郵報突然連結到您的影象。您網站上的每小時查詢可能會從幾百次增加到幾十萬次。這甚至可能導致您的主機帳戶被暫停。這是一個不僅要使用高效能主機 （可以處理像這樣的打嗝），還要啟用熱連結保護的原因，所以這不會發生。

檢視我們關於如何防止盜鏈的教程。

最小化重定向並在伺服器級別新增它們

太多的重定向總是你需要注意的事情。簡單的重定向，如單個301重定向、HTTP到HTTPS或www到非www（反之亦然）都可以。很多時候，您網站的某些區域需要這些。但是，每個都會對您網站的效能產生影響。如果您開始將重定向堆疊在一起，那麼重要的是要了解它們如何影響您的網站。這適用於頁面和帖子重定向、影象重定向等。

重定向將在響應標頭狀態上生成301或302。

最小化重定向 – 301

重定向對您的網站有多大影響？讓我們做一個小測試。首先，我們 在聯絡我們頁面上執行速度測試：  https://perfmatters.io?ref=1172/contact/。如下所示，我們的總載入時間為417毫秒。

沒有重定向的網站速度測試

然後我們稍微修改URL並執行另一個速度測試以檢視多次重定向的影響。 http://www.perfmatters.io/contact. 如您所見，現在載入同一個頁面需要695毫秒。這增加了66%。

具有多個重定向的網站速度測試

使用免費的WordPress外掛來實現重定向有時會導致效能問題，因為它們中的大多數使用wp_redirect 函式，這需要額外的程式碼執行和資源。其中一些還將自動載入的資料新增到wp_options表，這會增加資料庫膨脹。在伺服器級別新增它們是應該完成的地方。寶塔使用者可以使用其他提供的重定向規則工具實現301重定向。

新增301重定向

您還可以使用我們的蜘蛛分析外掛，以檢視不同搜尋引擎蜘蛛爬蟲反饋的301、302和304等http狀態碼連線。

利用蜘蛛爬蟲分析統計不同狀態碼

檢視我們關於WordPress重定向的深入文章 ，以及提高效能的最佳實踐。

不要讓Cron工作失控

CRON作業 (WP-Cron) 用於為您的WordPress站點安排重複性任務。但是，隨著時間的推移，這些可能會失控並導致效能問題。您可以使用免費的WP Crontrol外掛來檢查和處理您網站上發生的所有Cron作業。

我們還看到了WordPress內建Cron處理程式的效能問題：WP-Cron。如果一個站點沒有足夠的PHP worker，有時會有一個請求進來，WordPress會生成cron，但是cron必須等待worker，因此只是坐在那裡。更好的方法是禁用WP-Cron並改用系統cron。這甚至在官方外掛手冊中也有推薦。

要禁用WP-Cron，請將以下內容新增到您的wp-config.php檔案中，就在“That’s all, stop editing! Happy blogging.” 注意：這會禁用它在頁面載入時執行，而不是當您直接通過wp-cron.php.

define('DISABLE_WP_CRON', true);

禁用WP-Cron

然後您需要從您的伺服器安排wp-cron.php。

新增快取控制和過期標頭（確定快取長度）

WordPress站點上的每個指令碼都需要附加一個HTTP快取標頭（或者應該附加）。這決定了檔案上的快取何時到期。要解決此問題，請確保您的WordPress主機具有正確的 cache-control標頭和 expires 標頭設定。如果不這樣做，您很可能會看到有關需要在速度測試工具中新增過期標頭或利用瀏覽器快取的警告。

當cache-control標頭開啟客戶端快取並設定資源的max-age時，expires標頭用於指定資源不再有效的特定時間點。雖然兩個標頭可以一起使用，但您不一定需要新增兩個標頭。cache-control較新，通常是推薦的方法。

利用瀏覽器快取 – 快取標頭

如果您的伺服器缺少這些標頭，您可以手動新增它們。

在Nginx中新增快取控制標頭

您可以通過將以下內容新增到伺服器配置的伺服器位置或塊來在Nginx中新增cache-control標頭。

location ~* \.(js|css|png|jpg|jpeg|gif|svg|ico)$ {
expires 30d;
add_header Cache-Control "public, no-transform";
}

在Nginx中新增過期標頭

您可以通過將以下內容新增到您的伺服器塊來在Nginx中新增expires標頭。在此示例中，您可以看到如何根據檔案型別指定不同的過期時間。

    location ~*  \.(jpg|jpeg|gif|png|svg)$ {
expires 365d;
}
location ~*  \.(pdf|css|html|js|swf)$ {
expires 2d;
}

在Apache中新增快取控制標頭

您可以通過將以下內容新增到檔案 .htaccess中來在Apache中新增cache-control標頭。程式碼片段可以新增到檔案的頂部或底部（在#BEGIN WordPress之前或#END WordPress之後）。

<filesMatch ".(ico|pdf|flv|jpg|jpeg|png|gif|svg|js|css|swf)$">
Header set Cache-Control "max-age=84600, public"
</filesMatch>

在Apache中新增過期標頭

您可以通過將以下內容新增到.htaccess檔案中來在Apache中新增expires標頭。

## EXPIRES HEADER CACHING ##
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/jpg "access 1 year"
ExpiresByType image/jpeg "access 1 year"
ExpiresByType image/gif "access 1 year"
ExpiresByType image/png "access 1 year"
ExpiresByType image/svg "access 1 year"
ExpiresByType text/css "access 1 month"
ExpiresByType application/pdf "access 1 month"
ExpiresByType application/javascript "access 1 month"
ExpiresByType application/x-javascript "access 1 month"
ExpiresByType application/x-shockwave-flash "access 1 month"
ExpiresByType image/x-icon "access 1 year"
ExpiresDefault "access 2 days"
</IfModule>
## EXPIRES HEADER CACHING ##

同樣重要的是要注意，您只能在伺服器上的資源上新增HTTP快取標頭。如果您收到警告，也許您需要在第三方請求上利用瀏覽器快取，您無能為力，因為您沒有通過他們的伺服器發出請求。常見的罪魁禍首包括 Google Analytics指令碼和營銷畫素，如Facebook和Twitter。

如果您嘗試使用Google Analytics指令碼解決此問題，您可以使用Perfmatters或WP Rocket等外掛在本地或CDN上託管它（儘管這不受官方支援）  。

新增Last-Modified和ETag標頭（驗證快取）

接下來，我們還有另外兩組標題，last-modified和etag.

雖然 cache-control和 expires 標頭幫助瀏覽器確定自上次請求以來檔案是否已更改（或者更確切地說，它們驗證快取）。在 last-modified和etag標頭都驗證並設定快取的長度，應包括在每一個原始伺服器的響應。如果這些設定不正確，您可能會看到一條警告，提示您需要“指定快取驗證器”。

HTTP標頭Last-modified和ETag

如果沒有找到標頭，它每次都會為資源生成一個新的請求，這會增加伺服器的負載。 利用快取頭確保 後續請求不必從伺服器載入，從而為使用者節省頻寬並提高效能。

如果您使用的是CDN，它們很可能也會為您新增這些標頭。就像使用 cache-control和 expires一樣，您不能在外部資源上手動設定這些HTTP標頭。

最後修改的標頭

最後修改的標頭通常自動從伺服器傳送。這是一個您通常不需要手動新增的標題 。傳送它是為了檢視自上次請求以來瀏覽器快取中的檔案是否已被修改。您可以在Pingdom中檢視header請求或使用Chrome DevTools檢視最後修改的標頭的值。

ETag標頭

ETag標頭也很類似Last-Modified頭。它還用於驗證檔案的快取。如果您執行的是Apache 2.4或更高版本，則ETag標頭已使用FileETag指令自動新增 。就Nginx而言，自2016年以來，ETag標頭已預設啟用。

您可以使用以下程式碼在Nginx中手動啟用ETag標頭。

etag on

新增Vary: Accept-Encoding標頭

vary: Accept-Encoding標頭應包括在每一個原始伺服器的響應，因為它告訴瀏覽器客戶端是否能夠處理壓縮內容的版本。如果未正確設定，您可能會看到一條警告，提示您需要“Specify Vary: Accept-Encoding Header”。

例如，假設您有一個沒有gzip壓縮的舊瀏覽器和一個帶有它的現代瀏覽器。如果您不使用 vary: Accept-Encoding 標頭，您的Web伺服器或CDN可能會快取未壓縮的版本並錯誤地將其傳送到現代瀏覽器，這反過來會損害您的WordPress網站的效能。通過使用標頭，您可以確保您的 Web伺服器和/或CDN提供適當的版本

HTTP標頭Accept-Encoding

如果您使用的是CDN，它們很可能也會為您新增這些標頭。就像我們上面討論的其他快取標頭一樣，您不能在外部資源上手動設定此標頭。

在Apache中新增Vary：Accept-Encoding標頭

您可以通過將以下內容新增到您的.htaccess檔案中，在Apache中新增變數：Accept-Encoding標頭。

<IfModule mod_headers.c>
  <FilesMatch ".(js|css|xml|gz|html)$">
    Header append Vary: Accept-Encoding
  </FilesMatch>
</IfModule>

在Nginx中新增 Vary: Accept-Encoding Header

您可以通過將以下程式碼新增到配置檔案中，在Nginx中新增vary: Accept-Encoding標頭。所有Nginx配置檔案都位於該 /etc/nginx/ 目錄中。主要配置檔案是 /etc/nginx/nginx.conf.

gzip_vary on

在wp-config.php中更改WordPress記憶體限制

正如WordPress Codex中所述，對於WordPress版本2.5，WP_MEMORY_LIMIT選項允許您指定PHP可以消耗的最大記憶體量。如果您收到諸如“已用盡 xxxxxx 位元組的允許記憶體大小”之類的訊息，則可能需要此設定。

預設情況下，WordPress會嘗試將分配給PHP的記憶體增加到單個站點的40MB和多站點的64MB。它們在檔案的./wp-includes/default-constants.php第 32 – 44 行（原始碼）上定義了記憶體限制。

然後memory_limit ，您的託管服務提供商也會在伺服器上安裝PHP 。這是兩件不同的事情。一般情況我們應該將memory_limit預設值設定為 256M。如果您遇到記憶體大小耗盡錯誤，您可以嘗試增加WordPress中的PHP記憶體限制。

將以下內容新增到您的wp-config.php file，在“That’s all, stop editing! Happy blogging.”之前。

define( 'WP_MEMORY_LIMIT', '256M' );

Jan Reilink也有一篇很棒的部落格文章，其中更詳細地描述了WordPress記憶體限制問題。他還提供了您可以使用的程式碼的變體。您可以將其設定為PHPmemory_limit值，而不是手動設定數量。

define( 'WP_MEMORY_LIMIT', ini_get( 'memory_limit' ) );

前端優化和外部服務的技巧

現在我們將深入探討一些可以通過優化前端來加速WordPress的方法。前端通常涉及完全由客戶端瀏覽器處理的任何內容，例如CSS、JavasScript、影象等。這還包括分析您在站點上載入的外部服務以及它們如何影響您的整體載入時間。

在前端優化方面，您應該擁有的兩個最重要的目標是：

• 減少您的整體網頁大小。CSS、JavaScript、影象的大小很重要。4MB網站的載入速度通常比1MB網站慢得多。但是，Paul Calvano有一篇很棒的文章，介紹了頁面大小對載入時間的影響，以及確保它不是您跟蹤的唯一內容的重要性，因為有時這可能會產生誤導。
• 減少HTTP請求和外部服務。 通過HTTP/2  ，現在可以使用單個TCP連線同時傳送多個請求和響應。雖然這對效能來說很棒，但減少HTTP請求仍然可以幫助加速您的WordPress網站。這還包括減少外部請求和服務的總數。這些都會增加額外的延遲，例如DNS查詢、TLS連線和網路延遲。

速度測試您的WordPress網站以獲得基線

在優化網站的前端時，從基線開始總是好的。這通常意味著您需要執行速度測試。有多種方法可以做到這一點，請檢視我們的15個很棒的網站速度測試工具列表。

Pingdom網站速度測試

檢視我們關於如何使用Pingdom和如何使用GTmetrix的深入教程。在進行速度測試時，請記住以下幾點：

1. 選擇一種工具並堅持使用

我們是Pingdom、GTmetrix、WebPageTest、PageSpeed Insights和Chrome DevTools的忠實粉絲。但是，您使用哪種速度測試工具並不重要，因為它是您一致的。它們都有不同的測量和量化速度的方法，因此請選擇一種工具並在所有測試和優化過程中堅持使用它。甚至谷歌也說選擇一個。

2. 不要執著於完美的分數

許多工具（例如Google PageSpeed Insights）都有某種型別的速度或效能分數。重要的是要記住，分數並不總是像您網站的速度和使用者感知的效能那麼重要。分數可幫助衡量您的表現。但在某些情況下，痴迷於完美的100/100或A分數可能是浪費時間。擁有大量外部指令碼和廣告的大型網站永遠不會獲得滿分，這完全沒問題。

3. 測試地點很重要

您在速度測試時選擇的位置非常重要。正如我們在前面部分中討論的那樣，原因是這一切都與您選擇的資料中心位置有關。TTFB，網路延遲，都發揮作用了。因此，從靠近資料中心的位置和遠離資料中心的位置測試您的站點。這也將幫助您瞭解CDN對您的WordPress網站的影響有多大。

4. 由於快取而多次測試

正如我們前面關於快取的部分所述，如果快取最近在您的WordPress主機或CDN上被清除或過期，它將在HTTP標頭上註冊一個“MISS”。這意味著您的網站或資產不是從快取中提供的。

MISS HTTP標頭

要正確檢視整個站點的速度，您需要檢視從快取載入的所有內容、初始頁面以及所有資產都註冊了“HIT”。這有時需要多次執行速度測試。然後你可以取平均值。

HTTP標頭HIT

現在讓我們進入一些您可以在WordPress網站上進行的前端優化。

刪除查詢字串

人們在速度測試工具中看到的一個常見警告或建議是您應該刪除查詢字串。這是怎麼回事？嗯，基本上它的工作原理是您的CSS和JavaScript檔案通常在其URL的末尾有檔案版本，例如 . 某些伺服器和代理伺服器無法快取查詢字串。因此，通過刪除它們，您有時可以改善快取。https://domain.com/file.min.css?ver=4.5.

你可以使用像Perfmatters這樣的高階外掛 ，它有一個簡單的一鍵式選項來刪除查詢字串。或者您可以手動將以下程式碼新增到您的主題 functions.php 檔案中。更好的選擇是使用像Code Snippets這樣的免費外掛來新增程式碼。這樣您就不必直接編輯主題。

function remove_query_strings() {
if(!is_admin()) {
add_filter('script_loader_src', 'remove_query_strings_split', 15);
add_filter('style_loader_src', 'remove_query_strings_split', 15);
}
}
function remove_query_strings_split($src){
$output = preg_split("/(&ver|\?ver)/", $src);
return $output[0];
}
add_action('init', 'remove_query_strings')

使用查詢字串

這是使用查詢字串載入的指令碼示例。

帶查詢字串

沒有查詢字串

這是刪除查詢字串後的指令碼示例。

沒有查詢字串

但是，在您立即刪除站點上的查詢字串之前，瞭解使用查詢字串的原因很重要。WordPress開發人員通常使用檔案版本控制來解決快取問題。

例如，如果一個外掛開發者推出的更新和變化 style.css ，從 ?ver=4.6 到 ?ver=4.7，這將被視為一個全新的網址，並不會被快取。如果您刪除查詢字串並更新外掛，這可能會導致快取版本繼續提供服務。在某些情況下，這可能會破壞站點的外觀，直到快取的資源過期或快取完全重新整理。

此外，一些CDN可以快取查詢字串。 預設情況下，比如閃電博正在用的又拍雲，查詢字串已經快取在您的資產中。

請參閱我們關於如何從靜態資源中刪除查詢字串的深入教程 。

消除阻止渲染的JavaScript和CSS

當您有檔案阻止頁面儘快載入時，可能會出現關於阻止渲染的JavaScript和CSS的警告。特定的JS和CSS有時是有條件的，這意味著它們不需要顯示首屏內容。您可以通過使用async和defer屬性來防止它們成為渲染阻塞。

消除渲染阻塞資源

要消除阻塞渲染的 JavaScript 和 CSS，您需要執行以下操作：

從關鍵渲染路徑中清除JS

將JavaScript移出關鍵呈現路徑通常是通過向呼叫JavaScript資源的HTML的 script元素新增defer 或 async屬性來完成的。

• async屬性告訴瀏覽器開始下載資源的時候了，而不會減慢HTML解析。一旦資源可用，HTML解析就會暫停，以便可以載入資源。
• defer屬性告訴瀏覽器暫緩下載的資源，直到HTML解析完成。一旦瀏覽器完成了HTML，它將按照它們在文件中出現的順序下載並呈現所有延遲的指令碼。

優化CSS資源的交付

優化CSS的交付本質上意味著您需要弄清楚如何使其不受渲染阻塞。

• 確定呈現首屏內容所需的樣式， 並將這些樣式與HTML內聯。
• 僅在需要時在裝置上有條件地使用CSS。
• 非同步載入剩餘的CSS。

執行上述所有操作有時可能是一個棘手的過程，並且肯定需要根據您在網站上載入的指令碼進行一些調整。這裡有幾個WordPress外掛可以提供幫助：

• Autoptimize
• Async JavaScript
• Hummingbird

有關更詳細的解釋和演練，我們建議檢視我們關於消除阻塞渲染的JavaScript和CSS的文章。

在WordPress中結合外部CSS和JavaScript

使用CDN時通常會看到組合外部CSS警告，因為您將CSS檔案託管在外部域上，例如cdn.domain.com。過去，解決此問題的快速方法是連線您的CSS檔案，或將它們組合起來，以便在單個請求中載入它們。

但是，如果您使用支援HTTP/2的提供程式通過HTTPS執行，則此警告不再像以前那樣重要。使用HTTP/2，現在可以通過單個連線並行載入多個CSS檔案。並且超過86%的瀏覽器支援HTTP/2。

但這並不一定意味著這種優化完全無效。在某些情況下，我們已經看到這仍然可以加快WordPress網站的速度。這取決於檔案的大小以及檔案的數量。因此，這是我們建議您仍然在您的網站上測試的一項優化。

結合外部CSS和JavaScript檔案的最簡單方法之一是使用免費的Autooptimize外掛。將它們組合起來後，您將看到一個“autoptimize_xxxxx.css”或“autoptimize_xxxxx.js”檔案。它還支援從您的CDN載入它們。您也可以使用WP Rocket外掛執行此操作。

組合的CSS和Javascript檔案

檢視我們關於如何在WordPress中結合外部CSS和JavaScript的深入文章。

在HTML、CSS和JavaScript上使用縮小

我們可以通過縮小HTML、CSS和JavaScript資源來減少瀏覽器必須下載的資料量。縮小是從原始碼中刪除不必要的字元（如註釋和空格）的過程。這些字元在開發中非常有用，但它們對於瀏覽器呈現頁面毫無用處。

非縮小的HTML

這是一個非縮小的HTML程式碼示例。

非縮小的HTML程式碼

縮小的HTML

這是一個縮小的HTML程式碼示例。

縮小的HTML程式碼

您可以使用免費的Autooptimize外掛或WP Rocket來輕鬆縮小您的檔案。

使用無Cookie的域

通常，當您提供影象、JavaScript、CSS等內容時，沒有理由  伴隨HTTP cookie，因為它會產生額外的開銷。一旦伺服器為特定域設定了cookie，該域的所有後續HTTP請求都必須包含該cookie。此警告通常出現在具有大量請求的站點上。

我們有一篇關於如何處理來自無cookie域警告的服務靜態內容的深入文章 。很多時候您可以忽略此警告，因為HTTP/2等新協議  現在使這一點變得不那麼重要。新連線的成本通常比通過同一連線流式傳輸所有內容的成本更高。

解決此警告的一種簡單方法是使用CDN提供程式 ，該提供程式可以忽略cookie以及剝離cookie，這將完全阻止客戶端接收Set-Cookie響應標頭。 KeyCDN是一家提供此功能的CDN提供商。預設情況下，您可以看到啟用了以下兩個選項。這是一個簡單的替代方案，而不必費心移動和配置您的站點以從單獨的子域交付靜態資產。

CDN strip cookies

如果您正在執行Cloudflare， 則無法禁用通過其網路提供的資源上的cookie。CloudFlare在您的標頭中包含他們自己的安全cookie。同樣，這些cookie非常小，對效能的影響也非常小。但是，如果您使用CloudFlare，則無法繞過此警告。

解決此問題的第二種方法是重新配置您的WordPress站點，以從新域或子域提供靜態資產。

在WordPress中禁用嵌入

當他們釋出WordPress 4.4時，他們將oEmbed功能合併到核心中。這允許使用者只需貼上URL就可以在他們的網站上嵌入YouTube視訊、推文和許多其他資源，WordPress會自動將其轉換為嵌入內容，並在視覺化編輯器中提供實時預覽。隨著更新，WordPress本身成為oEmbed提供者。

此功能對很多人都很有用，您可能希望保持啟用狀態。但是，這意味著它還會在您的WordPress站點上生成一個額外的HTTP請求來載入wp-embed.min.js 檔案。這會在站點範圍內載入。雖然這個檔案只有1.7KB，但這些東西會隨著時間的推移而增加。請求本身有時比內容下載大小更重要。

wp-embed.min.js檔案

您可以輕鬆地禁止載入此檔案。以下是三個不同的選項：

• 選項1 – Disable Embeds with Plugin
• 選項2 – Disable Embeds with Code
• 選項3 – Move the JavaScript Inline

在WordPress中禁用表情符號

與嵌入類似，在WordPress 4.2中，他們將表情符號的支援新增到舊瀏覽器的核心中。這樣做的一個大問題是它會在您的WordPress站點上生成一個額外的HTTP請求來載入wp-emoji-release.min.js檔案。這會在站點範圍內載入。雖然此檔案只有10.5KB，但如果您不在網站上使用表情符號，則它毫無用處。

wp-emoji-release.min.js

有幾種不同的方法可以在WordPress中禁用表情符號。您可以使用免費外掛或程式碼來實現。

• 使用外掛禁用Emojis
• 使用程式碼禁用Emojis

如何加速WordPress評論或禁用它們

網站上繁忙的評論部分可能會導致許多效能問題。想想讓評論起作用的資源：

• 查詢資料庫以提取現有評論。
• 為每個新評論建立資料庫條目。
• 評論和評論後設資料由訪問者的瀏覽器接收和處理。
• 外部資源，例如Gravatars，被請求、下載和載入（需要單獨的DNS查詢）。
• 在許多情況下，必須下載和處理大型JavaScript和jQuery資源，才能使評論系統按預期方式工作。

您可以使用以下四種不同的選項來加快WordPress評論速度：

選項 1 – 禁用評論

如果您的網站沒有收到很多評論，並且您認為它們沒有增加任何價值，最好完全禁用評論。請記住，評論會影響您的 SEO，因為 Google 通常會將這些內容作為頁面上的附加內容進行抓取，因此您應該只批准高質量的評論。檢視以下三種禁用評論的簡單方法：

• 通過WordPress設定禁用評論
• 使用外掛禁用評論
• 使用程式碼禁用評論

選項 2 – 優化原生WordPress評論

您的第二個選擇是優化WordPress評論系統。一種方法是減少初始頁面載入時載入的評論數量。

1. 轉到WordPress管理區域中的設定 → 討論。
2. 查詢其他評論設定部分。
3. 選中分頁顯示評論的覈取方塊，併為您希望在初始頁面載入時顯示的評論數量新增一個值。

將評論分頁

您的另一個選擇是在CDN上使用主機Gravatars。

預設情況下，當載入WordPress評論時，每個唯一的Gravatar都需要一個HTTP請求。因此，如果一個頁面載入了來自50個不同評論者的評論，則需要50個HTTP請求才能下載所有這些Gravatar。可以想象，這會影響您的頁面速度。更不用說我們看到gravatar.com的外部DNS查詢有時很慢，在某些情況下甚至超時的事實。

檢視如何從CDN載入 Gravatar。

在本地或CDN上託管Gravatar

選項 3 – 使用第三方評論系統

您的第三種選擇是使用第三方評論系統。如果您的站點託管在廉價、資源匱乏的共享伺服器上，那麼使用第三方評論系統可能會加快包含大量評論的頁面的速度。這與影象優化的想法相同，解除安裝工作。

Disqus外部請求

始終確保對您正在嘗試的第三方評論系統進行速度測試。雖然大多數這些請求都是非同步載入的，但如果您使用Disqus，您仍然會注意到一些額外的載入時間。

選項 4 – 延遲載入評論

您的第四個選擇是延遲載入評論，這樣它們就不會減慢初始頁面呈現的速度。以下是您可能想要檢視的幾個外掛：

• Lazy Load for Comments：此外掛允許您延遲載入原生WordPress評論。
• Disqus Conditional Load : 如果你想使用Disqus評論系統，這是延遲載入評論的必備外掛。

禁用WordPress的RSS Feed

如果您沒有在您的網站上使用WordPress的部落格部分，您可以禁用WordPress RSS Feed。雖然這不會對效能產生巨大影響，但一切都會有所幫助。這也是您不必擔心的一件事。

檢視這兩種在WordPress中禁用RSS Feed的不同方法：

• 使用外掛禁用RSS Feed
• 使用程式碼禁用RSS Feed

使用預取和預連線

資源提示和指令，例如prefetch 和preconnect可以是在幕後加速WordPress的好方法。KeyCDN 有一篇優秀的文章和資源提示概述。

預取

DNS預取允許您在使用者單擊連結之前解析域名（在後臺執行DNS查詢），這反過來有助於提高效能。這是通過在WordPress站點的header中新增一個 rel=”dns-prefetch”標籤來完成的。

<link href="//domain.com">

使用DNS預取的一些常見事情是您的CDN URL、谷歌字型、谷歌分析等。

<link href="//cdn.domain.com/">
<link href="//fonts.googleapis.com/">
<link href="//www.google-analytics.com">

大多數現代瀏覽器也支援預取 。檢視我們的教程，瞭解如何向WordPress標頭新增程式碼。

或者您可以使用Perfmatters之類的外掛輕鬆實現DNS預取。只需單擊Perfmatters外掛中的“Extras”選項卡並新增域。格式：（ //domain.tld 每行一個）

預取

預連線

Preconnect允許瀏覽器在HTTP請求之前建立早期連線，消除往返延遲併為使用者節省時間。

預連線是優化工具箱中的一個重要工具……它可以消除請求路徑中許多代價高昂的往返——在某些情況下，將請求延遲減少數百甚至數千毫秒。– lya Grigorik（來源）

它是通過在WordPress站點的Header中新增一個rel=”preconnect”標籤來完成的。

<link href="//domain.com">

您可能希望利用它的一些示例包括您的CDN URL或Google字型。

<link href="https://cdn.domain.com">
<link href="https://fonts.gstatic.com">

大多數現代瀏覽器都支援預連線 ，但Internet Explorer、Safari、IOS Safari和Opera Mini除外。檢視我們的教程，瞭解如何向WordPress的頁頭新增程式碼。

或者您可以使用Perfmatters之類的外掛輕鬆實現預連線。只需單擊Perfmatters外掛中的“Extras”選項卡並新增域。格式：（ scheme://domain.tld 每行一個）。

預連線

基於每頁/文章禁用指令碼

加速WordPress的另一個非常強大的方法是挖掘載入到您的頁面和帖子上的每個請求。您很可能最終會發現在整個站點範圍內載入不應該載入的指令碼。

您可以使用像Perfmatters 這樣的高階外掛，它內建了“指令碼管理器”功能。這允許您在每個頁面/帖子的基礎上禁用指令碼（CSS和JavaScript），甚至只需單擊一下即可在整個站點範圍內禁用指令碼。

這可以用於以下幾個示例：

• 流行的Contact Form 7外掛會在每個頁面和文章上自行載入。您可以一鍵輕鬆地在任何地方禁用它，並僅在您的聯絡頁面上啟用。
• 社交媒體共享外掛應該只載入到您的文章中。您可以輕鬆地在任何地方禁用它並僅載入文章型別，甚至自定義文章型別。
• 目錄外掛 (TOC) 在每個頁面和文章上載入。使用指令碼管理器，您可以輕鬆控制要載入的位置。

為什麼有些外掛以這種方式編碼？

您可能想知道為什麼所有外掛開發人員不只在頁面上檢測到外掛時才載入他們的指令碼？嗯，它比那要複雜一些。例如，如果您有一個像Contact Form 7這樣的外掛，它也有短程式碼，可以讓您將其放置在任何地方。這包括將其放入小部件中。使用 WordPress，與從帖子或頁面後設資料中查詢資料相比，當您將指令碼出列時，從它們中查詢資料要困難得多。

因此，很多時候這是由於可用性問題。他們破壞外掛的可能性越小，他們獲得的票證和支援就越少。然而，市場上有很多外掛，如果他們願意的話，有很多方法可以解決這個問題並編寫程式碼以提高效能。不幸的是，有時下載量和使用者數量之多，使可用性編碼成為優先事項。

遊覽指令碼管理器

我們將向您介紹指令碼管理器。在您的工具欄中單擊它後，您將看到載入到當前URL的所有指令碼，包括JavaScript和CSS檔案。然後您有以下選項：

1. 狀態開啟 （預設設定）
2. 狀態關閉： 隨處禁用（然後您可以選擇要啟用的文章型別以及當前URL）
3. 狀態關閉： 僅在當前URL上禁用（這對於在您的主頁上使用非常有用）
4. 狀態關閉： 例外（當前URL、文章型別或存檔）

Perfmatters指令碼管理器

一切都按外掛或主題名稱分組在一起。這使得一次禁用整個外掛變得非常容易。通常，WordPress外掛將同時包含JavaScript和CSS檔案。一個WordPress主題可能有10個以上的檔案。

選擇和/或修改設定後，請務必點選底部的“儲存”。然後，您可以在網站速度工具中進行測試，以確保指令碼不再載入到頁面或文章上。請務必先清除快取！如果您的網站出現任何視覺問題，您始終可以在設定中重新啟用它以恢復正常。

在woorkup的速度測試中，他們能夠將總載入時間減少20.2%。僅在他們的主頁上，他們就能夠將HTTP請求的數量從46個減少到30個。他們的頁面大小也從506.3 KB縮小到451.6KB。

有關禁用指令碼的其他方法，請檢視我們關於如何實現指定頁面或者文章禁用WordPress外掛載入。

分析第三方效能

基本上，您從站點外部呼叫的任何內容都會對載入時間產生影響。讓這個問題變得更糟的是，其中一些只是間歇性地緩慢，這使得識別問題更加困難。

第三方外部服務可以被視為從您自己的伺服器外部與您的WordPress站點進行通訊的任何內容。以下是我們經常遇到的一些常見示例：

• 社交媒體平臺，如Twitter、Facebook和Instagram（小部工具或轉換畫素）
• 第三方廣告網路，如Google Adsense、Media.net、BuySellAds、Amazon Associates
• 網站分析和跟蹤指令碼，如Google Analytics、Crazy Egg、Hotjar、AdRoll
• A/B測試工具，例如Optimizely、VWO、Unbounce
• WordPress評論系統， 例如Disqus、Jetpack、Facebook 評論
• 備份和安全工具， 例如VaultPress、Sucuri、CodeGuard
• SumoMe、HelloBar等社交分享工具
• CDN網路， 如KeyCDN、Amazon CloudFront、CDN77和StackPath
• 外部託管的Javascript

其中一些第三方跟蹤器對效能有多大影響？在我們自己的案例研究中，我們看到第三方指令碼將頁面載入時間增加了86.08%。

Ghostery還測量了Alexa中排名前500的美國域名，結果令人震驚，儘管對我們來說並不奇怪。當完全沒有跟蹤器被阻止時，網站速度會慢2倍。這意味著這些第三方跟蹤指令碼是降低網路頁面載入速度的主要因素之一。

使用跟蹤器載入時間（圖片來源：Ghostery）

您必須非常小心您的WordPress網站。只需一個錯誤的第三方API呼叫就可能使您的整個站點超時！是的，它不應該那樣工作，但在很多情況下，它確實如此。我們見過它的次數多得數不過來。

New Relic提供了一種出色且簡單的方法來隨時間監控您的外部服務。在下面的這個例子中，我們可以看到對twitcount.com、graph.facebook.com和widgets.pinterest.com的外部呼叫。

社交媒體外部服務響應時間

重要的是，每當您向站點新增新功能或外掛時，您都要調查從中載入的外部資源。越少越好！

始終以移動為先進行優化

谷歌於2018年3月26日開始推出其移動優先索引。此前谷歌的抓取、索引和排名系統使用的是桌面版網站。移動優先索引意味著Googlebot現在將使用您的WordPress網站的移動版本進行索引和排名。這有助於改善移動使用者的搜尋體驗。

在針對移動優先優化您的網站時， 速度是需要關注的最重要因素之一。速度在從可用性到跳出率以及確定潛在買家是否會返回您的網站的所有方面都起著重要作用。事實上，速度現在是Google搜尋和移動搜尋廣告的著陸頁因素。

糟糕的移動體驗將導致大多數使用者永遠不會回來。根據最新的谷歌頁面速度報告，移動網站在2018年的平均載入時間為15秒。 你能想象載入一個頁面要等那麼久嗎？驚人。

使用者需要（並且值得）更好的。根據同一份頁面速度報告，  53%的移動網站訪問者離開的頁面載入時間超過3秒。

緩慢的移動體驗不會扼殺轉化。他們甚至阻止您獲得轉換潛在客戶的機會。隨著頁面載入時間僅增加幾秒鐘，有人彈跳的可能性呈指數級攀升。在針對移動裝置進行優化時，需要考慮以下幾點。

檢視您的移動流量

檢視您獲得的移動流量始終很重要，因為這可能會稍微改變您的優先順序。您可以在Google Analytics中的“Audience → Mobile → Overview.”下檢視有多少移動裝置正在訪問您的網站。正如您在本網站上看到的，其中超過67%的流量來自移動裝置。好多啊！

Google Analytics中的移動流量

確保您的網站是響應式的

在2019年，您的網站更好地響應！這意味著它利用媒體查詢在移動裝置上自動縮小規模。如果您還沒有這樣做，那麼您很可能已經落後於競爭對手。我們在本文前面提到的所有WordPress主題都是完全響應式的，並且在所有裝置上看起來都很棒。

使用Google的移動友好工具來測試並確保您的網站通過所有要求。

移動友好測試

仔細檢查以確保srcset正常工作

在過去，上傳影象以縮放而不讓CSS調整它們的大小非常重要。然而，這不再那麼重要，因為WordPress 4.4現在支援響應式影象 （沒有被CSS縮小）。WordPress會自動為上傳到媒體庫的每個影象建立多種尺寸。通過將影象的可用尺寸包含到 srcset 屬性中，瀏覽器現在可以選擇下載最合適的尺寸並忽略其他尺寸。請參閱下面的程式碼示例。

WordPress原始碼集

由於存在所有第三方影象外掛和自定義，我們已經多次看到它無法正常工作。因此，重要的是要仔細檢查您的影象是否正確地為不同的螢幕尺寸新增了不同版本的srcset屬性。影象優化現在永遠重要。

Google AMP可能是您的解決方案

谷歌AMP  （加速移動頁面專案）最初於2015年10月啟動。該專案依賴於AMP HTML，這是一個完全基於現有網路技術構建的新開放框架，允許網站構建輕量級網頁。簡而言之，它提供了一種提供當前網頁的精簡版本的方法。

我們與Google AMP有一種愛恨交織的關係，很多社羣也是如此。我們自己對此進行了測試，但沒有看到好的結果。然而，這並不意味著你不會。每個網站都不同，Google AMP也在不斷改進。

您可以使用以下外掛之一在WordPress網站上快速開始使用Google AMP：

• 用於WordPress的AMP
• WP AMP

檢視我們關於如何設定Google AMP的深入教程。如果您需要，如何禁用Google AMP。這不僅僅是您可以禁用和完成的事情。

概括

正如您可能知道的那樣，我們沉迷於可以加速WordPress的所有不同方式。擁有一個快速的網站有助於提高您的排名，提高搜尋引擎的可抓取性，提高轉化率，增加網站停留時間，並減少您的反彈建立。更不用說每個人都喜歡訪問快速網站的事實！

我們希望這個加速指南對您有所幫助，並且您能夠帶走一些東西並將它們應用於您的WordPress網站。如果是這樣，請花點時間分享一下。

我們錯過了什麼重要的事情嗎？如果是這樣，我們很樂意聽到它。在下面的評論中告訴我們您的WordPress加速技巧。