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+ 次重定向
重定向链。缩短的 URL 重定向到跟踪域名，跟踪域名重定向到您的 HTTP 端点，HTTP 再重定向到 HTTPS。三次跳转，三次往返。通过 URL 进行分组，找出产生这些重定向链的入口点，然后消除中间环节。
重定向的来源
- HTTP 到 HTTPS：过时的内部链接仍然指向
http://。更新所有链接、站点地图和规范标签，直接使用https://。 - www 规范化：www 和非 www 之间存在不一致。在 DNS 级别强制执行其中一个，并更新所有引用。
- CMS slug 更改：旧路径通过 301 重定向到新路径。对于外部反向链接没问题，但要更新每一个内部链接，使其直接指向新的 slug。
- 营销短链 URL：像
/spring-sale这样的短路径重定向到/products/seasonal。每一位访客在每次点击时都要付出延迟的代价。 - 电子邮件和社交媒体中的 URL 缩短器：链接在到达您的域名之前，会经过 Bitly、跟踪像素或电子邮件服务提供商。每项服务都会增加一次您无法控制的往返，但您可以最大限度地减少自身的重定向，从而使总数保持在较低水平。
调试工作流
- 筛选 redir ≥ 1：查看您的总流量中有多少百分比遇到了至少一次重定向。任何高于 15% 的比例都值得调查。
- 按 URL 分组：找出哪些着陆页是重灾区。营销页面和更改了 slug 的旧博客文章往往占主导地位。
- 拆分内部与外部：按 navigation origin 进行筛选。带有重定向的同源流量意味着您自身的链接存在错误。跨源重定向较难修复，但不那么紧迫。
- 修复源头，而不是重定向：不要去优化重定向本身（更快的服务器响应）。通过更新导致重定向的链接来彻底消除它。
工程经验法则
- 所有内部导航 0 次重定向。当您控制源链接时，不允许出现任何来自您自身网站的重定向。
- 在每次 URL 迁移后进行审计。在您更改 slug 或移动页面时，在代码库和 CMS 中使用 grep 查找旧路径。重定向是外部链接的安全网，不能代替更新您自身的引用。
- 在移动设备上为每次重定向预留 150 毫秒的预算。如果您的 TTFB 目标是 800 毫秒，并且用户遇到了两次重定向，那么在服务器进行任何工作之前，您就已经消耗了 300 毫秒。
重定向是最容易发现和修复的 TTFB 收益点。无需更改代码，无需调整服务器，也无需优化资源。只需更新指向错误位置的 URL 即可。