WordPress 頁面速度優化終極指南

按照本指南，您將學習大幅加快 WordPress 網站速度的所有技術。 以下是在 WordPress 中擁有出色的頁面速度加載時間對您的業務有益的最重要原因：用戶不會放棄您的網站，他們會在那里花費更多的時間和金錢，並且搜索引擎會在搜索結果中更好地排名您的網站。 準備好？

介紹

在頁面加載時間方面，互聯網用戶沒有太多耐心。 我們單擊鏈接或輸入 URL，然後等待一、二、三，僅此而已。 谷歌統計數據表明，50% 的用戶希望移動網站在 2 秒內加載，如果頁面加載時間超過 3 秒，53% 的用戶可能會放棄該頁面。 如果您考慮到移動設備上主頁的平均加載時間為 19 秒（在 3G 網絡上），那麼這是一個非常短的時間。 計算機上的加載時間更快，平均加載時間為 5 秒，但這仍然太長了。

以桌面網站基準作為參考不再是藉口。 對於當今的大多數網站來說，大部分流量來自移動設備。 在本文中，我們將全面了解 WordPress 網站頁面速度優化的最新技術。 遵循本指南，您將能夠加速 WordPress 網站，大大減少移動和桌面加載時間，從而使其更加用戶友好。

如果您沒有 WordPress 網站，請不要關閉該指南。 本分步指南中介紹的大多數速度優化技術可應用於任何類型的網站。

如果您的網站在構建時考慮到了盈利，無論是在線電子商務商店還是銷售在線/離線服務，錯過潛在客戶絕不是一件好事。 你基本上把錢留在了桌子上。 提高頁面速度應該會對您的收入產生積極影響。 有趣的事實：奧巴馬籌款活動通過優化網站並將頁面加載時間從 5 秒減少到 2 秒，將捐贈轉化率提高了 14%。

作為網站所有者或開發者，我們希望我們的訪問者獲得最佳體驗。 我們創建具有出色功能的漂亮網站，但我們通常忘記快速網站的重要性。 一個快速的網站與我們的訪問者建立信任，它增加了訪問者在我們頁面上停留更長時間的機會，因此他們可能會花費更多。 另一方面，如果我們的網站速度很慢，訪問者可能會放棄，他們甚至不會看到我們很棒的網站，以及我們同樣很棒的報價。

如果上面的理由不夠有說服力，我還有一個。 谷歌和其他搜索引擎 (SE) 透露，網站速度較慢會降低您的搜索引擎排名，使您的訪問者更少。 因此，擁有一個快速的網站意味著谷歌會更喜歡你，這可以極大地改變你的 SE 排名，對你有利。

當然，加載時間會因幾個原因而有所不同，例如，訪問者的互聯網速度、訪問者的位置以及我們網站的“沉重”或臃腫程度。 對於訪問者的網速我們無能為力，但我們可以照顧其他方面並改善每個人的體驗。 在本指南中，我們將了解如何優化我們的 WordPress 網站以提高速度，使其快速而精簡，讓我們開始吧！

目錄

• 基礎
  • WordPress 託管
    • 共享主機
    • 託管主機
    • VPS 或專用服務器
  • WordPress 主題
  • WordPress 插件
• WordPress頁面速度優化步驟
  • 頁面速度工具
    • 谷歌 PageSpeed 見解
    • GTMetrix
    • Pingdom 網站速度測試
    • 網頁測試
  • 圖像優化
    • 圖像優化小指南
    • Google PageSpeed 優化圖像
    • 其他圖像改進
    • 案例研究改進
  • 瀏覽器緩存
  • 資源壓縮（Gzip 或 Deflate）
  • 刪除不需要的 JS 或 CSS 文件
  • 在首屏內容中呈現阻止 JavaScript 和 CSS
  • 服務器端緩存
    • WP Rocket（服務器端緩存插件）
  • 內容交付網絡
    • Cloudflare
• 最終結果
• 結論

基礎

為了使您的網站盡可能快，我們必須在良好的基礎上構建它。 就像蓋房子一樣，你不想把它建在流沙上，一開始就遇到問題。 你想把它建立在堅實的基礎上，所以它會持續很長時間而沒有任何問題。 要檢查的三個主要事項是：

• 託管
• WordPress 主題
• WordPress 插件

WordPress 託管

託管是您的 WordPress 網站的基礎，因此是一個至關重要的組件，即使您已經擁有一個託管，也不應忽視這一點。 切換到更好的託管服務提供商將加快您的 WordPress 加載時間長達幾秒鐘。

選擇正確的網絡主機很重要，您不應根據主機價格做出決定。 通常，價格低，性能低，這是我們想要避免的。 讓我們看看可用的託管選項並解釋它們之間的區別。

共享主機

這是最普遍的託管解決方案，因為它很便宜。 但正如我們所說，價格低，性能低。 在共享主機上，一台物理服務器上有數千個帳戶，這意味著服務器資源在這些主機帳戶創建的所有網站之間共享。

