Trusted by market leaders · Client results
维度：导航：重定向次数 (redir)
redir 维度计算到达最终页面前的 HTTP 重定向次数。有效值为 0、1、2 或 3+。每次重定向都是一次完整的网络往返，甚至发生在服务器开始生成 HTML 之前。
在 100 毫秒 RTT 的连接上，一次重定向会为 TTFB 增加 100 毫秒。在 200 毫秒的移动网络连接上，这个时间会翻倍。在移动设备上的两次重定向意味着：在浏览器接收到页面的第一个字节之前，有 400 毫秒的纯粹等待。这种延迟在直接访问最终 URL 的实验室测试中是不可见的，但跟随链接、书签或搜索结果的真实用户在每次访问时都会承受这种延迟。
各个值的含义
0 次重定向
理想状态。浏览器在第一次请求时直接命中了最终 URL。所有的内部导航都应产生这个值。如果您站点的链接、站点地图和规范标签是正确的，内部流量应保持在 0。
1 次重定向
在外部流量中很常见：HTTP 升级到 HTTPS、www 规范化，或营销活动的 URL。对于您无法控制的入站链接是可以接受的。但对于您自己的内部链接是不可接受的。如果 CoreDash 在内部导航上显示 1 次重定向，意味着您的链接指向了旧的或不一致的 URL。
2 次以上重定向
重定向链。短链接重定向到跟踪域名，该域名又重定向到您的 HTTP 端点，然后再重定向到 HTTPS。三次跳转，三次往返。按 URL 进行分组以查找是哪些入口点创建了这些重定向链，然后消除这些中间环节。
重定向从何而来
- HTTP 到 HTTPS：过时的内部链接仍然指向
http://。请更新所有链接、站点地图和规范标签，直接使用https://。 - www 规范化：www 和非 www 之间的不一致。请在 DNS 层强制使用其中之一，并更新所有的引用。
- CMS slug 更改：旧路径通过 301 重定向到新路径。这对外部反向链接来说没问题，但必须更新每个内部链接，使其直接指向新的 slug。
- 营销短网址：像
/spring-sale这样的短路径重定向到/products/seasonal。每次点击都会让访问者承担延迟成本。 - 电子邮件和社交媒体中的短链接：链接在到达您的域名之前，经过了 Bitly、追踪像素或电子邮件服务提供商。每一项服务都会增加一次您无法控制的网络往返，但您可以最大限度地减少自身的重定向，以保持总体次数处于较低水平。
调试工作流
- 过滤 redir ≥ 1：查看总流量中有多少百分比至少命中了一次重定向。任何高于 15% 的比例都值得调查。
- 按 URL 分组：找出哪些着陆页是重灾区。营销页面和更改了 slug 的旧博客文章通常占据主导地位。
- 分离内部和外部来源：按 navigation origin 进行过滤。带有重定向的同源流量意味着您自己的链接有误。跨源重定向较难修复，但紧迫性较低。
- 修复源头，而非重定向：不要优化重定向本身（例如寻求更快的服务器响应）。应该通过更新导致重定向的链接来彻底消除它。
工程经验法则
- 所有内部导航均为 0 次重定向。当您能够控制来源链接时，自己网站产生任何重定向都是不可接受的。
- 在每次 URL 迁移后进行审计。当您更改 slug 或移动页面时，在代码库和 CMS 中 grep 搜索旧路径。重定向是外部链接的安全网，但绝不能替代更新自身的内部引用。
- 在移动端为每次重定向留出 150 毫秒的预算。如果您的 TTFB 目标是 800 毫秒，而用户命中了两次重定向，那么在服务器开始任何工作之前，您就已经消耗了 300 毫秒。
重定向是查找和修复以提升 TTFB 最容易的切入点。无需修改代码，无需调整服务器，也无需优化资源。只需更新指向错误位置的 URL 即可。