系列： WordPress 性能优化手记
-
面对 WordPress 后台站点健康提示的页面缓存缺失与响应时间缓慢问题，文章记录了通过安装并配置 W3 Total Cache 插件来优化的全过程。经测试，最终选择磁盘增强模式作为页面缓存引擎，并结合 Redis 处理数据库与对象缓存，同时启用了图片延迟加载。配置完成后，验证了浏览量统计与评论功能的兼容性，成功消除了关键问题警告，显著降低了服务器响应时间。
-
本文记录了在 WordPress 网站使用 Polylang 插件批量处理标签时，因 W3 Total Cache 的 Redis 对象缓存引发 OOM 错误的解决过程。通过排查发现 Redis 最大内存限制过小且淘汰策略配置不当，导致写入被拒绝。解决方案是通过修改配置文件将最大内存上限提升至 1GB，并将淘汰策略调整为 allkeys-lru，最终使批量脚本顺利完成，验证了调整内存参数和淘汰策略的有效性。
-
针对基于阿里云ECS和OneinStack环境的WordPress站点出现的504错误，文章记录了排查与优化过程。面对CPU满载和后台响应缓慢，发现PHP-FPM慢日志配置冲突及Nginx超时设置缺失。通过修正PHP-FPM参数为动态模式，调整Nginx超时时间，并开启慢日志监控，最终使CPU使用率回落，站点恢复正常，同时提出了升级硬件和引入CDN等后续建议。
-
本文记录了在1核2G阿里云ECS服务器上解决WordPress单日126次504超时的全过程。故障根源在于18000个标签页导致并发过高，通过禁用WP-CRON并改用系统定时任务、配置Nginx限流拦截恶意爬虫、调整W3TC与Redis缓存策略以绕过数据库查询，实现了从系统机制到缓存层的全面调优。该方案在不影响SEO和数据完整性的前提下，成功压榨服务器性能并解决了高负载与超时问题。
-
针对 WordPress 站点全球访问速度问题，本文记录了使用国内拨测和海外 WebPageTest 进行性能基准测试的过程。测试发现，国内跨运营商延迟较高，而海外节点受限于高延迟和大量请求，LCP 指标未达标。基于分析，文章对比了阿里云 CDN 与 Cloudflare 的优缺点，最终确定以海外加速为主，优先接入 Cloudflare 免费版并计划通过智能 DNS 分流兼顾国内体验。
-
WordPress 站点配置 Nginx 全局限流后，后台编辑文章时出现标签保存失败及 429 错误。经排查发现，Gutenberg 编辑器处理标签时会频繁调用 REST API，导致触发了每秒 6 次的严格限流阈值。最终通过将 Nginx 限流速率调升至 30 次/秒并增加突发缓冲，消除了 429 拦截，恢复了标签功能的正常保存，同时保留了基本的安全防护能力。
-
本文记录了在 OneinStack 环境下排查 WordPress 与 W3 Total Cache 缓存未生效问题的全过程。针对响应头显示动态生成而插件显示已启用的矛盾，文章验证了 Redis 状态与 Nginx 配置，分析了 Disk: Enhanced 模式的依赖性及 Response Headers 的误读。作者最终修正了初始结论，确认在此环境下 W3 Total Cache Page Cache 默认生效，无需额外 Nginx 重写或配置，并通过关闭 Page Cache 保留 Redis Object Cache 优化了架构。
-
在通过 EdgeOne 屏蔽异常 Sogou UA 流量、解决 WordPress 502 后，阿里云 ECS 仍然偶发 CPU 95%～100% 告警。进一步结合 PHP-FPM Slow Log、Nginx 请求日志和 W3 Total Cache 实测发现，大量带 Query String 的前台请求会导致 W3TC Disk: Enhanced 页面缓存无法复用，使请求重新进入 PHP-FPM，完整执行 Gutenberg、Polylang、Post Views Counter、Redis Object Cache 和数据库查询。正常 URL 第二次请求 TTFB 仅约 0.1 秒，而带参数 URL 每次仍需约 7～11 秒。最终决定不逐个封禁参数，也暂不升级服务器或修改 W3TC 内部逻辑，而是在 EdgeOne 与 Cloudflare CDN 层进行 Query String 缓存键和回源 URL 规范化，从根源减少动态参数造成的缓存穿透。
-
一次阿里云 ECS CPU 接近 100% 的告警，最终从 Nginx 499、PHP-FPM max_children、Slowlog、W3 Total Cache Object Cache 和 Redis 一路排查到 Page Cache 冷缓存。实测发现服务器仅有 1 vCPU，而 /page/9/ 在 Cold MISS 时 TTFB 高达 10.6 秒，缓存命中后仅约 0.016 秒。最终没有提高 PHP-FPM 并发、关闭 Redis 或开启缓存预热，而是将 W3TC Page Cache 最长生命周期从 1 小时延长到 12 小时，以降低历史页面反复动态生成带来的 CPU 压力。
-
在再次出现 CPU 告警后，我暂时停止继续追查瞬时负载根因，转而重新启用 W3 Total Cache 页面预缓存，并从 900 秒 × 5 页 的保守配置逐步优化。通过准确统计中英文 Yoast Sitemap，确认真正需要预缓存的页面为 6270 个，并自动生成 www + en 联合 W3TC 专用 Sitemap，每小时同步更新。最终将 W3TC Page Cache、EdgeOne 中文站和 Cloudflare 英文站的缓存生命周期统一调整为 96 小时，同时采用 300 秒 × 7 页 的低批量持续预热策略，在降低冷缓存回源和 PHP 动态生成压力的同时，避免预缓存本身制造新的 CPU 峰值。