没有不值得去解决的问题,也没有不值得去学习的技术!

从站点健康警告到全绿通关

如 如图1 所示,站点健康直接提示这是一个可能对性能或安全性产生重大影响的问题,需要优先解决。

作者:

WordPress 性能优化手记

如 如图1 所示,站点健康直接提示这是一个可能对性能或安全性产生重大影响的问题,需要优先解决。

(1) 从站点健康警告到全绿通关

PHP Fatal error: Uncaught RedisException: OOM command not allowed when used memory > 'maxmemory'. in /data/wwwroot/.../wp-content/plugins/w3-total-cache/Cache_Redis.php:150

(2) 解决 WordPress + Polylang 批量处理标签时遇到的 Redis OOM 错误

采用 ondemand 模式,适合 1 核小内存机器,空闲时释放进程。最终配置如下:如图4

(3) 一次WordPress站点504错误的排查与优化实录

优化前最终基准数据:历史累计504错误129条(6月3日峰值126条,为爬虫批量爬标签导致)。

(4) 从单日126次504超时到彻底稳定:WordPress 1核2G服务器极限优化全记录(附全部实操命令)

WebPageTest 核心指标

(5) WordPress性能基准测试与CDN选型实录:从国内拨测到海外WebPageTest,1核2G服务器如何面向全球

页面底部提示“此响应不是合法的 JSON 响应”。

(6) WordPress 标签保存失败?Nginx 限流规则惹的祸 —— 一次完整的 429 问题排查与解决

表示页面仍然是动态生成,没有缓存命中。

(7) WordPress + Nginx + W3 Total Cache 缓存未生效排查全过程(OneinStack 实战)

图7:带 Query String 后,W3TC 显示 Requested URI contains query

(8) WordPress CPU 再次满载:动态参数如何穿透 CDN 与 W3TC 页面缓存

图1:阿里云 ECS 在 14:33~14:42 期间 CPU 使用率持续接近 100%,而内存使用率整体较为稳定

(9) WordPress 服务器 CPU 再次满载:从 Nginx 499、PHP-FPM、Redis 到 W3TC 冷缓存的完整排查

图4:W3TC 最终使用 300 秒 × 7 页,并切换到中英文联合 Sitemap

(10) 从 CPU 告警到双域名预缓存:W3 Total Cache、EdgeOne 与 Cloudflare 96 小时缓存优化实战

一、发现问题

最近在 WordPress 后台的 工具 → 站点健康 中,发现了一个「关键问题」:

未检测到页面缓存,且服务器响应时间缓慢

如 如图1 所示,站点健康直接提示这是一个可能对性能或安全性产生重大影响的问题,需要优先解决。

如 如图1 所示,站点健康直接提示这是一个可能对性能或安全性产生重大影响的问题,需要优先解决。
  • 服务器响应时间中位数为 656ms,而推荐的临界值是 600ms,已经超标。
  • 未检测到页面缓存插件。
  • 未检测到客户端缓存响应头。

这意味着每次用户访问,服务器都要动态生成页面,既慢又消耗资源。我决定彻底解决它。

了解有关页面缓存的更多信息(在新窗口中打开)https://developer.wordpress.org/advanced-administration/performance/optimization/#caching 如图2

了解有关页面缓存的更多信息(在新窗口中打开)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等,非常符合我后续写性能优化系列文章的需求。

如图15 是我最终选择W3 Total Cache的界面截图。它的功能覆盖页面缓存、数据库缓存、对象缓存、浏览器缓存、CDN等,非常符合我后续写性能优化系列文章的需求。

三、安装与基础配置

3.1 安装插件

安装并激活插件,W3 Total Cache,如图4 是激活后的欢迎界面,它提供了一个「设置指南」向导,非常友好。

安装并激活插件,W3 Total Cache,如图4 是激活后的欢迎界面,它提供了一个「设置指南」向导,非常友好。

3.2 页面缓存引擎测试

向导第一步是测试页面缓存的存储引擎。如图5 是测试结果:

向导第一步是测试页面缓存的存储引擎。如图5 是测试结果:
存储引擎延迟(ms)相对提升
846.38
磁盘:基本25.40-97.00%
磁盘:增强24.81-97.07%
Redis28.84-96.59%

磁盘:增强 不仅速度最快,而且官方推荐。我毫不犹豫选择了它。

3.3 数据库缓存引擎测试

如图6 是数据库缓存的测试结果:

如图6 是数据库缓存的测试结果:
存储引擎延迟(ms)提升
9191.75
磁盘293.43-96.81%
Redis290.52-96.84%

Redis 比磁盘略快,且插件提示“建议使用Redis或Memcached”,所以我选择了 Redis。

3.4 对象缓存引擎测试

如图7 是对象缓存的测试结果:

如图7 是对象缓存的测试结果:
存储引擎延迟(ms)提升
170.08
磁盘150.29-11.64%
Redis38.26-77.50%

Redis 优势巨大,延迟从170ms降到38ms。毫无疑问,继续选择 Redis。

