不知什么时候起，WordPress的后台提供了一个“站点健康”的评估页面，会对你的站点跑一系列测试并提供改进建议。
有一些是严重的问题，有一些则是推荐的可选改进。但你懂的，我喜欢把推荐的也做了，才会算完。而且最近插件启用多以后，的确感觉我的网站变慢了，慢到连爬虫都不愿意上门了。
所以决心按照站点健康的要求，一个个改正。而要改正这些，并不一定要亲自改代码，很多时候，用好插件做做配置就可以了。
准备工作
首先，你需要了解一些背景知识。
其次，我们需要确保PHP安装了需要的可选插件。PHP的插件安装方式，取决于你是通过apt安装的公版php-fpm，还是自行编译安装的php-fpm。
如果你是apt安装的公版php-fpm，你可以自行在apt软件源中选择你需要的可选php插件并安装之。
如果你是通过lnmp自动化脚本安装的建站环境，那php插件安装就比较蹊跷一些。你使用lnmp压缩包内的install.sh脚本安装整套环境以后，还需要并只能使用lnmp压缩包内的另一个脚本addons.sh脚本来安装可选的组件：
具体而言，推荐你安装Redis、imagieMagick和Exif。安装后两者，可以让你得到“站点健康”的“必需和推荐的模组均已安装”认证。而前者，是后面优化步骤需要的内存缓存/持久化对象缓存引擎。
推荐的插件
WordPress提供了丰富的cache插件，但大多良莠不齐，而且甚至相互冲突。这里推荐你安装并仅安装以下插件，以最优化配置：
来自BoldGrid的W3 Total Cache
它是WordPress缓存和速度优化的全方位插件，理论上讲，你只需要安装这一个插件即可，它支持服务器端的各个层面的缓存设置，包括数据库缓存、对象缓存、操作码缓存、页面缓存、页面优化、响应标头优化、云端加速等。安装后通过一定的设置，你就能解决“站点健康”上基本所有和速度优化有关的问题，获得诸如“正在使用一个持久对象缓存”、“检测到页面缓存，并且服务器响应时间良好”等认证。
它和object cache引擎结合使用时效果最佳。Redis并不是唯一可使用的引擎，其它的Memcached、opcache等都有支持，但个人测试的结果，兼容性、功能和易用性综合最佳的是Redis。你可以在插件的“安装指南”引导页面对这些引擎进行测试，如下：
配置上，一般情况的设置你跟着插件的推荐或者你自己的需求来设置就好了。我这边基于最小原则会建议你：
- 不需要启用opcache操作码缓存，反正对于小博客来说PHP执行效率影响不大，等到日后变成大博客了再说吧。
- 不需要开启WebP Converter，因为它在免费版下有配额限制。后面我会推荐另一款插件来补充。
- 不需要开启页面压缩，因为我实测和我的主题很容易冲突，经常会把我的页面布局打乱。后面我会推荐另一款插件来补充。
- 请开启“用户体验”下的“延迟加载”（也就是“处理 HTML 图像标记”和“处理背景图像”），这样你就不用额外安装Performance Lab插件了。
该插件功能强大，设计符合专业认知，提供比较傻瓜的一键式配置引导，不强制消费，是不可多得的WordPress插件。
2025.07.02更新
最近发现，这个插件在更新浏览器缓存设置后，会一直提示我“Nginx.conf规则已更新。请重新启动nginx服务器以提供一致的用户体验”。但我反复重启nginx服务器也无济于事，这个提示还是没有消失。
首先我们知道，这个提示在校验通过后是会自动消失的，所以根本原因是这些配置的确没有生效。
后续排查，发现因为WordPress没有读写主机vhost目录之外的系统文件的能力，所以它只会把更新后的nginx.conf规则生成在WordPress根目录。所以，无论我们如何重启nginx服务器，这些规则都不会被自动载入的。
我们需要到nginx服务器的conf配置目录中，用include的办法把位于WordPress根目录的这个nginx.conf文件给链接进配置文件的server配置域中，这个插件生成的配置才会生效。然后上面这个烦人的提示就会消失。
实际测试，需要在vhost的主机配置中进行单独的链入，才能友好地生效。需要特别注意的是，如果你也选择我这样的做法，那在vhost的主机配置中，因为http和https是分开的两个server，所以你需要在这两个server配置域内分别进行一次include，才能完全生效。
并且，最好主nginx.conf中的server配置域也进行include，因为据我推测，主nginx.conf中的server配置域是对应你不用域名访问主机、直接用IP访问的情况，也就是default的情况，这个情况也最好覆盖到。
更多信息，可参考：https://www.zhanzhangb.com/2459.html
来自LiteSpeed Technologies的LiteSpeed缓存
其实这个插件和上一个W3 Total Cache插件非常重复，而且还一昧安利你使用它的云端加速功能，比较鸡肋 。
但我仍推荐你安装的原因，是因为它提供了一个非常贴心的功能，就是识别数据库中的老式MyISAM表并把它转换为InnoDB表。使用这个功能检测你的数据库以后，你就可以把它卸载或者禁用了。
来自TeamUpdraft的WP-Optimize
这个插件非常推荐安装并保留，因为它恰好补全了W3 Total Cache的软肋。
它提供的图像压缩功能，可以把图片转换成WebP，和W3 Total Cache的功能点设计非常一致，还没有配额限制。
它提供的页面压缩功能，实测和我的博客兼容性很好，不会出现W3 Total Cache的破坏页面布局的问题，而且运行状态透明，界面设计更好。
它还有一个非常独到的地方，就是数据库的优化相关功能。它能一键帮你优化数据库表（重建数据库表）；还提供数据库表详细视图，并利用大数据帮助你识别哪些表是由什么已卸载的插件残留下来的，并让你轻松删除这些表（默认卸载插件不会清理数据库表，所以这个功能真心满分推荐）。
不推荐的插件
如前述，有些插件会相互冲突，不推荐安装。
来自WordPress Performance Team的Performance Lab
功能没什么特别的，很多还和W3 Total Cache重复（比如Lazy Loading），设计感和透明度都很差。
最让我无语的，是它还会在站点公共目录下创建和W3 Total Cache冲突的同名的object-cache.php，使得W3 Total Cache提示“对象缓存加载项文件对象缓存.php不是 W3 总缓存下拉列表，删除它或禁用对象缓存”：
这个提示让人云里雾里，也不知道问题的根源在哪里。并且，这个问题会导致W3 Total Cache的对象缓存、页面缓存等功能失常，让你不管怎么设置都过不了“站点健康”的认证。
经过反复试错，才确定是这两者有冲突导致，太气人了。
搜索发现，这个问题有被网友提过并得到官方的确认，请查看：
https://wordpress.org/support/topic/conflict-on-object-cache-php
后话
更多信息，请参考：
One comment: