什么是 Time To First Byte (TTFB) 以及如何改善它

什么是 Time to First Byte

Time-to-first byte (TTFB) 表示从发起请求到接收网页第一个响应（字节）之间经过了多少毫秒。因此，TTFB 也被称为等待时间。TTFB 是衡量网页速度某些方面的一种方式。TTFB 是一个基础性指标，这意味着 TTFB 增加的时间也会被加到 Largest Contentful Paint 和 First Contentful Paint 上。

为什么 Time to First Byte 很重要

Time to First Byte 不是一个 Core Web Vital，在通过 Core Web Vitals 评估的同时 TTFB 指标未能达标是完全可能的。但这并不意味着 TTFB 不重要。TTFB 是一个极其重要的优化指标，修复 TTFB 将大幅提升页面速度和页面体验！

TTFB 对访客的影响

Time to first byte 先于所有其他绘制指标。当浏览器在等待 Time to First Byte 时，浏览器无法执行任何操作，只能显示空白屏幕！这意味着 time to first byte 的任何增加都会导致更多的"空白屏幕"时间，而 time to first byte 的任何减少都会转化为更少的"空白屏幕"时间。

要获得"页面即时加载的感觉"，time to first byte 需要尽可能快！

为什么 TTFB 不是 Core Web Vital？ TTLB 不考虑渲染：较低的 TTLB 并不一定意味着良好的 user experience，因为它不考虑浏览器渲染网页所需的时间。即使所有字节都被快速下载，如果浏览器需要处理大量 JavaScript 或渲染复杂布局，网页仍然可能需要很长时间才能显示。

什么是良好的 TTFB 分数？

建议您的服务器足够快地响应导航请求，使第 75 百分位的用户体验到的 FCP 处于"良好"阈值内。作为大致指南，大多数网站应努力将 TTFB 控制在 0.8 秒或更短。

• TTFB 低于 800 毫秒被认为是良好的。
• TTFB 在 800 到 1800 毫秒之间需要改善
  
• TTFB 超过 1800 毫秒被认为是差的，应立即改善

TTFB 从请求到响应

从浏览器到服务器：请求

浏览器请求时间是从用户浏览器发送 HTTP 请求到该请求到达托管网站的服务器之间经过的时间。这部分的 TTFB 在很大程度上超出了网站的直接控制范围，主要取决于

• 用户的网络速度。
• 其网络基础设施的质量。
• 用户和服务器之间的物理距离。○

在此阶段，DNS 查找、浏览器启动时间、浏览器缓存查找以及与服务器的连接协商（TCP 和 TSL）都会占用一些时间。

在服务器上：处理和准备响应

一旦服务器收到请求，时钟就开始计时，因为它需要生成响应。这个阶段是大多数开发人员倾向于关注的地方，也是优化工作能产生最显著影响的地方。需要考虑的因素包括：

• 服务器能力：强大的硬件（CPU、RAM）、高效的软件（Web 服务器、数据库）和优化的配置都很重要。
  
• 数据库耗时：如果请求需要从数据库获取数据，慢查询可能成为主要瓶颈。
• 代码优化：编写不佳的服务器端代码（例如低效脚本）可能导致处理时间过长。
• 缓存策略：有效的缓存（如服务器端缓存或使用内容分发网络 - CDN）可以大幅减少重复请求的处理负担。

返回浏览器：传递第一个字节

处理完成后，服务器将响应发送回用户的浏览器，从第一个字节开始。

• 与第一个阶段类似，网络条件和距离在这里也起着作用。
• CDN 在此阶段特别有益，因为它们将内容缓存在更靠近用户的地方，最大限度地减少传输时间。
  
• 重定向在此时被发送，这使得整个过程以额外的延迟重复进行。

Time To First Byte 的技术阶段

与浏览器中的"从请求到响应路径"类似，导航请求的 Time To First Byte 可以使用Navigation Timing API 进行测量，并可分解为 5 个子部分。

1. 重定向时间：当资源被移动到新位置时，重定向时间会被添加到该资源的 TTFB 中。
2. Worker 和缓存时间：在从互联网获取资源之前，浏览器会首先尝试在自己的缓存中或通过 worker 查找（如果已设置 worker）
3. DNS 查找时间：接下来，浏览器可能需要执行 DNS 查找，将域名（www.example.com）转换为 IP 地址
4. TCP 连接时间：然后浏览器将连接到服务器并执行一些检查
5. SSL 握手：然后浏览器和服务器将加密它们的通信
6. 服务器响应：最后服务器需要发送 HTML。它可能需要先生成 HTML。

