从站点健康警告到全绿通关
一、发现问题
最近在 WordPress 后台的 工具 → 站点健康 中，发现了一个「关键问题」：
未检测到页面缓存，且服务器响应时间缓慢
如 如图1 所示，站点健康直接提示这是一个可能对性能或安全性产生重大影响的问题，需要优先解决。
- 服务器响应时间中位数为 656ms，而推荐的临界值是 600ms，已经超标。
- 未检测到页面缓存插件。
- 未检测到客户端缓存响应头。
这意味着每次用户访问，服务器都要动态生成页面，既慢又消耗资源。我决定彻底解决它。
了解有关页面缓存的更多信息（在新窗口中打开）https://developer.wordpress.org/advanced-administration/performance/optimization/#caching 如图2
缓存插件安装简便，可将您的 WordPress 文章和页面缓存为静态文件。这些静态文件随后会提供给用户，从而减轻服务器的处理负载。对于相对静态的页面，这可以将性能提升数百倍。您可以通过在插件目录中搜索“cache”来获取相关插件列表。
二、选择方案
我开始调研各种缓存插件。我在 WordPress 插件库中搜索“cache”的结果，可选方案非常多。
综合对比后，我锁定了三款主流插件：
| 插件 | 优点 | 缺点 |
|---|---|---|
| WP Super Cache | 简单轻量，适合新手 | 功能相对单一 |
| LiteSpeed Cache | 性能极致，但依赖 LiteSpeed 服务器 | 我的阿里云ECS是Nginx环境，无法发挥最大优势 |
| W3 Total Cache | 功能全面，支持Redis/Memcached，技术爱好者最爱 | 配置稍复杂，但可玩性高 |
如图15 是我最终选择W3 Total Cache的界面截图。它的功能覆盖页面缓存、数据库缓存、对象缓存、浏览器缓存、CDN等，非常符合我后续写性能优化系列文章的需求。
三、安装与基础配置
3.1 安装插件
安装并激活插件，W3 Total Cache，如图4 是激活后的欢迎界面，它提供了一个「设置指南」向导，非常友好。
3.2 页面缓存引擎测试
向导第一步是测试页面缓存的存储引擎。如图5 是测试结果：
| 存储引擎 | 延迟(ms) | 相对提升 |
|---|---|---|
| 无 | 846.38 | – |
| 磁盘：基本 | 25.40 | -97.00% |
| 磁盘：增强 | 24.81 | -97.07% |
| Redis | 28.84 | -96.59% |
磁盘：增强 不仅速度最快，而且官方推荐。我毫不犹豫选择了它。
3.3 数据库缓存引擎测试
如图6 是数据库缓存的测试结果：
| 存储引擎 | 延迟(ms) | 提升 |
|---|---|---|
| 无 | 9191.75 | – |
| 磁盘 | 293.43 | -96.81% |
| Redis | 290.52 | -96.84% |
Redis 比磁盘略快，且插件提示“建议使用Redis或Memcached”，所以我选择了 Redis。
3.4 对象缓存引擎测试
如图7 是对象缓存的测试结果：
| 存储引擎 | 延迟(ms) | 提升 |
|---|---|---|
| 无 | 170.08 | – |
| 磁盘 | 150.29 | -11.64% |
| Redis | 38.26 | -77.50% |
Redis 优势巨大，延迟从170ms降到38ms。毫无疑问，继续选择 Redis。
3.5 图片转换功能
如图8 是Image Converter的界面。我选择 不启用，原因有三：
- 它是第三方远程转换（依赖w3-edge.com的API），免费额度很少（100次/小时，1000次/月）。
- 图片需要上传到别人的服务器，有隐私顾虑。
- 本地转换插件（如EWWW、Imagify）更自由、无限制。
3.6 延迟加载图像
如图9 是延迟加载的设置界面。我勾选了“启用延迟加载”，并保持默认选项。
随后查看网页源代码，如图11 所示，图片标签中出现了 class="lazy"，说明W3 Total Cache成功为图片添加了懒加载标记。
3.7 完成安装
如图10 是安装完成后的摘要页面，显示：
- 页面缓存：磁盘：增强（TTFB提升-97.07%）
- 数据库缓存：Redis
- 对象缓存：Redis
- 图片转换：未启用
- 延迟加载：已启用
四、功能兼容性测试
4.1 浏览量统计
我使用的是 Post Views Counter 插件。由于页面缓存的存在，本以为PHP模式会失效（如图12）。
如图13 是Post Views Counter的计数模式设置界面。
我将模式从“PHP”切换为 REST API。测试发现：
- 后台文章列表的浏览量数字正常增长（从60变成66）。
- 但前台页面因缓存显示仍是60。
如图14 是清空W3 Total Cache页面缓存后的对比截图，前台数字终于同步为66。之后每天观察，浏览量持续增加，证明 REST API 模式在缓存环境下工作正常。
我在 PHP模式中实际测试，发现浏览量数字也会增长。不过我最终选择了 REST API 模式。
4.2 评论功能
我亲自发布了一条测试评论，如 如图16 所示。提交后页面即时显示新评论，没有延迟或刷新异常，说明W3 Total Cache处理评论缓存的机制非常智能（会刷新当前页面的缓存，或者主题使用了AJAX评论）。
4.3 延迟加载图像
通过开发者工具的Network面板滚动测试（如图17），我确认了：
- 初次加载只请求首屏图片。
- 向下滚动时，新图片才陆续出现在网络请求中。
延迟加载完美生效。
五、最终成果
再次进入 工具 → 站点健康，之前的“1个关键问题”已经消失，状态变为 “良好”。如图11。
六、总结与下一步计划
通过这次优化，我深刻体会到：页面缓存是 WordPress 性能提升的第一生产力。而W3 Total Cache + Redis的组合，在阿里云ECS上表现极其出色。
