要判断网站接入边缘加速后如何验证首字节时间变化，关键不是只看一次测速结果，而是让前后测试使用同一套条件。先固定页面、地点和指标，再重复采样；同时确认请求是否命中边缘节点，才能知道首字节变快或变慢的原因。
先统一要比较的时间指标
首字节时间常写作 TTFB，但不同工具的计时起点并不完全相同。Chrome 开发者工具的 Network 面板中，选中主文档请求，在 Timing 查看等待服务器响应的时间；Navigation Timing 则可查看 requestStart 到 responseStart 的间隔。前者便于观察请求发出后的等待，后者可用于同一浏览器内的前后对照。
不要把两种口径的数值直接混在一起。DNS 查询、TCP 建连和 TLS 握手可能计入某些页面级 TTFB 口径，却不在 requestStart 至 responseStart 这段间隔内。记录方法时写明工具、字段和单位；若关心用户从导航开始到收到首字节的整体体验，也应始终采用同一个页面级指标。
按同一条件建立前后对照
- 选测试对象：选一个稳定可访问的主文档页面，并另选一两个具有代表性的静态资源。不要把页面首字节与图片资源的首字节放在同一组比较。
- 固定环境：保持测试设备、浏览器版本、网络类型和测试地点一致。若用户分布在不同地区，可分别在各地测试；边缘节点距离不同，结果也可能不同。
- 采集接入前数据：记录每次的时间、页面、网络环境和 TTFB。每组重复约 10—20 次作为起点，分时段采样更能发现网络波动；次数可按环境稳定程度调整。
- 接入后重复测试：等待配置生效后，用相同页面和环境重测。冷启动与重复访问分开记录，因为边缘缓存首次未命中时可能需要回源，之后的访问表现可能不同。
- 汇总而非挑最好值：比较中位数和 p75（第 75 百分位），同时保留样本数。中位数显示典型体验，p75能提示较慢的一部分访问是否改善；单次最低值不能代表整体变化。
读懂变化来自哪里
静态内容变快，先核对边缘命中
检查响应头或边缘服务提供的请求日志，确认该请求是否由边缘节点直接返回。不同服务商的命中标记名称各异，不应只凭某个固定字段判断。若命中访问的 TTFB 降低、未命中访问变化不大，可能说明用户到边缘的路径缩短了，但源站处理时间仍影响首次请求。
动态页面无改善，查看回源链路
边缘加速并不意味着每个页面都能缓存。需要实时生成的页面仍可能由边缘节点转发至源站，首字节时间会受源站排队、计算和边缘至源站网络耗时影响。对照服务日志中的边缘处理时间与回源耗时；如果回源占大头，应先排查源站负载或链路，而不是仅根据边缘节点位置判断效果。
还要留意测试时的连接复用、浏览器缓存、重定向和页面是否实际经过加速配置。若接入后 TTFB 上升，先确认前后访问的是同一主机名和页面版本，再检查边缘是否频繁回源、节点选择是否稳定，以及是否增加了重定向。配置切换期间的数据宜单独标记，不与稳定期样本混算。
结论与常见问题
可靠的结论来自同口径、同环境的重复对照。把测试页面、地点、时间段、命中状态和统计值一并记录，才便于复查网站接入边缘加速后如何验证首字节时间变化，并定位差异究竟发生在用户到边缘，还是边缘回源阶段。
只测首页够不够？
不够。至少再选一种静态资源或不同特征的页面；首页可能有特殊缓存规则，不能代表整个站点。
接入后第一次访问更慢，是否代表加速无效？
不一定。首次访问可能发生回源或缓存填充，应与后续命中访问分开比较，并核对实际命中状态。
应该看平均值还是中位数？
优先看中位数和 p75，并结合样本量。平均值容易受少数特别慢的请求影响，可作为补充，不宜单独下结论。
不同地区的数据能放在一起算吗？
不建议直接合并。先分别比较各地结果，因为网络路径、用户到边缘节点的距离和本地网络状况都会影响 TTFB。
