前几天，我连续写了几篇关于 WordPress CDN、Cloudflare Free、腾讯云 EdgeOne 的文章。
最开始的问题是：
WordPress 主站上线 CDN 后，到底有没有真正变快？
后来又进一步发现：
Cloudflare Free 即使已经命中 HTML 缓存，在中国大陆访问时也可能出现移动、联通线路波动。
今天这篇文章不再重复 EdgeOne 的接入过程，也不再展开讲缓存规则配置，而是专门做一次数据对比。
对比对象只有三个阶段：
阶段一：CDN 上线前
阶段二：Cloudflare Free 上线后
阶段三：腾讯云 EdgeOne 上线后
对比维度也只保留两个：
boce 国内多节点测速
WebPageTest 页面性能测试
这样可以更清楚地回答一个问题：
从 Cloudflare Free 迁移到腾讯云 EdgeOne 后，我的 WordPress 主站到底有没有变快？
一、测试背景
我的网站结构如下：
主站：https://www.shuijingwanwq.com/
英文站：https://www.shuijingwanwq.com/en/
源站：阿里云杭州 ECS
程序：WordPress + Polylang + W3 Total Cache
缓存：页面缓存 + 对象缓存 + CDN 边缘缓存
最开始接入的是 Cloudflare Free。
Cloudflare Free 在海外访问、HTTPS、静态资源缓存、Cloudflare Cache Rules 这些方面都很好。但我的网站主要访问用户仍然来自中国大陆，所以实际体验不能只看 cf-cache-status: HIT，还要看中国大陆三大运营商的访问线路。
迁移前，我已经确认过几个事实：
W3 Total Cache Page Cache 是有效的
Cloudflare HTML 页面可以 HIT
缓存闭环本身没有问题
问题主要出在中国大陆访问链路波动
所以这次迁移到 EdgeOne 后，我最关心的不是“配置是否成功”，而是：
国内 boce 节点是否更稳定
WebPageTest 核心性能指标是否继续保持
TTFB / FCP / LCP / Speed Index 是否变好
总请求数和页面体积是否有异常
二、boce 三阶段对比：CDN 前、Cloudflare 后、EdgeOne 后
先看 boce 数据。
boce 的价值在于，它可以从中国大陆多个地区、多个运营商节点测试网站响应时间。对于中文主站来说，这比单纯在海外跑 WebPageTest 更接近真实访问环境。
1. CDN 上线前 vs Cloudflare 上线后
在之前的测试中，CDN 上线前后大致对比如下：
| 阶段 | 平均响应 | 最慢节点 | 无法访问 | 稳定性 |
|---|---|---|---|---|
| CDN 上线前 | 4–5s | 约 10s | 少量 | 中等 |
| Cloudflare 上线后 | 1–2s | 8–10s | 极少 | 明显提升 |
从这个结果看，Cloudflare 上线后确实带来了明显改善。
特别是在重新确认 W3 Total Cache Page Cache 生效、Cloudflare HTML Cache Rule 命中后，网站整体响应比 CDN 上线前好了很多。
这也是我最开始得出的结论：
WordPress 性能优化不能只看有没有 CDN，而要看 CDN、页面缓存、对象缓存、响应头和缓存命中是否形成闭环。
但后续测试又发现，Cloudflare Free 在中国大陆访问并不是始终稳定。
三、Cloudflare Free 的问题：不是不能用，而是波动大
在后续测试中，我专门用 boce 测试了 Cloudflare Free 下的主站首页。
第一次测试结果并不理想：
| 线路 | 平均响应 |
|---|---|
| 全部平均 | 5.245s |
| 电信平均 | 0.967s |
| 移动平均 | 7.286s |
| 联通平均 | 7.341s |
这个结果非常典型。
电信线路还可以，但移动和联通明显偏慢。
后来再次测试，Cloudflare Free 又恢复到比较好的状态：
| 线路 | 平均响应 |
|---|---|
| 全部平均 | 1.256s |
| 电信平均 | 1.033s |
| 移动平均 | 1.799s |
| 联通平均 | 0.895s |
这说明 Cloudflare Free 的问题不是“永远慢”，而是：
它在中国大陆访问时波动比较大。
如果只测到第二次结果，很容易认为 Cloudflare Free 也不错；但如果刚好遇到第一次那种状态，移动和联通用户的体验就会很差。
对于普通网站来说，这可能只是偶尔慢一点。
但对于依赖搜索流量、广告展示、联盟营销转化的 WordPress 博客来说，这种波动就值得认真处理。
四、EdgeOne 上线后的 boce 第一次测试
迁移到腾讯云 EdgeOne 后，我先做了第一次 boce 测试。
这次测试结果如下：
| 线路 | 最快响应 | 最慢响应 | 平均响应 |
|---|---|---|---|
| 全部 | 0.11s | 8.46s | 2.806s |
| 电信 | 0.11s | 8.36s | 3.451s |
| 移动 | 0.13s | 8.19s | 2.444s |
| 联通 | 0.13s | 8.46s | 2.529s |
单看第一次 EdgeOne 测试，并不能说它已经完全稳定。
它比 Cloudflare Free 最差那次的 5.245s 好，但仍然存在几个问题：
全部平均响应还有 2.806s
电信平均达到 3.451s
最慢节点仍然超过 8s
不可访问节点有 3 个
所以如果只看这一次测试，我不会轻易下结论说 EdgeOne 已经明显胜出。
这也是 CDN 测试里很容易踩坑的地方：
单次测试不能代表长期效果，尤其是刚迁移 DNS、刚部署规则、刚切换边缘网络时，结果可能会有明显波动。
五、EdgeOne 上线后的 boce 第二次测试
过了一会儿，我又跑了第二次 boce 测试。
这次结果明显好很多：
| 线路 | 最快响应 | 最慢响应 | 平均响应 |
|---|---|---|---|
| 全部 | 0.02s | 5.07s | 0.354s |
| 电信 | 0.04s | 1.16s | 0.154s |
| 移动 | 0.02s | 5.07s | 0.578s |
| 联通 | 0.02s | 3.55s | 0.308s |
这个结果就非常接近我希望看到的状态了。
尤其是三大运营商平均响应：
电信：0.154s
移动：0.578s
联通：0.308s
相比 Cloudflare Free 最差那次：
电信：0.967s
移动：7.286s
联通：7.341s
改善非常明显。
不过这里也要保守一点看待。
第二次截图中检测进度显示为 97%，并且仍然有 2 个不可访问节点。所以这不是一个“完美结果”，但已经足够说明：
EdgeOne 在中国大陆主流节点上的整体响应，比 Cloudflare Free 最差状态稳定得多，也比 CDN 上线前明显更好。
六、boce 三阶段核心对比
把几个阶段放在一起看，会更清楚。
| 阶段 | 代表性平均响应 | 说明 |
|---|---|---|
| CDN 上线前 | 4–5s | 源站直连，整体偏慢 |
| Cloudflare 上线后 | 1–2s | 缓存闭环后明显改善 |
| Cloudflare Free 波动时 | 5.245s | 移动、联通明显变慢 |
| EdgeOne 第一次测试 | 2.806s | 刚迁移后仍有波动 |
| EdgeOne 第二次测试 | 0.354s | 国内多线路表现明显改善 |
这张表可以得出一个比较稳的结论：
Cloudflare Free 在缓存闭环正常时，确实能让网站比 CDN 上线前更快；但在中国大陆访问场景下，它的波动比较大。EdgeOne 上线后，第二次 boce 测试的平均响应已经降到 0.354s，国内访问表现明显更符合中文主站的需求。
但我不会把结论写成“EdgeOne 永远比 Cloudflare 快”。
更准确的说法应该是：
对我的这个 WordPress 主站来说，在当前源站位于阿里云杭州 ECS、主要流量来自中国大陆的前提下，EdgeOne 比 Cloudflare Free 更适合作为 www 主域名的统一加速层。
七、WebPageTest 三阶段对比
boce 主要看中国大陆多节点响应。
WebPageTest 则更适合看页面加载过程，包括：
TTFB
FCP
LCP
Speed Index
CLS
TBT
请求数
页面体积
总加载时间
之前 CDN 上线前和 Cloudflare 上线后的 WebPageTest 数据如下：
| 指标 | CDN 前 | Cloudflare 后 |
|---|---|---|
| TTFB | 0.668s | 0.175s |
| FCP | 2.053s | 0.907s |
| LCP | 2.261s | 1.217s |
| Speed Index | 2.353s | 1.787s |
| Requests | 76 | 78 |
Cloudflare 上线后，WebPageTest 核心指标明显改善。
特别是 TTFB，从 0.668s 降到 0.175s，说明页面首字节返回速度提升非常明显。
这也是我之前判断 Cloudflare 缓存闭环有效的主要依据。
八、EdgeOne 上线后的 WebPageTest 结果
迁移到 EdgeOne 后，我重新跑了一次 WebPageTest。
EdgeOne 上线后的核心数据如下：
| 指标 | EdgeOne 后 |
|---|---|
| TTFB | 0.167s |
| FCP | 0.608s |
| LCP | 0.863s |
| CLS | 0.038 |
| Start Render | 0.7s |
| Speed Index | 1.617s |
| TBT | 0.126s |
| Page Weight | 2MB |
| Total Requests | 76 |
| Total Time | 10.94s |
从核心体验指标看，EdgeOne 后的表现是很不错的。
尤其是：
TTFB：0.167s
FCP：0.608s
LCP：0.863s
Speed Index：1.617s
这些指标说明：
HTML 首字节返回很快
首屏内容出现很快
最大内容绘制已经进入 1 秒以内
页面视觉完成速度继续改善
这比 Cloudflare 上线后的 WebPageTest 数据还要略好。
九、WebPageTest 三阶段核心对比表
把三阶段数据放在一起：
| 指标 | CDN 前 | Cloudflare 后 | EdgeOne 后 |
|---|---|---|---|
| TTFB | 0.668s | 0.175s | 0.167s |
| FCP | 2.053s | 0.907s | 0.608s |
| LCP | 2.261s | 1.217s | 0.863s |
| Speed Index | 2.353s | 1.787s | 1.617s |
| CLS | 未记录 | 0.042 | 0.038 |
| TBT | 未记录 | 0.073s | 0.126s |
| Requests | 76 | 78 | 76 |
| 页面体积 | 约 2MB | 2MB | 2MB |
| Fully Loaded / Total Time | 未记录 | 5.795s | 10.94s |
这张表里有几个关键信号。
第一，EdgeOne 后的 TTFB 与 Cloudflare 后非常接近，并且略低：
Cloudflare 后：0.175s
EdgeOne 后：0.167s
这说明迁移到 EdgeOne 后，HTML 首字节没有变差。
第二，EdgeOne 后的 FCP、LCP、Speed Index 都继续改善：
FCP：0.907s → 0.608s
LCP：1.217s → 0.863s
Speed Index：1.787s → 1.617s
这说明从 WebPageTest 的核心体验指标看，EdgeOne 没有拖慢页面，反而比 Cloudflare 后的测试结果更好。
第三，TBT 从 0.073s 上升到 0.126s。
这个值虽然变高了，但仍然不算严重。后续如果要继续优化，可以再看 JS 执行、插件脚本、广告脚本、第三方资源等因素。
第四，Total Time 从 5.795s 上升到 10.94s。
这个指标需要单独看，不能直接等同于“用户体感变慢”。
因为用户最先感受到的是：
TTFB
Start Render
FCP
LCP
Speed Index
而 Total Time 可能受后续图片、统计脚本、广告脚本、低优先级资源影响。
从这次截图看，页面核心指标已经很好，但长尾资源仍然值得继续排查。
十、Request Table 观察：首页 HTML 已经不是瓶颈
WebPageTest 的 Request Table 里，第一个请求是首页 HTML：
资源：https://www.shuijingwanwq.com/
Content Type：text/html
DNS：84ms
Connection：30ms
SSL：57ms
First Byte：39ms
Content：85ms
Downloaded：48695B
这个结果说明：
首页 HTML 本身已经非常快，不再是主要瓶颈。
也就是说，EdgeOne 接入后，主 HTML 的边缘返回表现是正常的。
后续如果还要优化 Total Time，更应该关注：
图片体积
CSS / JS 数量
插件资源
第三方脚本
广告脚本
统计脚本
首屏大图
在截图中可以看到一个比较明显的点：
/wp-content/uploads/2026/05/logo.png
Downloaded：884150B
Content：1904ms
这个文件接近 900KB，对于 logo 来说偏大。
后续可以考虑：
压缩图片
改成 WebP
控制实际显示尺寸
减少首屏大图体积
检查是否存在不必要的大图加载
这部分已经不是 CDN 选型问题，而是页面资源优化问题。
十一、这次对比得出的结论
这次对比后，我的结论分成三层。
1. CDN 上线前，网站确实偏慢
CDN 上线前，boce 平均响应大约 4–5s，WebPageTest 的 TTFB 是 0.668s，FCP 和 LCP 都在 2 秒以上。
这说明当时源站直连状态下，网站性能还有明显优化空间。
2. Cloudflare 上线后，缓存闭环确实有效
Cloudflare 上线后，WebPageTest 指标明显改善：
TTFB：0.668s → 0.175s
FCP：2.053s → 0.907s
LCP：2.261s → 1.217s
Speed Index：2.353s → 1.787s
所以不能简单说 Cloudflare Free 没有价值。
它确实让 WordPress 缓存闭环变得有效，也确实改善了 WebPageTest 的核心指标。
问题在于：
Cloudflare Free 在中国大陆访问时，尤其是移动、联通线路，波动比较明显。
3. EdgeOne 更适合当前这个中文主站
EdgeOne 上线后，第二次 boce 测试平均响应降到 0.354s。
WebPageTest 核心指标也继续改善：
TTFB：0.167s
FCP：0.608s
LCP：0.863s
Speed Index：1.617s
这说明 EdgeOne 至少在当前测试条件下，比较符合我的目标：
不换主域名
不拆 /en/ 英文目录
不新增 cn 子域名
继续使用同一个 www 主站
改善中国大陆访问
保持 WebPageTest 核心指标
十二、最终判断
这次迁移不是因为 Cloudflare 不好。
Cloudflare Free 依然是非常优秀的全球 CDN，尤其适合海外访问、静态资源缓存、低成本全球加速。
但对于我的这个 WordPress 主站来说，情况比较特殊：
源站在阿里云杭州 ECS
域名已经备案
主要访问用户在中国大陆
同时存在 /en/ 英文目录
不希望拆分主域名结构
不希望重做 Polylang SEO 结构
在这个前提下，腾讯云 EdgeOne 更适合当前阶段。
从 boce 看，EdgeOne 第二次测试的国内平均响应已经降到 0.354s。
从 WebPageTest 看，EdgeOne 后的 TTFB、FCP、LCP、Speed Index 都保持在比较理想的水平。
所以我现在更倾向于把结论写成：
Cloudflare Free 解决了 WordPress 缓存闭环问题，但没有完全解决中国大陆线路波动问题。EdgeOne 在不改变 WordPress 主站结构的前提下，进一步改善了中国大陆访问表现，同时没有明显牺牲 WebPageTest 的核心页面性能指标。
这也是这次从 Cloudflare Free 迁移到腾讯云 EdgeOne 后，最重要的实测价值。
十三、后续还需要继续观察的点
这次数据已经比较有参考价值，但还不能说所有问题都彻底结束。
后续我还会继续观察几个点：
boce 多次测试是否长期稳定
移动、联通线路是否还会偶发变慢
Google Search Console 核心网页指标是否变化
Bing 和百度抓取是否正常
EdgeOne HTML 缓存是否需要接入自动刷新
Total Time 偏高是否来自图片或第三方脚本
尤其是 Total Time 10.94s 这个指标，虽然不影响当前对 TTFB、FCP、LCP 的判断，但后续仍然值得单独优化。
下一步可能重点处理：
压缩 logo.png
检查首屏图片体积
减少不必要插件资源
继续观察 EdgeOne 缓存命中
考虑 EdgeOne API 自动清缓存
到目前为止，这次迁移可以认为是成功的。
它没有改变 WordPress 结构，没有拆英文站，也没有影响后台访问；同时，国内访问和 WebPageTest 核心指标都保持在更理想的范围内。
Linux 服务器运维、部署与线上故障排查
如果你的网站或后端服务部署在 Linux 服务器上，遇到访问异常、Nginx 配置问题、MySQL / Redis 异常、Docker 服务不可用、磁盘占满、CPU / 内存过高等问题，可以联系我做一次远程排查。
适合以下场景：
✅ 网站打不开或访问不稳定
✅ Nginx / PHP-FPM 配置异常
✅ MySQL / Redis 性能或连接问题
✅ Docker 服务部署与维护
✅ 服务器迁移与环境配置
✅ CPU / 内存 / 磁盘异常排查
服务内容：
✅ Linux 环境检查
✅ 网站部署与迁移
✅ Nginx / PHP-FPM / MySQL / Redis 排查
✅ Docker 配置与维护
✅ 服务器性能分析
✅ 长期远程运维支持
如需咨询，请联系我，并注明：Linux 运维咨询。
联系方式：
Telegram：@shuijingwan
微信：13980074657
邮箱：shuijingwanwq@gmail.com
发表回复