為什麼您的 WordPress 網站如此緩慢，並且是加快速度的便捷指南

已發表: 2021-08-19

我想，讓你知道，這不只是一個普通的“如何加快WordPress的”的文章，開始這個帖子。

我不會反芻任何已經可以在網上找到的東西。 我不會告訴你你應該安裝一個緩存插件，啟用壓縮，縮小你的 css/js 等等......。

畢竟，您應該已經知道如何做這些事情了。 如果沒有，您可以在數百個其他博客上找到這些通用信息。

Wordpress Tricks

相反，本文包含我在過去一個月左右實施的所有自定義/半自定義內容，以加快我自己的 WordPress 博客速度並基本上防止惡意訪問使我的服務器癱瘓。

它之所以“鮮為人知”，是因為我將要描述的技術將非常特定於您自己的博客，具體取決於您所看到的流量模式。

wpengine 注意：如果您的博客速度很慢，並且您真的不想處理加快網站速度的任何技術方面的問題，那麼您可能應該註冊 WP Engine 之類的服務。

這些人專門從事 WordPress 託管，並會確保您的博客盡可能快地運行。 但自然，這是有代價的。 如果這篇文章超出你的頭腦，你應該檢查一下:)

無論如何，在我向您解釋我如何以及為什麼對我的博客所做的事情之前，您必須了解一些關於 WordPress 和緩存的基本概念，我將在下面進行描述。

一些有趣的 WordPress 事實

假設您已經遵循了有關如何加速 WordPress 的所有指南。 你的博客感覺很活潑。 Webpagetest.org 告訴您您的博客速度快得要命。 一切都很好吧？ 不一定。

Webpage test

我曾經對我的博客有同樣的感覺。 畢竟，我遵循大多數標準加速協議。 我運行的插件很少，從人類讀者的角度來看，我的博客在正常使用下感覺非常快（廣告網絡會減慢我的博客速度，所以我最後加載廣告）。

但隨後我開始分析我的 CPU 使用率圖表，並且經常注意到儘管流量水平低到中等但服務器負載高的時期。 有時，我的服務器甚至會長時間無法使用或無響應。

請注意，我開始關注這些統計數據的唯一原因是因為不久前我在與我的博客相同的服務器上運行我的在線商店。 有時我會讓顧客抱怨商店非常慢。 當我終於進行了一些挖掘時，我發現我優化的、完全緩存的 WordPress 博客讓我的服務器癱瘓了！

故事的道德啟示？ 僅僅因為速度測試告訴您您的博客速度快並不一定意味著一切都很好。

這裡有一些關於 WordPress 和緩存插件的有趣事實，如 WP Super Cache 和 W3 Total Cache，您應該注意。

  • WordPress 404 響應很慢。 每當您的博客獲得對不存在頁面的訪問權限時，您糟糕的服務器都必須加載 WordPress，運行一堆 php 代碼，執行一堆 MySQL 查詢，然後吐出您的自定義 WordPress 404 頁面。 這是一項非常耗費資源的任務，緩存無濟於事。
  • 當 URL 中有 GET 參數時，您的緩存插件不能很好地工作。 例如，我曾經註意到每當我向我的電子郵件列表發送爆炸時，我的博客就會變得緩慢。 理論上使用靜態文件緩存，我的服務器應該幾乎立於不敗之地。

    但是因為 Aweber 在 URL 中插入了跟踪參數，所以我的文件都沒有被超級緩存。 因此，WordPress 必須生成一個全新的緩存文件（即使它已經存在），每次都將其壓縮並發送出去。 最糟糕的是，這些緩存文件只使用一次，浪費了服務器資源

  • 惡意訪問速度很慢。 由於惡意訪問默認情況下需要 WordPress 加載，因此決定向您的網站發送垃圾請求的惡意機器人或爬蟲可以很容易地關閉您的博客。
  • 您的緩存插件可能存在錯誤或與您設置博客的方式不兼容。 例如，3 年來我一直認為 WP Super Cache 是正確的，直到我開始查看我的日誌並註意到代碼中的錯誤。 由於我的設置方式，我遇到了 WP Super Cache 經常刷新我的緩存方式的問題。