想像一個大披薩（嗯？...），共享主機上的每個網站都得到一個非常小的一塊。 但是因為您的網站有很多訪問者，所以它需要更多的披薩！ 它仍然很餓，但是沒有比薩餅了:(，因為其他網站也很餓……

如果只得到一小塊披薩還不夠糟糕，那麼潛在的安全風險可能會使共享託管情況變得更糟。 共享主機上受感染的網站可能會導致整個服務器的速度和性能問題，並危及您的 WordPress 網站。

共享主機上的服務器配置非常有限，您沒有足夠的喘息空間來根據自己的喜好對其進行配置。 服務器已預先配置為特定的、通常非常通用的設置，它應該可以毫無問題地運行 WordPress。 稍後會出現問題，以內存不足或 PHP 設置受限的形式，插件需要正常運行。

我真的不能為任何商業網站推薦共享主機，但如果我不得不這樣做，我不得不說，它最適合流量非常低的網站。

託管主機

這是共享主機的一次重大升級，因為您的網站獲得了更大的比薩餅（整片比薩餅，是的！），但成本更高。

託管主機上的服務器人口較少，這將為您的站點轉化為更多的服務器資源。 這些服務器通常經過優化以盡可能順利地運行 WordPress，它們具有更多的內存、處理能力和緩存系統。

這些託管託管服務器的硬件和軟件安裝和配置由託管公司完成（因此稱為“託管”）。 其他服務，例如備份、負載平衡器、災難恢復和安全檢查/預防，也可以成為託管託管的一部分，具體取決於託管公司的報價。

對於中低流量網站，建議使用託管 WordPress 託管。

VPS 或專用服務器

如果我們堅持披薩的類比，使用 VPS（虛擬私人服務器）你會得到幾片披薩，但不是整個披薩，而使用專用服務器，你會得到整個披薩。

這意味著，使用專用服務器，您可以控制整個服務器及其所有資源，而使用 VPS，您可以獲得服務器的一部分，因為您仍然與其他人共享物理服務器機器。 當談到 WordPress 的頁面速度優化時，在 VPS 或專用服務器上設置 WordPress 時沒有服務器端限制。 您確切地知道有多少資源可用於您的網站，並且可以根據自己的喜好對其進行配置。 您可以在標準託管服務提供商支持它們之前實現尖端功能（這可能落後於服務器軟件技術數年）。

這兩種選擇都提供了更大的控制權和資源，但它們的價格也更高，並且需要更多的技能來設置和長期維護它們。 VPS/專用服務器也可以管理，因此您無需成為服務器專家即可使用。 它們適用於流量大的網站。

如果您不確定要使用哪個託管，我建議使用託管 WordPress 託管選項，如果需要，它還應該能夠擴展（從服務器分配更多資源）。

現在每個像樣的主機都提供的免費網站優化是將 PHP 版本升級到 7.x。 如果您的 WordPress 網站在低於 7 的 PHP 上運行，例如 5.6 或更早版本，請聯繫您的託管支持並要求他們將其更新到最新的穩定版本。 如果您正在尋找新的主機，您可以詢問他們的支持，如果他們有 PHP 版本 7.x。 他們都應該回答“是”，但如果他們沒有使用 PHP 7.x 的選項，那麼我建議遠離他們。 與舊版本相比，PHP 7 在速度和性能方面有了很大的改進，而且很容易切換到它，所以要好好利用它。

一個好的託管選擇將為您節省很多痛苦，如果您遇到問題，一個好的客戶支持應該能夠幫助您，所以我還要記住選擇一個提供良好支持的主機. 您可以利用一個快速技巧：向他們詢問購買前的問題並監控他們的響應時間、態度和專業水平。

WordPress 主題

當我們為我們的網站選擇 WordPress 主題時，我們總是從主題的設計開始，這沒關係。 我們應該首先選擇一些我們喜歡的主題，因為我們希望我們的網站很棒，而出色的設計是訪問者看到的第一件事。 第二件事可能是主題的功能。 主題或主題推薦的插件是否提供了我們想要的功能？ 如果是這樣，那就太好了！ 我們在做生意！ 我們幾乎總是忘記檢查主題加載的速度。

我們可以測試主題演示頁面的加載時間，我們將很快看到主題是否針對速度進行了優化。 我們將在下面的部分中檢查要使用哪些頁面速度工具以及如何使用它們，但現在，我只想讓您在購買前了解主題驗證的這個額外步驟。 當然，演示頁面的加載時間可能會有所改善，所以如果您沒有獲得滿分，請不要擔心，沒有 WordPress 主題會獲得 100% 的滿分，除非它的內容很少在其演示頁面上。 根據經驗，您應該尋找不在紅色數字中的主題（在頁面速度工具上得分 50 或更低）。

它歸結為主題設計和功能與主題速度之間的良好平衡。 例如，一個帶有少量文本的空 WordPress 主題加載速度會非常快，但是一個具有很多功能（大部分您可能不需要）、帶有大量多媒體內容的臃腫主題加載速度會慢得多。 在選擇一個好的和高性能的 WordPress 主題時，達到那個最佳點是目標。

WordPress 插件

我經常看到一個問題是：“有多少插件太多了？”。 這不是WordPress插件數量的問題，而是代碼質量和插件對系統的影響。 您可以擁有 50 多個活動插件，每個插件負責一個小的特定功能（具有良好的代碼）並且該站點將運行正常。 另一方面，您可以擁有 5 個活動插件，其中一個可能會阻塞您的系統，從而使您的 WordPress 變慢。

查看每個插件的代碼是一個好主意，但“沒有人有時間去做”，而且您需要良好的編程知識才能這樣做。 如果你真的走那條路，需要注意的是插件將許多外部資源排入隊列，發出大量 HTTP 請求，進行不必要的（未優化的）數據庫查詢等等（基本上任何會減慢 WordPress 網站速度的東西，背後沒有正當理由）。

我建議不要安裝和激活您認為需要的每個插件。

首先想一想，你的網站真的需要這個附加功能嗎？ 例如，如果您需要一個按鈕簡碼，請檢查您的主題文檔，也許主題有一個簡碼，您不需要安裝和激活整個簡碼捆綁插件，只需使用單個按鈕簡碼。 這是一個簡單的例子，但我希望您在安裝和激活新插件之前三思。 每個未經驗證的插件都可能使您的網站變得更重並因此變慢，而且如果插件編碼不當或未維護，還可能導致安全漏洞。

最後，在選擇插件時，您可以利用的一件好事是大型 WordPress 全球共享，因此是一個龐大的社區。 由於缺乏編碼知識，一個好的經驗法則是堅持使用具有大量活躍安裝、良好平均評分和積極評價的流行插件。 WordPressers 同行將使您的選擇變得更加容易！

WordPress頁面速度優化步驟

在我們開始優化之前，我想提幾點。

首先，您應該創建 WordPress 網站的備份，這裡是有關如何使用 WordPress 插件執行此操作的指南。 安全總比後悔好！

其次，我警告您不要期望我們將在指南中使用的頁面速度工具中的 100/100 分數。 在某些網站上追求 100/100 分數並不是一個好主意，甚至是不可能的。 這完全取決於您的網站顯示的內容類型。 如果一個網站只有一點文字和一張圖片，那麼當然，滿分是完全可能的。 但如果你的頁面很長，有很多多媒體內容和其他 3rd 方應用程序集成，如穀歌地圖等，那麼 100 分不在你的視線範圍內，你也不應該追求它。

為什麼選擇 100/100 不是一個好主意？ 如果您遵循頁面速度工具的說明並按照他們所說的那樣優化所有內容，那麼您的網站可能無法正常運行。 如果將所有阻塞的 JS 或 CSS 文件移動到頁腳，則會出現 CSS 閃爍（無樣式的內容會首先出現，當 CSS 加載時，網站會“閃爍”到位），JS 代碼也會發生同樣的情況，這將在 JS 代碼加載後修改任何 DOM 元素。

如果您盲目地遵循說明並不斷優化您的 WordPress 網站以獲得更好的加載時間，那麼您可能會破壞您的網站，只是為了獲得滿分。 完美的頁面速度分數只是一個數字，如果您的訪問者最終訪問一個損壞的網站，這實際上並不重要。 我們必須尋找頁面速度和用戶體驗的平衡點。

為了演示 WordPress 頁面速度優化，我們將使用我的共享主機帳戶和我們的醫學 WordPress 主題（帶有主題推薦插件）。 是的，是的，我知道我基本上說不要使用共享主機，但我們會看到它的能力和限制是什麼，另外這只是一個頁面速度優化測試，而不是一個實際的商業 WordPress 網站

我已經安裝了最新版本的 WordPress、MedicPress 主題、所有主題推薦的插件，並且我已經導入了演示內容。 這是我們測試站點的起點。

頁面速度工具

頁面速度優化可能很難，但值得慶幸的是，有一些在線工具可以讓我們的生活更輕鬆，並建議我們做什麼，以提高我們網站的速度。

優化 WordPress 速度的第一條規則是：始終衡量！

在每個優化步驟之後運行工具（或至少其中一個），我們將在下面的部分中查看這些工具，並跟踪改進。 通過這種方式，您將知道哪些任務帶來了最大的改進。 您還應該多次運行測試，以查看真正的平均加載時間。

頁面加載方式不同，具體取決於託管服務器所在的位置。 例如，如果您的服務器位於北美，而訪問者來自歐洲，那麼對於他來說，頁面加載速度會比加拿大訪問者慢。 這個問題可以通過 CDN（內容交付網絡）來解決，但我們稍後會在本文中討論這個問題。 現在，我只想指出，這個問題存在於世界各地的訪問者以及頁面速度優化工具中。 一些工具還允許您從不同位置執行測試，因此您可以了解這如何影響加載時間。

我們將看到的頁面速度工具是：

• 谷歌 PageSpeed 見解
• GTmetrix
• Pingdom 網站速度測試
• 網頁測試

還有其他工具，但這些是最受歡迎的工具，我們會堅持使用它們。

谷歌 PageSpeed 見解

從這個工具的標題可以看出，這是谷歌的產品。 除了分數（分為桌面版和移動版）以及如何改善頁面加載時間的有用說明之外，我們還可以得出關於 Google 喜歡在網站上看到的內容的結論。 它希望在網站上優化哪些內容以在搜索引擎結果中排名良好。

如果您有任何未優化的圖像或資源文件（JS 或 CSS），它將生成一個 zip 文件及其優化的對應文件，您可以在服務器上替換它。 很整潔，對吧？ 稍後我們將研究圖像和代碼優化，只要知道 Google PageSpeed 可以幫助您。

Google PageSpeed Insights 不像其他工具那樣有很多詳細的信息，但它是一個很好的起點，它涵蓋了頁面速度優化的所有重要方面。 它列出了最能改善您的網站的步驟。

我已經使用我們測試站點的 URL 運行了這個工具，我在台式機上得到了 71 分，在移動設備上得到了 67 分，所以還有改進的餘地。 可能的優化建議列表包括：

• 啟用壓縮（使用 gzip 或 deflate 壓縮資源），
• 優化圖像，
• 減少服務器響應時間，
• 消除首屏內容中的渲染阻塞 JavaScript 和 CSS，
• 縮小 JavaScript。

GTmetrix

此工具為您提供有關哪些內容已優化和哪些未優化的更詳細信息。 每個優化細節都列出並以 0-100 的等級進行評分。 該列表按重要性排序，因此如果您從上到下跟踪任務並優化沒有 100% 分數的任務，您將走上一條盡快加快 WordPress 網站速度的好方法。

使用 PageSpeed 和 YSlow 測試工具，GTmetrix 為您的頁面生成分數並顯示需要改進的任務。 該工具的一個不錯的功能是瀑布報告，它將以圖形方式表示您的網站是如何加載的，您可以更快地發現瓶頸。 在下圖中，您可以看到我的慢速共享主機需要 1.13 秒才能響應第一個信息。 這太長了，但我們將能夠改進它。

您還可以從全球 7 個不同的位置測試您的頁面，這很好，也是測試的重要內容，我們將在本文後面看到。

我在我們的測試站點上運行了 GTmetrix 工具（位置：加拿大溫哥華），PageSpeed 得分為 77，YSlow 得分為 71。使用此工具，我們還可以獲得以下有用信息：

• 滿載時間：3.1s，
• 總頁面大小：803KB
• 請求：54

我最喜歡 GTmetrix 工具，因為您可以在一個地方獲得大量相關信息。 在本指南中，我們將主要使用 GTmetrix 工具來衡量我們的優化進度。

Pingdom 網站速度測試

Pingdom 是另一個工具，它顯示的優化信息略有不同。 您將獲得與 GTmetrix 工具相同的基本匯總數據（沒有 YSlow 分數）。 使用 Pingdom，您可以選擇在 4 個不同位置測試頁面速度。 每個位置的結果都不同，這表明服務器位置很重要，但我們也將能夠改進這一點（本文稍後將使用 CDN）。 我們將使用 Pingdom 工具來測試 4 個可用位置的頁面加載時間，因為 Pingdom 測試完成得更快。

Pingdom 還顯示一些有趣的表格，如內容大小或請求數量，按內容類型或域過濾，它還有一個瀑布報告。

網頁測試

WebPageTest 工具比以前的工具具有更多的配置選項。 它有更多位置可供選擇，可以選擇互聯網速度，您可以啟用/禁用一些瀏覽器選項，並且可以測試特定設備。

這是一個很好的工具，它會為每次運行顯示詳細的瀑布報告（默認情況下它會運行 3 次，但您可以在設置中更改它），它會為每個速度優化因素顯示 A 到 F 等級：

• 第一個字節時間（響應時間），
• 啟用保活，
• 壓縮傳輸（gzip），
• 壓縮圖像，
• 緩存靜態內容，
• 有效利用 CDN。

您可以通過檢查所有結果選項卡來了解詳細信息，您會在其中找到很多有用的信息。 如果我需要詳細報告或需要測試他們網站上可用的位置，我會使用此工具，否則我認為 GTmetrix 有更簡潔的信息。

我為我們的測試站點運行了這個工具。 您可以在下面的屏幕截圖中看到結果：

我們查看了更流行的頁面速度工具，並進行了初始頁面速度測試，所以現在我們終於準備好開始優化我們的 WordPress 網站了。 作為參考，這些是我們將用於衡量我們的速度優化進度的頁面速度工具的起點結果：

• 谷歌 PageSpeed 見解
  • 手機：67
  • 台式機：71
• GTmetrix
  • 頁面速度：77
  • 慢速：71

圖像優化

這可能是網站性能最被忽視的方面，同時它可以為您的網站速度帶來最大的提升。 如果您在將圖像上傳到 WordPress 網站之前從未考慮過優化圖像，那麼這是您優化 WordPress 加載時間的第一步。

上傳大的、未優化的圖像，在你網站的一個小地方使用是一個很大的“不”。 示例：您的網站上有一個不大於 600 x 400 像素的圖片槽，並且您上傳了 1920 x 1080 像素的圖片（甚至更大！）。 現在，你重複這個錯誤幾次，你的網站會很慢。

首先要做的是將圖像調整為適當的大小。 在我們的示例中，圖像槽永遠不會大於 600 x 400 像素，因此我們應該將圖像調整為該大小。

“就這樣，工作完成了，對吧？” 不。 我們可以進一步改善形象。 有很多工具可以優化（壓縮）圖像而不損失其質量（我們的眼睛無法使用這些工具檢測到質量損失）。 這也將大大減少圖像文件的大小，使其加載速度更快。

圖像壓縮可以手動完成，也可以使用 WordPress 插件完成。 我的同事 Marko 為圖像優化寫了一個非凡的指南，因此我們將使用從他的文章中獲得的知識，并快速了解可用於優化圖像的技術。

圖像優化小指南

選擇正確的圖像格式——在線使用最流行的圖像格式是 JPEG 和 PNG。 通過選擇正確的圖像格式，您可以節省很多圖像文件大小（Marko 在他的文章中節省了 45%）。 你應該使用：

• .jpg格式的照片、帶有漸變的圖像和具有數百萬種顏色的圖像。
• 具有有限顏色（徽標）的圖像和具有透明度的圖像的.png格式。

調整圖片大小– 正如我上面提到的，在將圖片上傳到 WordPress 網站之前，您應該始終調整圖片大小。 首先，檢查您將使用圖像的空間有多大，並相應地調整它的大小。 您可以使用圖像處理程序（如 GIMP 或 Photoshop）調整圖像大小。

壓縮你的圖像——這可以通過在線圖像壓縮工具或 WordPress 插件來完成：

在線壓縮工具：Marko 推薦使用 Optimizilla 在線工具。 只需將您的圖像上傳到 Optimizilla 應用程序，一旦該過程完成，下載優化的圖像，然後您應該將其上傳到您的 WordPress 網站。 這聽起來有點乏味，所以當然有一個 WordPress 插件，可以簡化這個過程。

WP 圖像壓縮插件：Marko 再次測試了最流行的圖像壓縮插件並宣布獲勝：ShortPixel Image Optimizer。 安裝插件後，您必須請求 API 密鑰才能使用插件（一個非常簡單的過程）。 該插件的默認設置非常好，因此您無需進行任何設置，只需轉到Media -> Bulk ShortPixel並單擊“開始優化”按鈕。 任何新上傳的圖像也將被優化。 注意：此插件的免費版本僅允許每月 100 次圖像優化，如果您需要更多，則必須切換到他們的付費計劃。 我們希望我們的客戶能夠使用最好的工具，因此我們與 ShortPixel 合作，現在我們的ProteusClub 成員還可以獲得 1,000 積分，可免費使用 ShortPixel WordPress 插件。

最後，我不能推薦您閱讀有關 WordPress 圖像優化的整篇文章。

Google PageSpeed 優化圖像

這是關於如何優化 WordPress 網站上現有圖像的另一種方法。 如果您按照上述步驟，在圖像優化迷你指南部分，那麼您可能已經優化了圖像，因此 Google PageSpeed 不會為您提供任何圖像。 做得好！ 您仍然可以閱讀本節以供參考

我在 Google PageSpeed 工具介紹中提到，Google 會生成一個 zip 文件，其中包含可在您的網站上使用的優化文件。 您可以通過單擊此鏈接下載 zip 文件：

在這個 zip 文件中，您有一個名為image的文件夾，其中包含優化的圖像。 您可以通過 FTP 或您的託管文件上傳器上傳它們。 替換/覆蓋正確上傳文件夾（.../wp-content/uploads/...）中的圖像。 之後，您還應該在 WordPress 網站中生成這些圖像的較小版本（縮略圖）。 您可以使用 Regenerate Thumbnails 插件來做到這一點。

其他圖像改進

在本節中，我們將看到一些關於圖像的進一步改進，我們可以利用這些改進來獲得一些額外的性能。

延遲加載圖像

延遲加載是一種加載圖像的技術，其中圖像是異步加載的。 不在首屏的圖像不會在頁面加載時加載（它們在需要時甚至在需要時才加載）。 這意味著，可以在頁面頂部看到的圖像被加載，而其他圖像（未看到）在頁面加載後或用戶向下滾動頁面時（按需）加載。 如果您有一個包含許多圖像的長頁面，則可以使用此技術節省大量初始頁面加載時間。

可以使用一些自定義代碼或 WP 插件來實現延遲加載。 稍後我們將使用 WP Rocket 緩存插件，它也具有延遲加載功能。

圖片盜鏈

什麼是盜鏈？ 它正在顯示託管在另一台服務器上的圖像。 例如，如果您有一個非常受歡迎的帖子，並且在該帖子中，您有一個很好的圖像。 訪問者（小偷）可能會復製圖像源 URL 並在他自己的站點上使用它。 這意味著，將從您的服務器請求和提供圖像。 將小偷乘以 100，您的服務器必須響應數千個外部請求，這可能會降低您的服務器速度。

這不是直接的頁面速度優化，而是服務器優化。 您可以使用 .htaccess 文件中的一些代碼解決盜鏈問題。 您可以更進一步（有點邪惡）並用另一個可能不是那麼好的圖像替換被盜的圖像:)。 這也可以在 .htaccess 文件中完成。 在您的服務器上打開您的 .htaccess 文件並將此代碼添加到其中。 將your-website.com替換為您的域，將google.com替換為您希望允許訪問您的圖像並替換 http://replacing-stolen-image-url-goes-here.jpg 的任何其他域帶有您要為任何被盜圖像顯示的圖像 URL。

 RewriteEngine on RewriteCond %{HTTP_REFERER} !^$ RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?your-website.com [NC] RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?google.com [NC] RewriteRule \.(jpg|jpeg|png|gif)$ http://replacing-stolen-image-url-goes-here.jpg [NC,R,L]

