加载第一个字节所需时间 (TTFB)

Jeremy Wagner
Barry Pollard

浏览器支持

  • Chrome：43。 <ph type="x-smartling-placeholder">
  • Edge：12。 <ph type="x-smartling-placeholder">
  • Firefox：35。 <ph type="x-smartling-placeholder">
  • Safari：11. <ph type="x-smartling-placeholder">

来源

<ph type="x-smartling-placeholder">

什么是 TTFB？

TTFB 指标用于衡量从请求资源到响应的第一个字节开始到达的时间点之间的时长。

<ph type="x-smartling-placeholder">
</ph> 网络请求时间的可视化。从左到右的顺序分别是重定向、Service Worker Init、Service Worker Fetch 事件、HTTP Cache、DNS、TCP、请求、早期提示 (103)、响应（与卸载提示重叠）、处理和加载。关联的计时包括 redirectStart 和 redirectEnd、fetchStart、domainLookupStart、domainLookupEnd、connectStart、secureConnectionStart、connectEnd、requestStart、interimResponseStart、responseStart、unloadEventStart、unloadEventEnd、responseEnd、domInteractive、domContentLoadedEventStart、domContentLoadedEventEnd、domComplete、loadEventStart 和 loadEventEnd。 <ph type="x-smartling-placeholder">
</ph> 网络请求阶段及其相关时间的示意图。TTFB 测量 startTime 和 responseStart 之间的用时。

TTFB 是以下请求阶段的总和：

  • 重定向时间
  • Service Worker 启动时间（如果适用）
  • DNS 查找
  • 连接和 TLS 协商
  • 请求，直到收到响应的第一个字节为止

减少连接设置时间和后端的延迟可以降低 TTFB。

TTFB 的其他定义

之前的定义是传统定义，但引入了 Early Hints，即被视为“第一个字节”可以进行辩论。firstInterimResponseStart 是 responseStart 中新增的一个新计时条目，用于区分这二者，但只有 Chrome 和基于 Chromium 的浏览器支持此功能。因此，某些浏览器和工具（包括 CrUX）会在收到第一批字节（包括 Early Hints）之前进行测量。

“早期提示”只是一个较新的“及早响应”示例。某些服务器允许在正文可用之前刷新文档响应，要么仅使用 HTTP 标头，要么使用 <head> 元素，这两种方式在效果上都与 Early Hints 类似，因此也会使 TTFB 测量的定义模糊不清。

衡量“第一个字节”文档可操作数据的数量，那么所有这些定义都可以被视为有效。如果完整响应需要更多时间，那么尽早发回数据具有真正的价值。最重要的是，了解您所使用的工具衡量的是哪种指标，以及所衡量平台对衡量效果有何影响。这也使得很难根据不同平台或技术使用的功能，以及这对所使用的 TTFB 衡量结果的影响而比较 TTFB。

TTFB 通常也被视为服务器或主机响应时间的指标。但是，它会受到直接控制之外的因素（例如重定向时间）的影响，无论是从被 CDN 命中的缓存中传送，还是必须等待更长的时间返回源服务器。这一点在现场数据中尤为明显 - 实验室测试通常受这些因素的影响较小，因为结束网址通常会进行测试，并且经常会反复取消缓存更改。为清楚起见，Lighthouse 报告服务器响应时间，而不是 TTFB，但其他实验室工具可能不会报告。

什么是良好的 TTFB 得分？

由于 TTFB 会先于以用户为中心的指标（例如 First Contentful Paint (FCP) 和 Largest Contentful Paint (LCP)），因此建议服务器对导航请求做出足够快速的响应，以便 75% 的用户体验“良好”内的 FCP阈值。一般而言，大多数网站应力求将 TTFB 控制在 0.8 秒或更短。

<ph type="x-smartling-placeholder">
</ph> <ph type="x-smartling-placeholder"></ph> 良好的 TTFB 值不超过 0.8 秒，不良值超过 1.8 秒，介于两者之间的所有值都需要改进
良好 TTFB 值不超过 0.8 秒，不良值大于 1.8 秒。

如何衡量 TTFB

可以通过以下方式在实验室或现场测量 TTFB。

实地工具

实验工具

在 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';

// Measure and log TTFB as soon as it's available.
onTTFB(console.log);

衡量资源请求量

TTFB 适用于所有请求，而不仅仅是导航请求。特别是，在跨源服务器上托管的资源可能会导致延迟，因为需要与这些服务器建立连接。如需衡量现场资源的 TTFB，请在 PerformanceObserver 中使用 Resource Timing API：

new PerformanceObserver((entryList) => {
  const entries = entryList.getEntries();

  for (const entry of entries) {
    // Some resources may have a responseStart value of 0, due
    // to the resource being cached, or a cross-origin resource
    // being served without a Timing-Allow-Origin header set.
    if (entry.responseStart > 0) {
      console.log(`TTFB: ${entry.responseStart}`, entry.name);
    }
  }
}).observe({
  type: 'resource',
  buffered: true
});

上述代码段与用于测量导航请求 TTFB 的代码段类似，只不过前者不是查询 'navigation' 条目，而是查询 'resource' 条目。它还考虑到了从主要来源加载的某些资源可能会返回值 0，因为连接已打开，或者系统会立即从缓存中检索资源。

<ph type="x-smartling-placeholder">

如何提高 TTFB

如需有关提高网站 TTFB 的指导，请参阅我们有关优化 TTFB 的深度指南。