如何测量 Time To First Byte TTFB

PageSpeed 提示：每个资源都有自己的 time to first byte。但在此上下文中，我们讨论的是主页面的 time to first byte！

Time to First Byte 在使用不同设备和来自不同位置的不同用户之间可能会有很大波动。这就是为什么从桌面电脑自行测量 time to first byte 可能不是一个好主意。出于同样的原因，使用 pingdom 或 GTMetrix 等工具也不可靠。

测量 Time To First Byte 的最佳方式是从访客处收集 Real User Metrics (RUM) 数据。您可以使用以下代码自行完成，或使用 CoreDash 等 RUM 工具

使用合成工具测量 TTFB

使用 RUM 跟踪测量 TTFB

使用 CrUX 数据测量 TTFB

CrUX（Chrome User Experience Report）是 Google 提供的公开数据集，包含网站的真实性能数据。Google 使用 CrUX 数据集来确定您是否通过了 Core Web Vitals。

CrUX 数据集可以通过 PageSpeed Insights、CrUX API、Looker Studio 或 Google BigQuery 等工具访问。使用这些工具中的任何一个来获取网站的 TTFB。

使用 JavaScript 测量 TTFB

要使用 JavaScript 测量 Time to First Byte (TTFB)，您可以使用 Navigation Timing API。您可以创建一个 PerformanceObserver 来监听导航条目并将 responseStart 属性记录到控制台。responseStart 属性表示接收到响应的第一个字节时的时间戳。web-vitals JavaScript 库提供了一种更简洁的方式，使用 onTTFB 函数在浏览器中测量 TTFB。

以下代码可用于测量 Time To First Byte (TTFB)

const formatTime = (time) => {

//round by 2 decimals, use Math.round() for integer
return Math.round(time * 100) / 100;
};

new PerformanceObserver((entryList) => {
const [pageNav] = entryList.getEntriesByType('navigation');

// timing start times are relative
const activationStart = pageNav.activationStart || 0;
const workerStart = Math.max(pageNav.workerStart - activationStart, activationStart);
const dnsStart = Math.max(pageNav.domainLookupStart - activationStart, workerStart);
const tcpStart = Math.max(pageNav.connectStart - activationStart, dnsStart);
const sslStart = Math.max(pageNav.secureConnectionStart - activationStart, tcpStart);
const requestStart = Math.max(pageNav.requestStart - activationStart, sslStart);
const responseStart = Math.max(pageNav.responseStart - activationStart, requestStart);

// attribution based on https://www.w3.org/TR/navigation-timing-2/#processing-model
// use associative array to log the results more readable
let attributionArray = [];
attributionArray['Redirect Time'] = { 'time in ms': formatTime(workerStart - activationStart) };
attributionArray['Worker and Cache Time'] = { 'time in ms': formatTime(dnsStart - workerStart) };
attributionArray['DNS Time'] = { 'time in ms': formatTime(tcpStart - dnsStart) };
attributionArray['TCP Time'] = { 'time in ms': formatTime(sslStart - tcpStart) };
attributionArray['SSL Time'] = { 'time in ms': formatTime(requestStart - sslStart) };
attributionArray['Request Time'] = { 'time in ms': formatTime(responseStart - requestStart) };
attributionArray['Total TTFB'] = { 'time in ms': formatTime(responseStart - activationStart) };

// log the results
console.log('%cTime to First Byte (' + formatTime(responseStart - activationStart) + 'ms)', 'color: blue; font-weight: bold;');
console.table(attributionArray);

console.log('%cOrigininal navigation entry', 'color: blue; font-weight: bold;');
console.log(pageNav);

}).observe({
type: 'navigation',
buffered: true
});

使用 Server Timing 查找瓶颈

Server Timings 提供了一种将后端服务器性能计时发送到浏览器的方式。通过利用 Server Timings，开发人员可以有效地测量和分析影响 TTFB 的服务器端组件，帮助识别需要优化的领域并提高整体网站性能。

Server-Timing 头可以包含多个指标的计时，用逗号分隔：

指标的简短名称（如 database 和 processing）
以毫秒为单位的持续时间（表示为 dur=123）
描述（表示为 desc="My Description"）

Server-Timing: database;dur=123, processing;dur=234

浏览器现在可以读取 server timings 头。这些 server timings 头可以发送到您喜爱的 RUM 工具，如 CoreDash

托管如何影响 Time to First Byte？

托管以多种方式影响 time to first byte。通过投资更好的托管，通常可以在不更改任何其他内容的情况下立即改善 time to First byte。特别是从低预算的共享托管切换到正确配置和管理的虚拟服务器时，TTFB 可能会大幅改善。