如果您不想用自定義圖像替換被盜圖像，請使用此代碼。 這將禁用他們網站上的圖像：

 RewriteEngine on RewriteCond %{HTTP_REFERER} !^$ RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?your-website.com [NC] RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?google.com [NC] RewriteRule \.(jpg|jpeg|png|gif)$ - [NC,F,L]

案例研究改進

在優化圖像後，讓我們看看到目前為止我們在測試站點上取得的進展。 如您所知，我已經為我們的醫學主題導入了演示數據，我們將其用作我們的測試站點。 這些演示圖像使用了正確的文件格式，並且它們的大小已經正確，所以我可以跳過這兩個步驟。 如果我要上傳新圖片，我不會跳過它們！

所以，我已經安裝了 ShortPixel 插件並運行了批量優化器。 該插件報告平均圖像優化為 38%。 那太棒了！

我已經運行了 PageSpeed Insights 工具，Google 指出某些圖像可以進一步壓縮，所以我按照自己的建議，使用 Google 為我準備的圖像，然後通過 FTP 將它們上傳到我的服務器。

圖像排序後，頁面速度工具的結果是：

• 谷歌 PageSpeed 見解
  • 手機：72
  • 台式機：77
• GTmetrix
  • 頁面速度：81
  • 慢速：71

不是很大的改進，因為演示數據中使用的圖像已經非常優化，但我們仍然離我們的目標更近了一步。 如果您的網站上有未優化的圖像，那麼此圖像優化步驟將為您帶來巨大的分數增加並降低頁面加載時間。