我試圖用上面的要點說明的關鍵點是，每當您的博客上發生非標準訪問時，無論您如何設置 WordPress 博客，它都會佔用大量服務器資源。 正是這些類型的訪問將使您的服務器癱瘓，而不是常規流量。

檢測惡意訪問

優化您的 WordPress 博客的第一個關鍵是了解您的博客收到的流量模式。 我敢打賭 99% 的 WordPress 用戶不會這樣做。 相反，他們盲目地遵循並安裝各種插件，並假設一切正常。 別難過，我也是這樣。

所以第一步是找出到底發生了什麼。 有很多方法可以做到這一點，但最簡單的方法是使用插件 WP SuperCache 提供的調試模式。 這種模式有什麼作用？ 基本上，每次訪問由 WordPress 直接處理（資源密集型）時，它都會顯示在 WP Super Cache 日誌中。 以下是啟用此模式的方法。

WP Super Cache Log

在 WP Super Cache 插件的調試選項卡下，只需單擊“啟用調試”複選框即可！

啟用日誌記錄後，您可以單擊“日誌文件”鏈接，該鏈接將指向一個詳細說明 WordPress 流量的文件。 它看起來類似於下面的文本。

15:03:46 /?utm_source=fwisp.com supercache dir:
15:03:46 /?utm_source=fwisp.com No wp-cache file exists. Must generate a new one.
15:03:46 /?utm_source=fwisp.com In WP Cache Phase 2
15:03:46 /?utm_source=fwisp.com Setting up WordPress actions
15:03:46 /?utm_source=fwisp.com Supercache caching disabled. Only using wp-cache. Non empty GET request.
15:03:46 /?utm_source=fwisp.com USER AGENT (Mozilla/5.0 (compatible; YandexBot/3.0; +http://yandex.com/bots)) rejected. Not Caching

需要注意的重要一點是，每當您在此日誌中看到某些內容時，這都是一件壞事，因為這意味著 WordPress 必須工作。 並且因為 WordPress 是一個資源豬，你希望它做盡可能少的工作。

在日誌中尋找什麼

WP Super Cache 日誌很棒，因為它們會告訴您正在發生的一切。 但是，除非您知道要查找什麼，否則海量的信息可能會讓人不知所措。 以下是您在這些日誌中應該注意的內容。

  • 404 錯誤– 基本上這些是訪問您博客上不存在的頁面。 WordPress 處理的每個 404 訪問都會佔用大量服務器資源，因此您希望盡可能將它們扼殺在萌芽狀態
  • 一次性訪問——這些請求會導致您的服務器緩存和壓縮只使用一次的頁面（稍後會詳細介紹）
  • 奇怪的流量爆發——這些通常是機器人同時攻擊你的博客
  • 奇怪的緩存行為– 您的緩存是否在應該刷新的時候被刷新？ 在所有情況下，一切都被正確緩存了嗎？

在記錄了我的博客流量 2 週後，我發現了很多效率低下的問題，我將在下面進行描述。

機器人正在敲打我的檔案

我做的第一件事是查看我的服務器日誌，了解 CPU 負載高的時期。 然後，我在這些完全相同的時期分析了我的超級緩存日誌，看看是否有任何有趣的事情正在進行。 事實證明，每隔一天左右，一群機器人就會同時攻擊我博客的所有存檔頁面！

因為默認情況下這些存檔頁面不會被緩存，所以一堆同時訪問足以使我的服務器負載激增並使事情變得非常緩慢。 有時，它甚至導致我的服務器崩潰。

所以我仔細查看了我的 HTML 輸出，並註意到我有一堆存檔鏈接作為我的 WordPress 標題的一部分。 因此，機器人和其他網絡爬蟲會過來嘗試瀏覽檔案。

經過大量的谷歌搜索，我發現其他一些網站管理員也有類似的問題。

當我們多次看到您網站的加載問題時，代理服務器 IP 的點擊量很大，理論上這些代理正在緩存您的網站並點擊所有這些存檔鏈接。 當您的網站導致加載問題時，我們看到的許多 IP 是企業、教育和政府/軍事代理 IP，它們似乎在有人訪問網站時預取內容。

解決方案：檢查您的博客標題代碼中是否有php語句“wp_get_archives”並將其刪除。 刪除這個小片段後，我所有的存檔訪問都消失了。

機器人正在訪問不存在的文件

我注意到的第二件大事是有一堆機器人正在訪問我服務器上不存在的文件。 問題是每次發生文件訪問時，您的服務器都必須加載 WordPress，執行一堆 PHP 代碼，然後發出 404 頁面。

這個問題的解決方案是編輯 .htaccess（如果你不知道它是什麼，請谷歌這個）文件並添加以下行。

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !(robots\.txt|sitemap\.xml(\.gz)?)
RewriteCond %{REQUEST_FILENAME} \.(css|js|html|htm|rtf|rtx|svg
|svgz|txt|xsd|xsl|xml|asf|asx|wax|wmv|wmx|avi|bmp|class|divx|doc
|docx|exe|gif|gz|gzip|ico|jpg|jpeg|jpe|mdb|mid|midi|mov|qt|mp3|
m4a|mp4|m4v|mpeg|mpg|mpe|mpp|odb|odc|odf|odg|odp|ods|odt|ogg|pdf
|png|pot|pps|ppt|pptx|ra|ram|rar|swf|tar|tif|tiff|wav|wma|wri|
xla|xls|xlsx|xlt|xlw|zip)$ [NC]
重寫規則 .* – [L]

一旦將這些行插入到您的 .htaccess 文件中，您的網絡服務器將首先檢查文件是否存在。 如果沒有，它會在不加載 WordPress 的情況下發出 404 響應。

機器人正在訪問不存在的 URL

令人遺憾的是 WordPress 的編寫方式是，如果您可以訪問數據庫中不存在的文章，則您的服務器將不得不加載 WordPress，執行一堆 PHP 代碼並在發布之前執行一堆 MySQL 查找404 響應。

如果您仔細查看您的日誌，您可能會注意到某些可以在訪問 WordPress 之前排除的訪問模式。

例如，我注意到一堆機器人正在使用 URL www.mywifeequitherjob.com/some-article/www.facebook.com/like.php/...訪問我的網站。 每次，我的服務器都會加載 WordPress 並發出 404 響應。

因此，我沒有讓 WordPress 處理這些請求，而是將以下幾行添加到我的 .htaccess 文件中

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} www\.facebook\.com/plugins [NC]
重寫規則 .* 404.html [L,R=404]

在上面的幾行中，我讓我的網絡服務器在 URL 中查找“www.facebook.com/plugins”，並立即發出 404 響應而不加載 WordPress。 當您仔細閱讀日誌時，您會發現許多惡意訪問，就像我上面描述的那樣。 為每個寫一個 .htaccess 規則，這些訪問將不再加載你的服務器。

機器人正在攻擊我的評論鏈接

還記得我告訴過您緩存插件對帶有 GET 參數的 URL 的處理方式不同嗎？ 我發現有大量機器人使用“回複評論”參數集攻擊我的文章。

發生這種情況時（取決於您的緩存設置），wordpress 會加載並提供緩存/zip 文件，即使它可能再也不會被訪問。 這是一種資源浪費。

從我的日誌中獲取的示例
12:01:11 /how-to-get-more-facebook-fans-with-a-facebook-reveal-tab-or-fan-gate/?replytocom=5972 No wp-cache file exists. Must generate a new one.
12:01:11 /how-to-get-more-facebook-fans-with-a-facebook-reveal-tab-or-fan-gate/?replytocom=5972 Gzipping buffer.

解決方案是使用這些 GET 參數將所有機器人和爬蟲重定向到主文章頁面。 這是我添加到我的 .htaccess 文件中的代碼。

RewriteCond %{QUERY_STRING} 回復到com
RewriteCond %{HTTP_USER_AGENT} ^(.*)(bot|crawl|spider|slurp) [NC]
RewriteRule .* https://mywifeequitherjob.com%{REQUEST_URI}? [L]

此代碼查找“replytocom”GET 參數，然後在提供對 WordPress 的訪問權限之前從最終 URL 中刪除此參數。

爬蟲訪問帖子時沒有尾部斜杠

我不確定為什麼會這樣，但我注意到一堆網絡爬蟲似乎合法地嘗試訪問我博客上的文章，而 URL 中沒有尾隨斜線。

您可能知道也可能不知道，像http://yourblog.com/article/這樣寫的 URL 與像http://yourblog.com/article這樣寫的 URL 不同。

因此，當遇到沒有尾部斜杠的 URL 時，WordPress 必須介入，運行一堆 PHP 代碼，然後發出 301 重定向到帶有尾部斜杠的文章。 為了將 WordPress 取出圖片，您只需在 .htaccess 文件中插入以下規則即可。

# 添加尾部斜線
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_URI} !(.*)/$
RewriteCond %{QUERY_STRING} !.*=.*
重寫規則 ^(.*)$ $1/ [L,R=301]

