WordPress 装好、文章发了，兴冲冲测个速度——TTFB 八百毫秒起步。原因是 WP 的工作机制决定的：每个访客进来，Nginx 把请求交给 PHP-FPM，PHP 跑一遍加载几十个插件和主题文件，再连 MySQL 查几条数据，拼出 HTML 返回。哪怕页面内容一整天没变，这套流程也是每个请求从头走一遍。页面缓存要解决的就是这件事：把拼好的 HTML 存下来，后续请求直接拿现成的，PHP 和数据库都不用碰。
先盘一下 2026 年插件这块的格局。付费首选是 WP Rocket（单站 59 美元一年），激活即用，页面缓存、浏览器缓存、GZIP 默认全开，懒人闭眼买。免费方案里，LiteSpeed Cache 名声最大，但它的杀手锏是服务器级缓存——只有你的 Web 服务器是 LiteSpeed 或 OpenLiteSpeed 才满血，Nginx 用户装了只剩 CSS/JS 优化这些边角功能，等于废了一半。W3 Total Cache 免费且功能最全，每个缓存层都有独立开关，代价是配置项几百个，新手容易配出错。WP Super Cache 是 WordPress 母公司 Automattic 出的官方插件，活跃安装百万级，Easy 模式一个开关就完事，功能少但稳。选型一句话：肯花钱上 WP Rocket，Nginx 服务器求稳装 WP Super Cache，OpenLiteSpeed 用户用 LiteSpeed Cache。
不过 Nginx 用户其实还有一条更彻底的路：不上插件，直接用 Nginx 自带的 fastcgi_cache。它的缓存层级比所有插件都靠前——缓存命中时请求根本不会进 PHP，由 Nginx 直接吐出缓存的响应，速度比插件方案还快一个档位。代价是配置写在服务器上，没有图形界面。
完整配置贴在这里，可以直接改改域名用：
# /etc/nginx/conf.d/wp-cache.conf
fastcgi_cache_path /var/cache/nginx/wp levels=1:2
keys_zone=WORDPRESS:100m inactive=60m max_size=2g;
server {
# ... 你原有的 server 配置 ...
set $skip_cache 0;
# 登录用户、评论者不缓存（否则看到的可能是别人的个性化页面）
if ($http_cookie ~* "comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_logged_in") {
set $skip_cache 1;
}
# POST 请求（提交表单/评论）不缓存
if ($request_method = POST) {
set $skip_cache 1;
}
location / {
try_files $uri $uri/ /index.php?$args;
}
location ~ \.php$ {
include fastcgi_params;
fastcgi_pass unix:/run/php/php8.3-fpm.sock;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_cache_bypass $skip_cache;
fastcgi_no_cache $skip_cache;
fastcgi_cache WORDPRESS;
fastcgi_cache_valid 200 301 302 10m;
fastcgi_cache_use_stale updating error timeout invalid_header;
add_header X-FastCGI-Cache $upstream_cache_status;
}
# 发布/更新文章时自动清缓存，进 WP 主题的 functions.php
# add_action('save_post', function() {
# // 调用 nginx 的缓存清理接口，或用 Nginx Helper 插件代劳
# });
}
这段配置里最关键的是 $skip_cache 那组判断。缓存页面意味着所有人看到的是同一份 HTML，所以登录用户的评论预览、购物车这类个性化内容必须绕开缓存，判断条件就是检查 WP 写入的几个特征 Cookie。fastcgi_cache_use_stale 是个很妙的参数：后端 PHP 崩了的瞬间，Nginx 可以继续用稍旧的缓存页顶住，访客无感知，等于免费多了一层高可用。
改完重载 Nginx，验证分两步。第一步看响应头有没有缓存命中标记：
# 未登录状态连续请求两次，第二次应该命中
curl -sI https://example.com/ | grep -i x-fastcgi-cache
# 第一次：MISS（缓存未命中，走PHP）
# 第二次：HIT（命中缓存，没进PHP）
# 验证登录态跳过缓存：带浏览器里的登录Cookie再请求
# 期望输出 BYPASS
第二步压测对比。装不装缓存各跑一次 ab 或 hey，并发 50 打首页，TTFB 通常能从几百毫秒掉到几十毫秒，QPS 差一个数量级都正常。
最后说下清缓存这个绕不开的问题。页面缓存了，文章更新后旧页面还在缓存里。插件方案会自动处理，fastcgi_cache 方案要么配 nginx 的 cache purge 模块，要么装个 Nginx Helper 插件让它发清理请求。我的建议：小站追求省心就用 WP Super Cache，愿意多花二十分钟配置、追求极致性能的 Nginx 用户直接上 fastcgi_cache，这条路的收益天花板比所有插件都高。另外提一句，缓存和上一篇的 gzip 不冲突，压缩发生在缓存之后，两层一起开是标准姿势。
相关阅读：页面缓存是加固总清单性能组的第二棒。《性能与安全加固总清单：按这张表打勾，新站48小时达到生产水准》每完成一项打个勾，缓存这项配本篇的方案一次配对。
申请创业报道，分享创业好点子。点击此处，共同探讨创业新机遇！