托管提示：更好的托管涉及更快的处理、更好的网络速度以及更多更快的服务器内存。昂贵的托管并不总是等于更好的托管！共享托管服务上的许多升级只会为您提供更多存储空间，而不是更多的 CPU 算力

我不建议在不了解 TTFB 问题根本原因的情况下更换托管。我建议您设置 RUM 跟踪并添加 server timing 头。

升级托管时，您通常应至少寻找以下 3 项改进中的 1 项：

• 获取更多资源（CPU + RAM）：特别是当服务器生成动态 HTML 耗时过长时。
• 更快的 DNS：许多低预算托管提供商以其糟糕的 DNS 性能而臭名昭著
  
• 更好的配置：寻找更快的 SSL 加密套件、HTTP/3、Brotli 压缩、访问 Web 服务器配置（以禁用不需要的模块）等。
  

如何改善 TTFB - 加速初始连接

较高的 Time to First Byte 可能有多种原因。然而，DNS、TCP 和 SSL 影响所有 time to first byte。所以让我们从这里开始。虽然优化这 3 项可能不会产生最大的效果，但优化它们将优化每一个 TTFB！

加速 DNS

PageSpeed 提示：当您使用廉价主机或在不使用 CDN 的情况下服务全球受众时，DNS、TCP 和 SSL 通常是一个更大的问题。使用 RUM 跟踪查看您的全球 TTFB 并将 TTFB 分解为其子部分

使用快速的 DNS 提供商。并非所有 DNS 提供商都一样快。一些（免费的）DNS 提供商比其他（免费的）DNS 提供商慢。例如，CloudFlare 将免费为您提供世界上最快的 DNS 提供商之一！

增加 DNS TTL。另一种方法是增加 Time to Live (TTL) 值。TTL 是一个设置，决定查找可以被缓存多长时间。TTL 越高，浏览器需要执行另一次 DNS 查找的可能性就越小。需要注意的是，ISP 也会缓存 DNS。

加速 TCP

TTFB 的"TCP 部分"是与 Web 服务器的初始连接。连接时，浏览器和服务器共享有关信息交换方式的信息。您可以通过连接到地理位置靠近您的服务器并确保服务器有足够的空闲资源来加速 TCP。有时切换到 NGINX 等轻量级服务器可以加速 TTFB 的 TCP 部分。在许多情况下，使用 CDN 将加速 TCP 连接！

加速 SSL/TSL

TCP 连接建立后，浏览器和服务器需要通过加密来保护您的连接。您可以通过使用更快、更新和更轻量的协议（SSL 加密套件）以及在地理位置上更靠近您的 Web 服务器（因为 TSL 协商需要相当多的往返）来加速这一过程。使用 CDN 通常会改善 SSL 连接时间，因为它们通常配置得非常好，并在全球拥有多台服务器。TLS 1.3 特别设计为尽可能缩短 TLS 协商时间。

如何改善 TTFB - 加速服务器端

页面缓存

到目前为止，加速 time to first byte 最有效的方法是从服务器缓存提供 HTML。有几种方法可以实现全页缓存。最有效的方法是直接在 Web 服务器级别执行此操作，例如使用 NGINX 缓存模块或使用 Varnish 作为反向缓存代理。

还有许多针对不同 CMS 系统的插件可以缓存完整页面，许多 SPA 框架（如 NextJS）都有自己的全页缓存实现以及不同的失效策略。

如果您想实现自己的缓存，基本思路非常简单。当客户端请求页面时，检查它是否存在于缓存文件夹中。如果不存在，创建页面，将其写入缓存，然后像平常一样显示页面。在下一次请求该页面时，缓存文件将存在，您可以直接从缓存提供页面。

部分缓存

部分缓存的思路是缓存页面或资源中频繁使用、速度慢或开销大的部分（如 API 调用、数据库结果）以实现快速检索。这将消除生成页面时的瓶颈。如果您对这些类型的优化感兴趣（您应该感兴趣！！），请查找以下概念：Memory Cache、Object Cache、Database Cache、Object-Relational Mapping (ORM) Cache、Content Fragment Cache 和 Opcode Cache。

优化应用程序代码

有时页面无法从（部分）缓存中提供，因为缓存文件不存在、页面的大部分是动态的或因为您遇到了其他问题。这就是为什么我们需要优化应用程序代码。如何做到这一点完全取决于您的应用程序。这基于重写和优化代码中慢速部分。

优化数据库查询

