为什么您的 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 必须执行的工作。 祝你好运！