项目验收时，开发者在办公室打开网站很快，异地同事第一次访问却要等很久。双方说的可能都是真的：一个复用了连接和缓存，另一个经历了完整的跳转、连接与回源。要把“网站慢”变成能处理的工单，先固定测试条件，再拆请求阶段。
先约定测的是哪一次访问
给技术团队的记录至少包含完整入口 URL、最终 URL、测试时间与时区、所在地区、网络、浏览器、是否登录，以及首次访问还是再次刷新。入口地址尤其重要：从旧推广链接进入和直接打开最终页面，可能多经过几次重定向。
对同一入口分别记录首次导航和再次访问，不要拿开发者登录后的页面与客户未登录的页面直接比较。浏览器缓存、CDN 缓存和应用缓存是不同层次；关闭浏览器缓存，并不能证明这次请求没有命中 CDN。
把等待分给正确的环节
web.dev 对 TTFB 的说明把导航首字节时间分成重定向、适用的 Service Worker 启动、DNS、连接与 TLS，以及请求至首字节到达等阶段。它是诊断指标，不是 Core Web Vitals 之一。网络面板里单个请求的等待时间，也不宜直接当作整次导航耗时。
- 只有旧入口慢，最终地址快：保存完整跳转链，先检查是否绕行了旧域名或协议版本。
- 异地首次访问慢，再次访问明显变快：查看连接复用和缓存命中情况，再判断是否需要调整边缘分发。
- 相近地区也慢，服务端日志显示处理时间长：沿着请求标识查应用、数据库和依赖服务。
- 文档很快返回，屏幕仍长时间空白：转向脚本、接口数据与渲染排查，不要继续只盯服务器首字节。
这些是排查方向，不是凭一个现象就能下的根因结论。需要中文解释各阶段和对应处理方向时，可参考光算的TTFB 分阶段排查资料，再把本次实际请求证据附到工单中。
一张工单只验证一个改动
可以这样写验收任务：“固定同一个入口和未登录状态，保留改动前后的请求瀑布图；删除一段已确认多余的跳转后，从原测试地区复测，并检查最终页面和表单仍正常。”这是操作示例，并非任何项目的实测结果。
如果决定增加缓存，先明确哪些页面允许共享。账户、购物车和个性化响应不能为了缩短等待而被错误地缓存给其他用户。若使用 103 Early Hints 等提前响应机制，还要记录工具实际测到的是哪种首字节口径，避免改的是测量表现，正文到达却没改善。
最后交付原始记录、改动项、复测条件和仍未解释的差异。一次更快的刷新只能证明这个样本变快，不能代表所有地区的真实用户都已改善；首字节变快之后，仍要确认主要内容是否及时显示。