瀏覽器緩存

當用戶通過瀏覽器訪問您的網站時，它必須從您的服務器下載所有資源（HTML、圖像、JS、CSS……），以便為訪問者顯示該網站。 當同一用戶訪問您網站上的另一個頁面時，CSS 和 JS 文件通常保持不變，但如果您沒有適當的服務器配置，瀏覽器可能仍會再次從您的服務器下載它們。

應在您的服務器上設置適當的緩存標頭和到期日期，以允許將靜態資源（JS、CSS 和其他文件）存儲在瀏覽器的緩存中。 這極大地提高了回訪者或查看您網站上多個頁面的訪問者的性能。

通常，託管服務器已經配置好了。 If the page speed optimization tools report that you are missing the “Leverage browser caching” optimization or something like that, then it's best to contact your hosting company and let them know that you want to set-up browser caching for your site. They will be able to sort that out for you or at least point you to the right direction on how to do that yourself.

If you want to do things yourself, then you have to know that these browser caching settings vary, depending on the server type your hosting company is using. A good starting point for Apache servers is the .htaccess file of the HTML5 Boilerplate project (check out the “Expires headers” section). An nginx configuration is available as well.

My shared hosting account has browser caching already configured, so there is nothing for us to do on our test site.

Resource Compression (Gzip or Deflate)