大多数时候，低效的数据库查询是 Time to First Byte 缓慢的根本原因。首先将"慢查询"和"未使用索引的查询"记录到磁盘。分析它们，添加索引或请专家执行数据库调优来修复这些问题。参见 https://www.mongodb.com/docs/atlas/performance-advisor/ 和 https://dev.mysql.com/doc/refman/8.0/en/slow-query-log.html

减少内部网络延迟

我经常遇到的一个不良做法是，Web 应用程序与数据存储之间的通信缓慢导致 time to first byte 延迟。这通常只发生在将数据存储外包给云 API 的大型网站上。

如何改善 TTFB - 加速客户端

客户端缓存

客户端缓存涉及用户浏览器存储它们已访问的资源，如图像和脚本。因此，当用户再次访问您的网站时，浏览器可以快速检索缓存的资源，而无需再次下载。这可以显著减少向服务器发出的请求数量，从而减少 TTFB。

要实现客户端缓存，您可以使用 HTTP Cache-Control 头。此头允许您指定浏览器应缓存特定资源的时间。

您可以考虑在客户端完全缓存页面的 HTML。这将大幅减少 TTFB，因为我们不再需要请求。缺点是，一旦页面在浏览器缓存中，用户将看不到页面实时版本的任何更新，直到页面缓存过期。

Service Workers

Service workers 是在用户浏览器后台运行的脚本，可以拦截浏览器发出的网络请求。这意味着 service workers 可以缓存 HTML、图像、脚本和样式表等资源，因此当用户再次访问您的网站时，浏览器可以快速检索缓存的资源，而无需再次下载。

Speculation Rules API

Speculation Rules API 旨在改善未来导航的性能。一旦访客登陆您的页面，您可以使用 speculationrules 指示浏览器获取（使用 prefetch 指令）甚至渲染（使用 prerender 指令）访客最可能访问的页面。Speculation Rules API 比 link prefetch 方法更灵活、更可配置。

看看这个示例，其中浏览器被指示为未来导航预取菜单栏中的 URL，将其保留在内存中以便用于加速下一次导航。

<script type="speculationrules">
{"prerender": 
[{
  "source": "document",
  "where": {"selector_matches": "nav a"},
  "eagerness": "moderate"
}]}
</script>

页面预取

如果您不想使用 Speculation Rules API（因为其浏览器支持较差），您可以使用名为 quicklink 的小脚本。这将预取可见视口中的所有链接，几乎消除这些链接的 Time To First Byte！

quicklinks 的缺点是它需要更多的浏览器资源，但目前它的性能将优于 Speculation Rules API。

如何改善 TTFB - 利用 CDN

内容分发网络或 CDN 使用分布式服务器网络向用户交付资源。这些服务器通常在地理位置上更靠近终端用户，并针对速度进行了超级优化。

CDN 可以帮助改善 Time to First Byte 6 个部分中的 5 个：

• 重定向时间：大多数 CDN 可以在边缘缓存重定向或使用边缘 workers 处理重定向，无需连接到源服务器。
• DNS 查找时间：大多数 CDN 提供极快的 DNS 服务器，可能会优于您当前的 DNS 服务器
  
• TCP 连接和 SSL 握手时间。大多数 CDN 配置得非常好，这些配置加上与终端用户更近的距离将加速连接和握手时间
  
• 服务器响应：CDN 可以通过几种方式加速服务器响应时间。第一种是在边缘缓存服务器响应（全页边缘缓存），另外还提供出色的压缩（Brotli）和最新的（HTTP/3）协议

如何改善 TTFB - 避免重定向

重定向时间会被添加到 Time To First Byte。因此，作为一般规则，尽可能避免重定向。当资源不再在一个位置可用但已移至另一个位置时，可能会发生重定向。服务器将以重定向响应头响应，浏览器将尝试该新位置。

同源重定向。同源重定向源自您自己网站上的链接。您应该完全控制这些链接，在处理 Time to First Byte 时应优先修复这些链接。有很多工具可以让您检查整个网站的重定向

跨域重定向。跨域重定向源自其他网站上的链接。您对这些几乎没有控制权。

多次重定向。多次重定向或重定向链在单个重定向未将资源重定向到最终位置时发生。这些类型的重定向对 Time to First Byte 造成更大的压力，应不惜一切代价避免。同样，使用工具找到这些类型的重定向并修复它们！

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

当用户请求网页时，服务器可能会以重定向到另一个页面作为响应。此重定向可能会增加 TTFB 的额外时间，因为浏览器必须向新页面发出额外请求。

有几种方法可以避免重定向或最小化重定向的影响：

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