缓存插件还是CDN，WordPress速度优化怎么选

缓存插件和CDN不是二选一，它们治的是两种不同的慢。这道理说起来简单，但把插件装了七八个、CDN也开着、首页打开照样要等好几秒的站，我见过不少——钱和精力都花在了不缺的那一环上。所以每次有人问wordpress速度优化到底该上哪个，我的第一反应从来不是给答案，而是先让人去看看自己那个慢属于哪一类。

先分清你的慢是哪一种

打开浏览器的开发者工具，Network 面板刷一次首页，盯两个数：一个是文档本身（一般是那个 HTML 请求）等了多久，另一个是后面图片、CSS、JS、字体排了多长的队。前一个慢，说明 PHP 渲染、数据库查询、服务器响应在拖后腿；后一个慢，说明是传输和资源体积的问题。这两类问题对应的药完全不一样，一类归缓存和数据库，一类归 CDN 和压缩。

命令行也能粗看。curl -o /dev/null -s -w “%{time_starttransfer}\n” https://你的域名/ ，出来的就是首字节时间，服务器端的锅基本藏在这个数里。这个数超过半秒，先别谈 CDN，先把源站捋顺。

wordpress速度优化，插件能管到的那一半

缓存插件干的事说白了就一件：把 PHP 辛辛苦苦拼出来的页面存成一份静态 HTML，下次有人来直接吐出去，绕开数据库和模板渲染。所以它最大的收益体现在首字节上，对首屏那一堆图片请求基本无能为力。LiteSpeed Cache 免费、WP Rocket 付费、W3 Total Cache 配置项多到能看花眼，选哪个不重要，重要的是页面缓存命中率有没有上去。

对象缓存是另一层，Redis 或者 Memcached 把数据库查询结果放在内存里，登录用户多、动态页面多的站收益更明显。前端那块，Autoptimize 这类合并压缩 CSS/JS 的也能算在插件阵营。要留神的是插件的敌人：购物车、登录态、评论分页、随机推荐，这些一旦被缓存就出事，得在规则里单独排掉，别图省事全站一把缓存。

CDN 治的是另一段路

CDN 把你的图片、JS、CSS 复制到离访客近的节点，主站不用每张图都自己扛，顺手还能省点带宽、挡一点小流量攻击、做图片格式转换。但它不解决源站慢——缓存没命中的时候照样回源，中间还多了一跳，理论上更慢。所以那种首字节都没压下来的站上了 CDN，经常是配完测一圈，感觉没什么变化，然后开始怀疑节点不行。

这几个信号出现，再考虑 CDN

访客散在全国甚至海外，同一个页面南方用户和北方用户打开差一截；带宽账单一直往上涨；access log 里静态文件的请求占了大多数，机器 CPU 其实在给图片打工；或者站里图片多、封面多。这几条中了两条以上，节点这钱花得值。反过来，访客基本集中在一个城市、站又不大，距离优势可能还抵不过配置加排查的时间。

有些站，CDN 反而是负担

全站要登录、后台要频繁操作的站，比如会员系统、在线工具后台、电商，缓存规则写不细就容易把不该缓存的东西缓存出去，用户看到别人的登录状态这种事故不是传说。调改期也不适合，改一行代码要等缓存刷新，人会疯。SSL 这块同样有讲究，证书链和回源配置不对，证书验证失败的情况不少见，具体以服务商或官方页面说明为准。这类站不是不能上 CDN，而是先把规则理清，别一把梭。

顺序反了，配得越多越乱

顺序我一直建议：源站 → 页面缓存 → 对象缓存 → 前端压缩 → 最后才轮到 CDN。原因很朴素，源站首字节压到一两百毫秒以内时，CDN 缓存命中率高，效果一眼能看出来；源站首字节还挂着大半秒，你排查一个“页面慢”要在两套系统之间来回猜，纯属给自己加难度。

有回帮人看站，插件、CDN、对象缓存全开着，最后发现是首页有个查询没走索引，前面那些配置全在给一个慢查询擦屁股。这种时候你说插件没用吗？不是，是它根本没机会生效。

几个容易踩的小细节

CDN 的缓存键要不要带查询字符串，这条选错的结果是同一个页面存好几份或者干脆全不命中；/wp-admin/ 和 wp-login.php 一定要绕开缓存；静态资源加版本号或文件名指纹，不然更新了 CSS 用户拿的还是旧的；Redis 对象缓存开了不等于页面缓存开了，两者分工不同，别以为一个能顶两个；国内节点涉及备案，按官方页面说明走，别听人随口一说。

还有插件别叠。两个页面缓存插件同时开着，谁都可能给谁下绊子，出了问题连日志都不知道看哪家的。

落到操作上就四步：先用开发者工具比一比首字节和资源加载哪个慢；首字节慢，先查慢查询和页面缓存；资源慢，先压图片体积、加懒加载、开压缩；上面都做完还觉得慢，而且访客确实分散，再上 CDN。顺序对了，多数站花不了多少钱就能看出变化；顺序错了，插件装一页、节点开一堆，打开还是那个速度。不如今晚就打开 Network 面板看一眼，比继续纠结选哪个强。