首次字节时间（TTFB）

作者：林语者 分类：工程代码

什么是TTFB？

首字节时间（TTFB）是一个关键性能指标，用于在实验室环境和真实用户环境中衡量连接建立时间和Web服务器的响应能力。它有助于识别Web服务器响应请求过慢的情况。对于导航请求（即HTML文档请求），该指标优先于其他重要的加载性能指标。

TTFB衡量的是从资源请求发出到接收到响应第一个字节之间的时间。

graph LR
    A[Request Start] --> B[Redirect Time]
    B --> C[Service Worker Startup]
    C --> D[DNS Lookup]
    D --> E[Connection & TLS Negotiation]
    E --> F[Request Processing]
    F --> G[First Byte Received]

上图展示了网络请求的各个阶段及其相关时间。TTFB测量的是从startTime到responseStart之间经过的时间。

TTFB包含以下请求阶段的总和：

  • 重定向时间
  • Service Worker启动时间（如适用）
  • DNS查询
  • 连接和TLS协商
  • 请求处理（直到响应第一个字节到达）

通过减少连接建立时间和后端延迟，可以有效降低TTFB。

TTFB与早期提示

103早期提示的引入让人们对TTFB中”第一个字节”的测量内容产生了一些困惑。实际上，103早期提示会被计入”第一个字节”的测量。finalResponseHeadersStart是一个新增的时间记录点，用于测量最终文档响应（通常是HTTP 200响应）的开始时间。

注意：基于社区反馈，Chrome 115曾将responseStart（及TTFB）更新为测量最终文档响应的开始时间（后来标准化为finalResponseHeadersStart）。但由于这导致了许多工具的兼容性问题，Chrome 133又恢复了原来的行为。

早期提示只是早期响应的一个新例子。有些服务器可以在主体内容可用之前提前刷新文档响应，这可能通过仅使用HTTP头信息或使用<head>元素来实现。这两种情况都会产生与早期提示类似的效果，这就是为什么它们都会被计入responseStart测量，从而影响TTFB。

我们建议在完整响应需要较长时间生成时，尽早返回数据。然而，根据使用的功能及其对TTFB测量的影响，在不同平台和技术之间比较TTFB可能会很困难。最重要的是要理解您使用的工具测量的指标，以及该指标如何受到测量平台的影响。

合适的TTFB值

由于TTFB先于首次内容绘制（FCP）和最大内容绘制（LCP）等以用户为中心的指标，我们建议服务器应足够快速地响应导航请求，以确保75百分位的用户能够在”良好”阈值内体验到FCP。作为一般指导原则，大多数网站应将TTFB控制在0.8秒以内。

graph TD
    A[TTFB评估] --> B{TTFB值}
    B -->|≤0.8秒| C[良好]
    B -->|0.8-1.8秒| D[需要改进]
    B -->|≥1.8秒| E[较差]

关键点：TTFB不是Core Web Vitals指标，因此除非它损害了在关键指标上获得高分的能力，否则网站不需要强制满足”良好”TTFB阈值。

不同场景下的TTFB考量

不同网站的内容交付方式各不相同。较低的TTFB意味着可以尽快将标记发送到客户端。然而，如果网站虽然快速交付了初始标记，但需要JavaScript才能为该标记填充有意义的内容（例如单页应用程序SPA），那么尽可能降低TTFB对于加快客户端的标记渲染尤为重要。

相反，对于不需要太多客户端工作的服务器渲染网站，虽然TTFB可能较高，但它们的FCP和LCP值可能优于完全客户端渲染的网站。因此，TTFB阈值应被视为”粗略指南”，需要结合网站交付核心内容的方式来考虑。

如何测量TTFB

TTFB可以在实验室环境或真实用户环境中通过以下工具测量：

现场工具

  • Chrome用户体验报告
  • web-vitals JavaScript库

实验室工具

  • Chrome DevTools网络面板
  • WebPageTest

使用JavaScript测量TTFB

可以使用Navigation Timing API测量浏览器导航请求的TTFB。以下示例展示了如何创建PerformanceObserver来监听navigation条目并将其记录到控制台：

new PerformanceObserver((entryList) => {
  const [pageNav] = entryList.getEntriesByType('navigation');
  console.log(`TTFB: ${pageNav.responseStart}`);
}).observe({
  type: 'navigation',
  buffered: true
});

使用web-vitals JavaScript库可以更简洁地测量TTFB：

import {onTTFB} from 'web-vitals';
// 一旦TTFB可用就立即测量并记录
onTTFB(console.log);

测量资源请求

TTFB不仅适用于导航请求，也适用于所有请求。特别是托管在跨源服务器上的资源，由于需要与这些服务器建立连接，可能会产生延迟。要在现场环境中测量资源的TTFB，可以在PerformanceObserver中使用Resource Timing API：

new PerformanceObserver((entryList) => {
  const entries = entryList.getEntries();
  for (const entry of entries) {
    // 由于资源被缓存，或跨源资源未设置Timing-Allow-Origin头，
    // 某些资源的responseStart值可能为0
    if (entry.responseStart > 0) {
      console.log(`TTFB: ${entry.responseStart}`, entry.name);
    }
  }
}).observe({
  type: 'resource',
  buffered: true
});

上述代码片段与测量导航请求TTFB的代码类似，但查询的是’resource’条目而非’navigation’条目。它还考虑了某些资源可能返回0值的情况，这可能是因为连接已经打开，或者资源从缓存中立即获取。

如果跨源服务器未设置Timing-Allow-Origin头，则无法在现场环境中测量跨源请求的TTFB。

如何改善TTFB

有关改善网站TTFB的具体方法，请参阅TTFB优化详细指南。

评论

发表评论

正在加载评论...