减少 Time to First Byte 中 waiting duration 子部分

减少 Time to First Byte 的 waiting duration

Time to First Byte (TTFB) 可以分解为以下子部分：

• Waiting + Redirect（或 waiting duration）
  
• Worker + Cache（或 cache duration）
• DNS（或 DNS duration）
• Connection  （或 connection duration）
• Request（或 request duration）

想要优化 Time to First Byte？本文深入分析了 Time to First Byte 中 waiting duration 部分。如果您想了解或修复 Time to First Byte，但不知道 waiting duration 的含义，请先阅读 [url=/core-web-vitals/time-to-first-byte]什么是 Time to First Byte[/url] 和 [url=/core-web-vitals/time-to-first-byte/fix-and-identify]修复和识别 Time to First Byte 问题[/url]，然后再开始阅读本文

重定向会对 Time to First Byte (TTFB) 产生重大影响，因为每次重定向都会增加浏览器从服务器接收第一个字节数据所需的时间。以下是重定向如何影响 TTFB：

重定向如何增加 Time to First Byte？

重定向通常包含在完整的 TTFB 测量中（见蓝色框）。这意味着所有重定向所花费的时间都会计入整体 TTFB 分数，可能使其看起来比预期更高。

当页面被重定向时，通常会发生以下步骤：

• 浏览器向原始 URL 发送初始请求。
  
• 服务器处理此请求并返回重定向状态码（例如 301 或 302）。
  
• 浏览器随后向重定向的 URL 发送新请求。服务器处理第二个请求并开始发送实际内容。

增加的服务器处理时间

这种额外的处理增加了整体 TTFB，因为每个步骤都需要服务器花费时间来处理请求和响应。

重定向链

在某些情况下，在到达最终目的地之前可能会发生多次重定向。这会创建一个"重定向链"，可能会显著增加 TTFB。链中的每次重定向都会增加自己的处理时间，从而在接收到实际内容的第一个字节之前增加延迟。

网络延迟

重定向通常涉及客户端和服务器之间额外的网络往返。这会引入额外的网络延迟，特别是当重定向涉及不同的域名或服务器时。每次重定向中客户端和服务器之间的物理距离会进一步影响 TTFB。

JavaScript 重定向 vs 服务器端重定向：只有服务器端重定向（使用 30x 重定向头的）会被添加到 Time to First Byte 中。JavaScript 重定向不会被添加到 Time to First Byte 中，因为服务器已经发送了完整的响应（200）。

有人可能会认为应该优先使用 JavaScript 重定向，因为它们不会增加 Time to First Byte。不幸的是，JavaScript 重定向对真实用户来说要慢得多，并且会导致糟糕的 User Experience。

对 User Experience（和 SEO）的影响

虽然重定向有时是必要的，但它们对 TTFB 的影响可能会产生更广泛的影响：

• User Experience：由于重定向导致的较慢 TTFB 可能会延迟页面的初始渲染，可能会让用户感到沮丧。
• SEO：虽然 TTFB 不是直接的排名因素，但它会影响其他指标，如 Largest Contentful Paint (LCP)，这是搜索引擎考虑的 Core Web Vitals 之一。

如何测量由重定向引起的 TTFB 问题

要了解真实用户因重定向而受到的影响，您需要使用像 CoreDash 这样的 RUM 工具。Real User Monitoring 将让您详细跟踪 Core Web Vitals。

在 CoreDash 中，只需点击"redirect count"即可按重定向次数对数据进行可视化分割。然后，例如点击"1 redirect"分段，按"1 redirect"过滤 RUM 数据并查看所有受影响的 URL。  

如何最小化重定向影响

作为一般规则，遵循以下 3 个简单步骤来避免重定向问题：

• 尽可能减少重定向的使用。
  
• 通过更新链接直接指向最终目标 URL 来避免重定向链。
• 尽可能使用服务器端重定向而非客户端重定向，因为它们通常更快。

同源重定向。同源重定向来自您自己网站上的链接。您应该完全控制这些链接，并且在优化 Time to First Byte 时应优先修复这些链接。查找这些内部重定向的典型方法是使用任何可用的 [url=https://www.marketingtracer.com/]工具[/url] 来检查整个网站的重定向情况。

跨源重定向。跨源重定向来自其他网站上的链接。您对这些链接的控制非常有限。对于产生大量流量的高影响链接，请考虑联系该网站的管理员以更新链接的 URL。

重定向链。多次重定向或重定向链发生在单次重定向没有重定向到资源的最终位置时。这些类型的重定向对 Time to First Byte 造成更大的压力，应不惜一切代价避免。同样，使用 [url=https://www.marketingtracer.com/]工具[/url] 来查找这些类型的重定向并修复它们！

HTTP 到 HTTPS 重定向。解决此问题的一种方法是使用 Strict-Transport-Security 头（HSTS），它将在首次访问时强制使用 HTTPS，然后告诉浏览器在以后的访问中立即通过 HTTPS 方案访问该源。

一般来说，我们建议：

1. 定期检查和更新您的内部链接！每当您更改页面的位置时，请更新指向该页面的内部链接，以确保不存在对早期页面位置的引用。
   
2. 在服务器级别处理重定向。首选的重定向方法是 301 重定向。301 重定向是永久重定向，而 302 重定向是临时重定向。例如，临时重定向可能不会在搜索引擎中得到更新。
   
3. 使用相对 URL：在链接到您自己网站上的页面时，使用相对 URL 而不是绝对 URL。这将有助于防止不必要的重定向。
   
4. 使用规范 URL：如果您有多个内容相似的页面，请使用规范 URL 来指示该页面的首选版本。这将有助于防止重复内容和不必要的重定向。