接上篇
上篇聊完了我是怎么纠结、最终决定换主题的。决定做了，但紧接着就遇到了一个新问题：
换主题和开 CDN，顺序怎么安排？
我原本的计划是先用旧主题测完「无 CDN」的数据，开 CDN 拿到对比结果，然后再换主题。这样旧主题的「CDN 提速效果」也能留个档，看起来挺完美的。
但仔细一想，这个方案有问题，而且问题不小。
我为什么否掉了「先开 CDN，再换主题」
第一个问题：数据没法对比
做性能测试最基本的常识是：一次只改变一个变量。
如果我先开 CDN 拿到旧主题的数据，然后再换新主题，那新旧两组数据之间同时存在「主题代码」和「CDN 状态」两个差异。到时候测出来的加载速度变化，究竟是 CDN 贡献的，还是新主题本身更轻量或更臃肿导致的？完全说不清楚。
而且，上篇数据已经显示我的读者 96% 用 Chrome、93% 用 Windows、35% 以上屏幕宽度超过 1680px。新主题大概率会比旧主题更适配这些主流配置，但适配的同时可能也会引入更多的 CSS 和 JS——这些变化都会影响加载时间。如果和 CDN 的效果混在一起，根本没法拆解。
第二个问题：CDN 缓存会是一场灾难
这是更实操层面的考量。
CDN 缓存是基于 URL 路径一一对应的。旧主题的静态文件路径是 /wp-content/themes/hueman/，新主题则是 /wp-content/themes/newtheme/。如果我先开了 CDN，换主题后会发生这些事：
- 旧主题的缓存文件会继续占用 CDN 节点空间，直到过期才能释放
- 新主题的路径下没有任何缓存，所有请求都会穿透回源，造成「回源风暴」——相当于 CDN 白开了
- 如果新旧主题恰好有同名文件（比如都叫
style.css），CDN 可能误将旧缓存返回给访客，导致页面样式错乱
这意味着换完主题后，我不仅要手动刷新大量缓存，还要忍受新主题上线初期速度变慢的尴尬期。这完全背离了上篇文章里我换主题的初衷——给读者更好的体验。
我的选择：先换主题，再开 CDN
综合以上分析，我的操作步骤确定为：
第一步：更换主题
挑选一款对宽屏友好、移动端响应式完善、且代码轻量的主题，完成迁移和样式微调。
第二步：重新测试「无 CDN」基线
用相同的测试工具（PageSpeed Insights、Boorex 等）和节点，重新跑一遍国内/国外的网速数据，作为新主题的「裸跑成绩」。
这一步有个小插曲：我旧主题的「无 CDN」数据其实已经测完了，但既然决定换主题，那组数据就用不上了——因为换了主题，页面大小、请求数量都变了，拿旧主题的基线和换完主题后的 CDN 效果对比，结论是不准确的。沉没成本，该放弃就得放弃。
第三步：开启 CDN
待新主题稳定运行几天后，再开启 CDN，让缓存随着真实访客自然预热，然后进行第二轮测试，得出纯粹的 CDN 提速数据。
第四步：发布对比文章
整理两组数据的差异，写一篇客观的 CDN 效果评测。
这样做的好处是：
- 控制变量：新主题的「无 CDN」和「有 CDN」两组数据，变量只有一个——CDN 是否开启，结论经得起推敲
- 规避缓存问题：新主题上线时 CDN 还没开，不存在缓存污染或回源风暴的问题
- 平滑过渡：开启 CDN 后，缓存随着访问自然建立，不需要手动大量刷新或预热
给同样在折腾的朋友一点参考
这次看似简单的「先开 CDN 还是先换主题」的选择，背后其实是控制变量原则和缓存管理实操的双重考量。虽然旧主题的「无 CDN」数据白测了，但相比拿到一份无法解释的对比结果，这个沉没成本是值得付出的。
如果你也正在折腾 CDN 或更换主题，我的建议很简单：
- 先做决定：换不换主题？ 这个决定不该凭感觉，去查数据。
- 如果决定换，那就换完再开 CDN。 顺序错了，后续的麻烦比想象中多。
后续我会把新主题的选择过程和 CDN 实测数据也整理出来，欢迎持续关注。