重定向延迟检测

一次重定向就是一次完整的额外请求。浏览器必须查询下一个主机名、建立连接、为新域名协商 TLS 并等待服务器响应，然后才能请求页面本身。同一主机名上的一跳可能只需几十毫秒，而一条经过短链接服务、跟踪域名和 HTTP 到 HTTPS 规则的重定向链，很容易就会增加半秒甚至更多，在移动网络上尤其如此。

重定向时间发生在所有其他环节之前，因此会直接计入 Time to First Byte（TTFB，首字节时间）和 Largest Contentful Paint（LCP，最大内容绘制）。正因为如此，Lighthouse 和 PageSpeed Insights 会对主文档上的重定向发出警告。

对于每一跳，TrueURL 测量从发出请求到收到响应头所用的时间。需要建立新连接时，其中包括 DNS 查询以及 TCP 和 TLS 连接建立的时间，再加上服务器的处理时间，但不包括下载页面正文的时间。瀑布图按顺序显示各跳，最慢的一跳一眼就能看出来。

测量是在执行检测的 Cloudflare 数据中心（通常是离您最近的那个）进行的，而不是在您的设备上。结果反映的是每台服务器的响应速度，而真实访问者在每一跳上还要加上自己的网络延迟。多次运行可以减少偶然波动：第一次运行可能包含 DNS 缓存尚未预热和新建连接的时间，之后的运行通常更接近稳定状态。

以下仅供粗略参考，也是 TrueURL 为每一跳耗时着色所用的标准：

• 每跳低于 200 ms：快，常见于由 CDN 边缘节点或简单的 Web 服务器规则响应的重定向。
• 200～600 ms：可以接受，常见于应用服务器，或者需要建立新 TLS 连接的跨域名重定向。
• 600 ms 及以上：慢。这类重定向很可能是由较重的应用程序生成的，例如需要加载插件或执行数据库查询的 CMS，而不是一条简单的规则。

最有效的优化方法是彻底去掉多余的跳。其次，要尽可能在离访问者近的地方响应重定向：CDN 或边缘规则的响应速度，远远快于仅为了发送一个 301 就必须启动的应用程序。

• 在网站以及邮件、广告和社交媒体资料中直接链接到最终 URL，让大多数访问者根本不会遇到重定向。
• 将 HTTP 到 HTTPS、主机名和斜杠规则合并为一跳；HTTPS 重定向检测可以显示这些规则是否已经合并。
• 在 CDN、负载均衡器或 Web 服务器配置中处理重定向，而不是在应用程序中处理。
• 发送 HSTS 响应头，让回访者完全跳过 HTTP 到 HTTPS 的重定向。
• 避免把多个短链接服务和跟踪重定向层层叠加。