通過添加尾部斜杠，您將 301 重定向發送到正確的 URL，然後再將其發送到 WordPress，這將節省 CPU 資源。

我在 WP Super Cache 中發現了一個錯誤

與大多數人不同，我沒有在 public_html 目錄的根目錄中安裝我的 WordPress 博客。 另外，我博客的首頁也不是我的“帖子”頁面。 當您以與我相同的方式配置博客時，WP Super Cache 中存在一個錯誤，即使您預加載緩存，您的所有緩存文件也可能過早被刪除。

我不確定插件的作者是否意識到這個問題，但基本上我發現每當我的博客發布垃圾評論時，我的整個緩存都會被錯誤地刷新。 由於我一直收到評論和引用垃圾郵件，我的緩存不斷被清空，這使得緩存效率低得多。

所以我花了一個週末來調試這個問題，最後開發了一個解決方法。 如果你們中的任何人遇到同樣的問題，請告訴我，我會向您展示我的修復方法。 這裡故事的寓意是永遠不要假設您的緩存插件可以正常工作。 你需要看看日誌！

禁用 CPU 密集型插件

即使您已按照我上面的所有步驟進行操作，也不可能在惡意訪問到達您的 WordPress 博客之前將其過濾掉。

因此，您總是會收到無法有效處理的網站點擊。 沒有辦法解決。