Files sent from your server (HTML, JS, CSS, …) to your visitors can be compressed, so that they can be transferred faster, which improves your page speed. This can be done by enabling Gzip or Deflate compression on your server.

You can contact your hosting support and ask them, if they can enable resource compression for your site or you can configure it yourself, but be sure you know which server type your hosting is using. We can again look at the HTML5 Boilerplate project for some tips, they have default server configs for each of the major server types. For example, my hosting is using Apache server, so I found this compression config. I've copied the content of this config, I've located the .htaccess file for my WordPress site via the FTP (it's in the root of your WP installation) and I copied it at the end of the file.

I've re-run the page speed tools, after I've enabled the resource compression for my WordPress site and here are the results:

• 谷歌 PageSpeed 見解
  • Mobile: 83
  • Desktop: 90
• GTmetrix
  • PageSpeed: 96
  • YSlow: 82

As you can see, we've improved our scores by a fair amount and all we did, was enable the resource compression, which did not take a lot of time. By compressing resources, we change the total page size from 803KB to 476KB, which is awesome! We made another step towards an optimized site, so let's continue.

Remove unneeded JS or CSS files

If you are using plugins, which include JS or CSS files on all your pages and you actually are not using the plugin features on those pages, then it's best to remove them. This can be done with custom code in your child theme, but I would recommend that you use a plugin for that. It's much easier!

The plugin that will help us do that is WP Asset CleanUp. After you install and activate this plugin, go and edit your home page. Home pages are usually the “heavier” pages, so we will look at it for our example, but you can do that for other pages as well.

Under the page content editor, you will see a section called WP Asset CleanUp . This section will list all CSS and JS files that are included on your front page. Now, your job is to find out, which of these files are not needed on your WordPress front page.

For example, in our test site, we are using the Contact Form 7 plugin, but we are only using the contact form on our “Contact Us” page, so we can safely remove (unload) its CSS and JS files from our home page. I can do the same with WooCommerce assets, since we are not using them on our home page as well. You should look at each asset in the list and check, if you can unload it. Watch out for the files with the red exclamation icon, you should probably never unload these, since they are core WordPress files and they are needed for the site to work properly. This is how my home page Assets CleanUp settings looks like:

I was able to safely remove 11 assets, which will save 11 resource requests when a page loads and that will improve the page speed.

Re-run of page speed test tools showed, that Google PageSpeed Insights score did not change (because it also did not list this as a recommended optimization), but the GTmetrix score did improve:

• 谷歌 PageSpeed 見解
  • Mobile: 83
  • Desktop: 90
• GTmetrix
  • PageSpeed: 97
  • YSlow: 86

Our site also loads faster, it now needs 2.7 seconds to load the whole site (in the beginning it took 3.1 seconds). We are improving the WordPress site speed slowly but surely. Bear in mind, I'm using one of our WordPress themes for the test, which are built from the ground up to be performing out of the box. If you're using some other WordPress theme, where the author didn't put any efforts to optimize it for speed, your improved loading speed results will most probably be much greater at this point.

With removing unneeded JS and CSS files from our home page, we improved our scores, load time, number of request and the total page size as well. 做得好！

Render-blocking JavaScript and CSS in above-the-fold content

One of the optimizations that Google PageSpeed Insights suggests is also: “Eliminate render-blocking JavaScript and CSS in above-the-fold content”. 這是一個棘手的問題。 Remember when I said, that it's not good to chase a perfect score in the page speed tools? This is one of the reasons for that.

If we look at our example, the Google tool suggests that the Page Builder front-flex.css should be deferred or loaded asynchronously. We are using the Page Builder by SiteOrigin plugin for building content in our pages. So, if this file is responsible for making our layout of the page look good, then I might not respect Google suggestion and simply ignore it.

“But why would you disrespect Google? 你怎麼敢！” Well, this is only a tool and it gives you suggestions on what to do, but it does not know, if implementing some of these changes will break your site or ruin good user experience (UX) for your visitors. For example, if the tools had suggested that we load the style.css file with all the theme styles asynchronously, then it would have created the FOUC: Flash of unstyled content:

This is a bad UX, so I would ignore the suggestion from the tool and keep a good UX instead of improving our score. After all, Google is also using other factors it can gather from your website to rank it in the search results and user experience is one of them. When optimizing the website for speed, don't follow the recommendations blindly and forget about all the other aspects and goals your WordPress website has.

If the files that the tool suggests to be loaded asynchronously are valid candidates and they don't break anything, then of course we can implement that change. The best way is to just try to asynchronously load each suggested file and see, if the page still loads ok. Don't forget to reload the page without browser cache, so that a fresh copy of the page loads. You can do that by hard refreshing your site.

We will look at how to load files asynchronously in the WP Rocket plugin section below. There are other standalone plugins that offer this functionality, but since the WP Rocket has it build in, we don't need to pollute our WP installation with more plugins.

Server Side Caching

We've already talked about browser cache, but now we also have to take care of the server side cache. To understand server side caching we have to know the basics of how WordPress works, so let's look at that first.

When a visitor opens a WordPress page, the following things happen (basic explanation):

1. Server receives a page request.
2. WordPress PHP code begins to execute.
3. WordPress access the database to get the information it needs to build the requested page.
4. WordPress produces the HTML.
5. Server responds with the HTML for the browser to display it to the visitor.

These 5 steps have to be repeated for each page view, for each visitor. That's a lot of repetitive work for content that stays the same for each visitor (if your site is displaying mostly static content, which majority of websites is).

Server side caching eliminates pretty much all the server's hard work. It removes the need for repeating steps 2,3 and 4. So, when we enable server side caching, the process of a page request looks like this:

1. Server receives a page request.
2. Server retrieves the page HTML from the cache (if a cached version is available).
3. Server responds with the HTML for the browser to display it to the visitor.

As you can see, the hard work of running the WordPress code and accessing the database is bypassed, which means that the page loading time should be much faster.

If we look at the Google PageSpeed Insights tool suggestions, we will spot the “Reduce server response time” task. The tool says that our server responded in 0.98 seconds, which is not good. The slow shared hosting I'm using is definitely to blame for some chunk of that 1 second response time, but we'll be able to shorten it with server side caching.

Each page cache is usually saved with an expiration time of 24 hours, but that setting can be changed. This means that instead of thousands of page requests running the whole WordPress HTML building process, it will only be run once a day, to generate that cached page and the server will serve that cached page to other visitors. So, not only the page will be quicker, but the server will also have to do less work.

If you are updating a page in WordPress and an old cached version of the page is still available on your server, then you would have to clear that cache manually (usually with the click of a button) or some tools would do that for you automatically.

Some hosting companies already have a server side caching in place for their users, but this feature is usually available for managed WordPress hosting packages. So, before you follow instructions below, on how to setup server side caching, you should make sure that your server is not doing that for you already.

We will look at how to setup the WP Rocket plugin to enable server side caching and other features that it has (like lazy loading images, loading assets asynchronously, minification of JS and CSS files and much more). WP Rocket is a premium (paid) plugin, but I believe it's worth the investment. If you don't agree with me, that's fine WP Super Cache is a good free alternative, but it does not have the same extra features as WP Rocket and it's a little bit more cumbersome to setup.

WP Rocket (server side caching plugin)

As soon as we install and activate the WP Rocket plugin it will have some basic features enabled out of the box:

• Caching of all the pages for quick viewing.
• Decrease bandwidth usage with our GZIP compression.
• Management of the headers (expires, etags…).

The WP Rocket plugin default settings are a good starting point.

I've run the page speed tools a couple of times, so that they picked up the cached version of the site and these are the new results:

• Google page speed insights
  • Mobile: 91
  • Desktop: 97
• GTmetrix
  • PageSpeed: 97
  • YSlow: 87

The Google PageSpeed Insights tool no longer displays the “Reduce server response time” optimization suggestion, because we reduced it from 1 second to 121ms, that's a 88% improvement in server response time, just by activating the WP Rocket plugin! With this improvement, our fully loaded time is now 1.9 seconds, but we are not stopping here

讓我們看看 WP Rocket 插件必須提供的設置。 WP Rocket 在您的頂部 WP 管理菜單欄中有一個不錯的快捷菜單。 從那裡，您可以訪問設置頁面，清除緩存並訪問有關此插件的其他有用信息。

在我們繼續嘗試不同的 WP Rocket 設置之前，我想提一下，在您進行每次更改後，您應該在隱身/私人瀏覽器選項卡中驗證您的網站。 如果您登錄到您的 WordPress 站點，那麼您將看不到該站點的緩存版本。 在隱身瀏覽器選項卡中，您將不會登錄，並且會獲得該站點的緩存版本，因此您可以檢查它是否工作正常。

還知道啟用每個 WP Rocket 設置可能會對您的 WordPress 速度產生不同的結果甚至負面影響，具體取決於您使用的主題或插件，因此僅啟用所有 WP Rocket 設置並不是可行的方法。 您應該嘗試每個設置並使用頁面速度工具對其進行測量，以查看差異。 正如您將看到的，某些技術不會提高我們的頁面速度，因此我們不會使用它們。

清除緩存

服務器端緩存將在您激活 WP Rocket 插件後立即開始工作，所以讓我們看看如何清除它。 您可以手動清除緩存，如果您單擊 WP Rocket 快捷菜單中的菜單項“清除緩存”。 當您更新定制器設置、更改/更新小部件、類別等時，該插件還將自動清除緩存，當您更新頁面時，它會部分清除緩存。 有關何時發生自動緩存清除的更多信息，請參閱此 WP Rocket 問題。

緩存的使用壽命可以在 WP Rocket 設置的“基本”選項卡中設置。 我建議將此設置為 1 天。

預加載緩存

WP Rocket 的一個不錯的功能是“預加載緩存”，它將預加載您的主頁及其鏈接到的頁面的緩存，因此您的用戶將始終獲得頁面的緩存版本。 我可以在運行頁面速度工具之前使用此功能，並且不必多次運行這些工具來獲取緩存的版本結果。

可以在“預加載”選項卡下的設置頁面中訪問預加載緩存設置。 尋找“Preload bot”選項，在那裡你會找到一個手動和一個自動選項。 如果您啟用自動機器人選項，預加載緩存將在您每次更新或創建頁面或緩存過期時運行。 此選項會影響服務器的性能，因此如果啟用它，請密切注意性能日誌。 如果您正在更新和創建大量帖子/頁面並且您有共享主機，我建議您不要啟用此選項。 您應該只啟用手動機器人選項，這將創建另一個 WP Rocket 快捷菜單項，標題為“預加載緩存”，並且只有在您單擊它時才會預加載緩存（在您完成編輯帖子和頁面之後）。

在“預加載”設置選項卡中，您還可以找到從站點地圖預加載緩存的設置，因此您可以定義站點地圖，它將使用站點地圖中的 URL 為這些頁面預加載緩存。

延遲加載

我已經在本文的圖像優化部分解釋了延遲加載圖像，但是現在我們已經安裝了 WP Rocket，我們實際上可以啟用此功能。 轉到 WP Rocket 設置的“基本”選項卡並為圖像啟用 LazyLoad，如果您使用任何視頻或 iframe，那麼您也可以啟用它。

啟用此功能後，您應始終檢查您的站點並查看圖像的加載方式。 LazyLoad 可能會破壞您的站點佈局，或者您可能不喜歡圖像的加載方式（內容跳轉），因此請務必檢查您的頁面。 此功能非常方便，當您有很多首屏圖像時，它將幫助您減少原始頁面加載時的圖像請求數量。 在我們的測試站點上，我們只有 5 個首屏圖像，因此我們節省了 5 個圖像請求，我們的頁面加載時間現在降至 1.7 秒，而頁面速度工具的分數保持不變。 這是一個很好的指標，表明您可以通過工具不建議的某些任務來提高頁面速度。

縮小文件

我們仍然可以改進的一些 GTMetrix 建議是縮小 HTML、CSS 和 JS 文件。 因為我們的 WordPress 主題和大多數推薦的插件已經使用 JS/CSS 文件的縮小版本，並且我們在服務器上啟用了 Gzip，所以這種 WP Rocket 優化不會為我們的測試站點帶來任何重大改進，但您的情況可能是不同的。 轉到 WP Rocket 設置中的“靜態文件”選項卡，然後檢查“縮小文件”選項下的所有 3 個選項。 保存設置並在隱身/私人標籤中檢查您的網站，以便您可以查找這些選項可能給您的網站帶來的任何問題。 在我的測試 WordPress 站點中，CSS 縮小破壞了頁面構建器 flexbox css 文件排隊，因此我不得不禁用 CSS 縮小文件選項。 HTML 和 JS 選項工作正常。

我問 WP Rocket 支持可能是什麼問題，他們很好地在我的網站上調試了這個問題。 這個問題是由我的共享主機上使用的 Varnish 緩存引起的。 他們建議更改我的託管服務器上的 Varnish 配置。 我已經聯繫了我的託管支持，並且我懷疑，我無法更改共享主機上的 Varnish 配置，但如果我升級到 VPS 託管包，我將能夠。 如您所見，使用共享主機不是一個好主意

如果您在 CSS 或 JS 縮小方面遇到一些問題，您可以將導致問題的文件 URL 添加到排除的 JS 或 CSS 文件的框中。 查找導致問題的文件可能很棘手，但通常您知道哪個功能被破壞以及哪個插件負責該功能，因此您檢查您的頁面源代碼並檢查該插件包含的文件。 如果插件有多個 JS 或 CSS 文件，那麼您可以嘗試將它們添加到排除列表中，看看問題是否消失。

合併 JS 和 CSS 文件

GTmetrix 工具中的 YSlow 選項卡告訴我們“減少 HTTP 請求”。 它說我們的 WordPress 使用 9 個外部 JS 腳本，我們應該嘗試將它們組合成 1 個，並且頁面使用 4 個外部 CSS 文件，我們也應該嘗試將它們組合成 1 個文件。 如果您還記得，我們​​已經在本文的刪除不需要的 JS 或 CSS 文件部分中刪除了不需要的 JS 和 CSS 文件。

將所有 JS 和 CSS 文件合併到一個文件中並不是一個好主意，因為瀏覽器可以並行下載 6 個較小的文件，比 1-2 個大文件要快。 另一個原因是某些文件包含在 HTML 文檔的頭部，而另一些則包含在文檔的末尾，因此您必須將它們拆分為至少 2 個文件。

要使用 WP Rocket 合併文件，請轉到插件設置中的“靜態文件”選項卡並啟用合併文件下的選項。 與往常一樣，在隱身/私人瀏覽器選項卡中驗證您的網站以檢查是否存在任何問題。

在我們的例子中，WP Rocket 又出現了問題，由於上面提到的共享主機 Varnish 配置問題，所以我不得不禁用 JS 合併文件選項。

同樣，如果您對 CSS 或 JS 連接有一些問題，您可以將導致問題的文件 url 添加到排除的 JS 或 CSS 文件的框中，就像在上面的縮小步驟中一樣。

從靜態資源中刪除查詢字符串

GTMetrix 建議我們從靜態資源中刪除查詢字符串，因為某些代理服務器不會緩存帶有查詢字符串的資源。

靜態資源（通常是 JS 或 CSS 文件）中的查詢字符串是一個 URL 屬性，它標記了該文件的版本。 它看起來像這樣： ?ver=2.5.8並附加在 URL 的末尾： http ://domain.com/css/front-flex.css?ver=2.5.8

我們可以使用 WP Rocket 輕鬆刪除這些查詢字符串。 轉到插件設置的“靜態文件”選項卡並啟用“刪除查詢字符串”選項。

啟用此選項後，我們的 GTmetrix PageSpeed 分數變為 98，但頁面加載時間沒有改變。

渲染阻塞 CSS/JS

剩下的唯一 Google PageSpeed Insights 工具建議是“消除首屏內容中的渲染阻塞 JavaScript 和 CSS”。 這意味著有一些 JS 或 CSS 文件阻止了首屏內容中頁面的加載。 該工具希望我們做的是延遲或異步加載這些阻塞資源。

再一次，WP Rocket 插件來救援了。 轉到“靜態文件”選項卡並查找阻止渲染的 CSS/JS選項。 在那裡您可以啟用可以解決此問題的 JS 和 CSS 選項。 啟用 JS 選項後，將出現安全模式（推薦）選項。 此安全模式將在頁面頭部加載 jQuery 庫（WP 默認入隊庫），將其保留為阻塞文件，但不會破壞頁面上任何具有內聯 jQuery 代碼的頁面。 由於 jQuery 仍然加載在頭部，PageSpeed 工具仍然抱怨我們有一個渲染阻塞 JS 文件。

因此，如果我為我們的測試站點禁用安全模式，Google PageSpeed 工具會給我們一個滿分，移動端 100 分，桌面端 100 分。 太好了，對吧？ 並不真地！ 我們的網站仍然可以正常運行，但讓我們看看網站是如何加載的：

無樣式內容 (FOUC) 的 Flash 可以通過使用 WP Rocket 設置中的關鍵路徑 CSS選項來修復（就在渲染阻止 CSS/JS 選項下方）。 理論上，您可以添加頁面首屏部分所需的 CSS 代碼，以便在頁面加載時不會出現這種無樣式文本的閃光效果。 這比聽起來要難。 有一些工具可以為你生成這個關鍵的 CSS，但我沒有用它們取得太大的成功。

生成關鍵路徑 CSS 代碼：

1. 在您的網站上禁用 WP Rocket 插件。
2. 轉到關鍵路徑 CSS 生成器工具。
3. 輸入您的站點 URL 並運行它。
4. 複製關鍵路徑 CSS 代碼。
5. 激活 WP Rocket 插件。
6. 將 CSS 代碼粘貼到 WP Rocket 設置中的“關鍵路徑 CSS”框。
7. 檢查關鍵 CSS 代碼中是否有任何相對 URL 路徑並將其更改為絕對路徑。

這就是我們的 WordPress 測試站點現在加載的樣子：

它更好，但我仍然不喜歡它。 是的，100/100 的 Google PageSpeed 得分很棒，但總加載時間較慢，而且我們還有 2 個請求，因為我們啟用了這個渲染阻塞 CSS/JS 選項。 對我來說主要問題仍然是頁面加載的用戶體驗，所以我禁用了這個 WP Rocket 選項。

WP Rocket 絕對是每個 WordPress 網站所有者都應該使用的插件，因為它具有加速您網站的所有功能。 只需激活插件就會給您帶來巨大的提升。 必須為每個網站測試其他功能，因為每個主題和插件都可能帶來自己的問題。

我們的優化步驟快要結束了。 唯一剩下的就是為我們的網站資產使用 CDN。

內容交付網絡 (CDN)

我已經在本文中多次提到，頁面加載時間會有所不同，具體取決於服務器的位置和訪問者的位置。 例如，我們用於測試的共享託管服務器位於德克薩斯州奧斯汀（美國），在本文的 Pingdom 頁面速度工具部分的開頭，我們測試了 4 個位置。 結果如下：

• 德克薩斯州達拉斯（美國）= 1.65 秒
• 加利福尼亞州聖何塞（美國）= 2.53s
• 瑞典斯德哥爾摩（歐盟）= 3.06s
• 墨爾本 (AUS) = 5.38s

現在我們已經優化了網站，使用了本文中提到的所有步驟，我們的加載時間是：

• 德克薩斯州達拉斯（美國）= 0.63s
• 加利福尼亞州聖何塞（美國）= 0.76 秒
• 瑞典斯德哥爾摩（歐盟）= 1.21s
• 墨爾本 (AUS) = 2.24s

當我們將網站設置為使用 CDN 時，我們將使用這些時間來比較我們的 WordPress 加載時間。

我們可以看到，這些時代非常不同； 這是因為數據必須從我們的服務器位置傳輸到澳大利亞訪問者，而不是到達達拉斯的訪問者。 這就是 CDN 將幫助我們減少加載時間的地方。

CDN 是服務器代理及其數據中心的地理分佈網絡。 他們的主要目標是將您的網站內容從離訪問者最近的服務器分發給訪問者。 這意味著，您的網站靜態內容（圖像、JS、CSS ......）將由他們分佈在世界各地的服務器提供服務，從而使您的網站更快地為每個人加載。

使用 WordPress CDN 有很多好處，包括：

• 減少延遲，即距離必須經過的時間和/或延遲。
• 減少第一個字節的時間 (TTFB)，這是衡量瀏覽器在從服務器接收其第一個數據字節之前必須等待多長時間。
• 從緩存中提供內容，以加快頁面加載時間並減少託管（源）服務器的壓力。
• 在安全連接上使用 HTTP/2 以利用多路復用、並行性、服務器推送和 HPACK 壓縮。
• 使用 GZIP 或 Brotli 壓縮數據以確保更小的 HTML、樣式表和 JavaScript 文件。

如今，CDN 提供了許多其他功能，尤其是在安全部門。 他們通常提供 DDoS 保護、機器人檢測/預防等。

我們將研究一種更流行的 CDN，稱為 Cloudflare。 他們提供免費套餐，其中包括使用他們的全球 CDN，而這正是我們所需要的。

Cloudflare

首先訪問 cloudflare.com 並註冊一個新的免費帳戶。 創建帳戶後，您必須在 Cloudflare 上設置您的網站，以便它為您的靜態內容（資產）提供服務。

當您登錄到新的 Cloudflare 帳戶時，系統會要求您添加您的網站（域）以自動檢索 DNS 記錄。

輸入您的域，然後單擊“開始掃描”。 即使我使用的是子域（ speed.gregorcapuder.com ），我也只需要輸入根域： gregorcapuder.com 。 掃描部分大約需要一分鐘才能完成，與此同時，您可以觀看一段簡短的視頻，該視頻將解釋正在發生的事情。 掃描完成後，您可以單擊“繼續”按鈕。

在下一步中，您將看到 Cloudflare 可以為我們的域找到的所有 DNS 記錄。 在這裡，您必須添加任何可能丟失的記錄，因此請查看列表並檢查是否缺少某些內容。 在我們的示例中，缺少 speed 子域，因此我將其添加到列表中。 在名稱輸入中，我輸入了“速度”（我的子域的名稱），在IPv4 地址中，我輸入了與主域（gregorcapuder.com）相同的 IP 地址，然後單擊“添加記錄”。 正如您在下面的屏幕截圖中看到的那樣，我已經為我的主域以及 speed 子域啟用了 Cloudflare（由橙色雲標記，雲後面有一個箭頭）。 這意味著，在這兩個網站上，流量將由 Cloudflare 處理和保護。

完成 DNS 記錄後，您可以繼續下一步，選擇“免費網站”計劃並繼續。

為您的網站啟用 Cloudflare 的最後一步是登錄到您的域名註冊商的儀表板（您從那裡購買域名）並更改您的域名的名稱服務器。 據說，新名稱服務器最多可能需要 48 小時才能生效，但就我而言，它在 1 小時內更新。 在此期間不會有網站停機，所以不用擔心。

為您的站點更新名稱服務器後，您將看到 Cloudflare 網站的狀態更改為“活動”。

我將儀表板中的所有 Cloudflare 設置保留為默認設置，我唯一更改的是安全級別。 轉到防火牆選項卡並將“安全級別”調整為低。 那是因為我不希望我的訪問者在錯誤的攻擊者檢測上獲得“挑戰頁面”。

現在，我們設置了 Cloudflare 端，我們還應該在 WP Rocket 插件上啟用 Cloudflare 設置。

登錄到您的 WordPress 管理儀表板並轉到 WP Rocket 插件設置。 導航到“CDN”選項卡，啟用“顯示 Cloudflare 設置”選項卡並保存設置。 這將在 WP Rocket 設置中顯示一個新的“Cloudflare”選項卡，您應該打開它。 您應該在此處輸入 Cloudflare 帳戶電子郵件、域，還應該複製並粘貼 Cloudflare 全局 API 密鑰。 要檢索全局 API 密鑰，請轉到 Cloudflare 儀表板（概覽選項卡）並單擊“獲取您的 API 密鑰”鏈接。 您將在這個新頁面上看到“API 密鑰”部分，您應該單擊“全局 API 密鑰”行的“查看 API 密鑰”按鈕。 將全局 API 密鑰粘貼到 WP Rocket 設置中後，我還建議在 WP Rocket 中啟用“優化設置”選項。 保存設置，然後單擊“清除 Cloudflare 緩存”按鈕，以驗證一切正常。

現在，配置了 CDN，我們可以再次測試來自不同位置的加載時間並查看改進（Pingdom 測試）。

• 德克薩斯州達拉斯（美國）= 0.54 秒
• 加利福尼亞州聖何塞（美國）= 0.70s
• 瑞典斯德哥爾摩（歐盟）= 0.91s
• 墨爾本 (AUS) = 1.16s

正如預期的那樣，歐洲和澳大利亞的裝載時間改善最大。 我們所有的加載時間都在 1 秒左右，或者更低。 這是一個很好的加載時間！

當您測試您的網站時，不要只為一個位置運行一次頁面速度工具來測試它。 你需要測試它幾次。 當您第一次在某個位置運行該工具時，緩存文件必須首先存儲在最近的 Cloudflare 服務器上，每個後續測試都應該向您顯示緩存版本的真實加載時間。 我建議您測試 3-5 次，以獲得您的頁面從特定位置加載的平均速度。

最終結果

我們的最終頁面速度工具得分是：

• 谷歌 PageSpeed 見解
  • 手機：91
  • 台式機：97

• GTmetrix
  • 頁面速度：98
  • 慢速：91

以下是截圖：

對比一下優化前後的GTmetrix數據：

我們在各個方面都改進了我們的網站性能。 該網站加載速度更快，向用戶顯示網站所需的請求更少，佔用的帶寬更少，並且為世界各地的訪問者加載速度更快。 同時，我們將網站的所有功能和样式保持原樣。 驚人的！

最後，我們為我們完成的每個優化步驟準備了一個很好的可視化結果表示：

結論

在這個終極的 WordPress 頁面速度優化指南中，我們研究了您可以採取的更重要的步驟，以顯著提高您的網站性能。 遵循本文中的建議將使您的網站精簡和快速，這將改善您的頁面加載時間，從而改善用戶體驗。 這些改進也可能會帶來更多的錢，並幫助您節省一些服務器成本，所以這對每個人來說都是雙贏的！

我想總結這篇文章，速度不是一切，它是網站拼圖的另一塊。 我們為人類、潛在客戶建立網站，因此請始終牢記這一點。 在內容、多媒體、設計、用戶體驗和頁面速度之間找到一個很好的平衡點。 不要沉迷於頁面速度和頁面速度工具分數。 只要您改善訪問者的體驗，您的目標就會實現。

我是否錯過了任何網站優化步驟，您認為這些步驟可以顯著改善頁面加載時間？ 在下面的評論中告訴我！

如果您發現我們的文章有用並且您遵循了它的步驟，請在下面的評論中讓我知道您取得了哪些改進。