什么是 RTT？它为何如此重要？
往返时间（RTT）是信号到达通信对端并返回所需的时间。它不等于完整响应时间，DNS、连接建立、服务端处理和传输都可能增加耗时。并行请求并不一定会按请求数量逐个累加 RTT。
RTT 如何影响 Web Vitals
- LCP： HTML 和关键资源的延迟可能推迟主要内容显示。
- INP： 测量操作到下一次绘制的响应，而不是异步请求完成时间。搜索结果可能很慢，但 INP 仍然良好，应分别测量。
- TTFB： 不只是一次 RTT，还可能包括连接建立和服务端处理；它本身不属于 Core Web Vitals。
- CLS： 未预留空间的资源迟到时可能引起布局偏移，但 RTT 高本身并不意味着一定会偏移。
RTT 偏高的常见原因
- 源服务器距离较远，或 CDN 与后端之间存在额外路径；
- 互相依赖的请求和重定向链；
- 可以复用却重复新建的连接；
- 发现过晚的关键第三方资源；
- 服务端处理缓慢，仅看总耗时可能误判为网络问题。
如何降低 RTT
- 比较地区，考虑靠近受众的 CDN 或计算服务，并确认哪些响应实际由边缘节点提供。
- 测试环境支持的 HTTP/2 与 HTTP/3。它们不会消除物理距离，HTTP/2 仍有 TCP 层面的队头阻塞。
- 缓存带版本的静态资源；HTML 与 API 应满足时效性和隐私要求。
- 仅为确认关键的资源使用
<link rel="preconnect">、dns-prefetch或字体 preload。提示不会缩短物理 RTT。 - 删除无用请求，推迟非关键 JavaScript。懒加载适用于首屏以下的合适内容，不适用于 LCP 图片。
- 减少重定向，复用连接或 TLS 会话。0-RTT 和证书优化应按实际环境验证。
利用 Milten 的结果调查 RTT
- 在测试条件下比较网络诊断中的 RTT、服务端延迟及各个源的传输性能。
- 检查资源提示和瀑布图，特别是 LCP/FCP 之前的请求。缺少提示只是调查线索，并不意味着必须添加。
- 区分服务端处理与传输延迟。
- 发布后重复测试。比较地区时，应确认可用设置并保持条件一致。
快速修复清单
- 找出缓慢的源和关键请求链；
- 检查浏览器–边缘节点，以及必要时边缘节点–源站的实际协议；
- 只添加有效的连接与预加载提示；
- 保留正确的最终 URL，减少无用重定向；
- 使用缓存或 stale-while-revalidate 时保证隐私和时效性；
- 比较多个等效测试及真实访问数据。
从测量开始
在 milten.io 运行 Speed Scanner，检查网络结果并选择一个已确认的瓶颈。保存初始结果和条件，做一项明确修改后再比较。