但是要意識到的重要一點是，您很可能不會遇到帶寬問題，而是會遇到 CPU 問題。

結果（這可能有悖常理），您實際上不想執行任何 CPU 密集型操作，例如動態“縮小”或“壓縮”頁面。 縮小和壓縮有助於提高帶寬，但會犧牲 CPU 使用率。

您最不想做的是縮小和緩存惡意訪問。 事實上，您可能也應該考慮不使用 GET 參數縮小或壓縮 URL。

最重要的是，您不應在您的站點上運行任何 CPU 密集型插件。 WP-Engine 有一個很好的 CPU 密集型插件列表，你應該盡量避免。

當我仔細閱讀我的插件列表時，我注意到我正在使用一個“類似的帖子”插件。 當我查看源代碼時，我震驚地發現該插件正在進行全文比較以查找類似的文章，這是一個主要的 CPU 消耗且不可擴展。

一旦我找到合適的替代品，這個插件肯定會被扔進垃圾桶。

故事的道德啟示

僅僅因為在線速度測試告訴您您的博客速度快，在總體上並沒有多大意義。

不要誤會我的意思。 頁面加載速度對於搜索引擎和您的普通客戶很重要，但您還必須考慮可能繞過緩存並使服務器癱瘓的惡意訪問。

所以不要盲目地安裝緩存和其他加速插件。 花一些時間來分析您的流量並儘可能多地編寫 .htaccess 規則，以最大限度地減少 WordPress 必須執行的工作。 祝你好運！