3.5 图片转换功能

如图8 是Image Converter的界面。我选择 不启用,原因有三:

  • 它是第三方远程转换(依赖w3-edge.com的API),免费额度很少(100次/小时,1000次/月)。
  • 图片需要上传到别人的服务器,有隐私顾虑。
  • 本地转换插件(如EWWW、Imagify)更自由、无限制。
如图8 是Image Converter的界面。我选择 不启用,原因有三:

3.6 延迟加载图像

如图9 是延迟加载的设置界面。我勾选了“启用延迟加载”,并保持默认选项。

如图9 是延迟加载的设置界面。我勾选了“启用延迟加载”,并保持默认选项。

随后查看网页源代码,如图11 所示,图片标签中出现了 class="lazy",说明W3 Total Cache成功为图片添加了懒加载标记。

随后查看网页源代码,如图11 所示,图片标签中出现了 class="lazy",说明W3 Total Cache成功为图片添加了懒加载标记。

3.7 完成安装

如图10 是安装完成后的摘要页面,显示:

  • 页面缓存:磁盘:增强(TTFB提升-97.07%)
  • 数据库缓存:Redis
  • 对象缓存:Redis
  • 图片转换:未启用
  • 延迟加载:已启用
如图10 是安装完成后的摘要页面,显示:

四、功能兼容性测试

4.1 浏览量统计

我使用的是 Post Views Counter 插件。由于页面缓存的存在,本以为PHP模式会失效(如图12)。

我使用的是 Post Views Counter 插件。由于页面缓存的存在,本以为PHP模式会失效(如图12)。

如图13 是Post Views Counter的计数模式设置界面。

如图13 是Post Views Counter的计数模式设置界面。

我将模式从“PHP”切换为 REST API。测试发现:

  • 后台文章列表的浏览量数字正常增长(从60变成66)。
  • 但前台页面因缓存显示仍是60。

如图14 是清空W3 Total Cache页面缓存后的对比截图,前台数字终于同步为66。之后每天观察,浏览量持续增加,证明 REST API 模式在缓存环境下工作正常。

如图14 是清空W3 Total Cache页面缓存后的对比截图,前台数字终于同步为66。之后每天观察,浏览量持续增加,证明 REST API 模式在缓存环境下工作正常。

我在 PHP模式中实际测试,发现浏览量数字也会增长。不过我最终选择了 REST API 模式。

4.2 评论功能

我亲自发布了一条测试评论,如 如图16 所示。提交后页面即时显示新评论,没有延迟或刷新异常,说明W3 Total Cache处理评论缓存的机制非常智能(会刷新当前页面的缓存,或者主题使用了AJAX评论)。

我亲自发布了一条测试评论,如 如图16 所示。提交后页面即时显示新评论,没有延迟或刷新异常,说明W3 Total Cache处理评论缓存的机制非常智能(会刷新当前页面的缓存,或者主题使用了AJAX评论)。

4.3 延迟加载图像

通过开发者工具的Network面板滚动测试(如图17),我确认了:

  • 初次加载只请求首屏图片。
  • 向下滚动时,新图片才陆续出现在网络请求中。
通过开发者工具的Network面板滚动测试(如图17),我确认了:

延迟加载完美生效。

五、最终成果

再次进入 工具 → 站点健康,之前的“1个关键问题”已经消失,状态变为 “良好”。如图11。

再次进入 工具 → 站点健康,之前的“1个关键问题”已经消失,状态变为 “良好”。如图11。

六、总结与下一步计划

通过这次优化,我深刻体会到:页面缓存是 WordPress 性能提升的第一生产力。而W3 Total Cache + Redis的组合,在阿里云ECS上表现极其出色。

解决 WordPress + Polylang 批量处理标签时遇到的 Redis OOM 错误

WordPress 网站维护、性能优化与博客运营咨询

本站已持续运营超过 10 年,累计发布 1000+ 篇原创技术文章,长期实践 WordPress 网站建设、CDN / Cloudflare 配置、缓存优化、Google SEO、广告变现和多语言网站运营。

如果你的 WordPress 网站遇到访问慢、缓存异常、插件冲突、广告不显示、SEO 基础结构混乱、CDN 配置不确定等问题,可以联系我做一次远程技术排查。

适合以下用户:
✅ 个人博客站长
✅ WordPress 网站运营者
✅ 独立开发者与内容创作者
✅ SaaS 产品官网运营团队
✅ 希望优化网站速度与稳定性的站点

服务内容:
✅ WordPress 速度优化
✅ Cloudflare / CDN / 缓存配置排查
✅ 插件冲突与页面异常排查
✅ AdSense 广告显示问题排查
✅ SEO 基础结构检查
✅ 博客运营与商业化咨询

如需了解方案或交流相关问题,请直接联系我,并注明:WordPress 维护咨询

联系方式:
Telegram:@shuijingwan
微信:13980074657
邮箱:shuijingwanwq@gmail.com

评论

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注

这个站点使用 Akismet 来减少垃圾评论。了解你的评论数据如何被处理