了解如何针对 Time to First Byte 指标进行优化。
发布时间：2023 年 1 月 19 日；最后更新���间：2025 年 11 月 28 日
第一字节时间 (TTFB) 是一项基础 Web 效果指标，先于所有其他有意义的用户体验指标，例如 First Contentful Paint (FCP) 和 Largest Contentful Paint (LCP)。这意味着，TTFB 值较高会增加后续指标的时间。
建议您的服务器足够快地响应导航请求，以便 75% 的用户体验到在“良好”阈值内的 FCP。作为粗略指南，大多数网站应努力将 TTFB 控制在 0.8 秒或更短。
如何衡量 TTFB
在优化 TTFB 之前，您需要观察它对网站用户的影响。您应将现场数据作为观察 TTFB 的主要来源，因为它会受到重定向的影响，而基于实验室的工具通常使用最终网址进行衡量，因此会漏掉这种额外延迟。
PageSpeed Insights 是一种获取 Chrome 用户体验报告中公开网站的实测数据和实验室数据的方法。
真实用户的 TTFB 显示在顶部的了解真实用户的体验部分：
对于实验室数据，TTFB 问题会显示在文档请求延迟时间数据分析中：
如需了解在现场和实验室中衡量 TTFB 的更多方法，请参阅 TTFB 指标页面。
了解现场 TTFB 和实验室 TTFB 之间的差异
实验室 TTFB 和现场 TTFB 可能会因多种原因而有所不同，如果确实存在差异，请务必了解原因，以便有效利用实验室数据来改善用户体验。
当实验室 TTFB 远大于现场 TTFB 时，这表明实验室环境比典型用户体验更受限。这不一定是个问题，因为实验室结果和建议仍然有效，但可能会夸大影响和改进。
当现场 TTFB 远大于实验室 TTFB 时，这表明存在实验室运行中不明显的问题，例如使用服务器端缓存、重定向或网络差异。在这种情况下，实验室结果和建议可能不太有用，因为它们忽略了其中一个主要问题。
如需了解服务器端缓存是否会影响实验室 TTFB，请尝试测试不太常见的网页，或使用不同的网址参数来获取未缓存的内容，看看 TTFB 是否更符合现场 TTFB。此外，如果您能够使用特定网址参数绕过服务器端缓存，也会很有帮助。请参阅缓存内容部分。
对于重定向和网络差异，分析流量如何进入我们的网站以及流量来自何处，有助于诊断这些是否是潜在问题。
使用 Server-Timing 调试现场的高 TTFB
您可以在应用后端中使用 Server-Timing 响应标头来衡量可能导致高延迟的不同后端进程。标头值的结构非常灵活，至少可以接受您定义的句柄。可选值包括时长值（通过 dur）以及可选的人类可读说明（通过 desc）。
Serving-Timing 可用于衡量许多应用后端进程，但您可能需要特别注意以下进程：
- 数据库查询
- 服务器端呈现时间（如果适用）
- 磁盘寻道
- 边缘服务器缓存命中或未命中（如果使用 CDN）
Server-Timing 条目的所有部分均以英文冒号分隔，多个条目可以用英文逗号分隔：
// Two metrics with descriptions and values
Server-Timing: db;desc="Database";dur=121.3, ssr;desc="Server-side Rendering";dur=212.2
您可以使用应用后端所选的语言来设置标头。例如，在 PHP 中，您可以按如下方式设置标头：
<?php
// Get a high-resolution timestamp before
// the database query is performed:
$dbReadStartTime = hrtime(true);
// Perform a database query and get results...
// ...
// Get a high-resolution timestamp after
// the database query is performed:
$dbReadEndTime = hrtime(true);
// Get the total time, converting nanoseconds to
// milliseconds (or whatever granularity you need):
$dbReadTotalTime = ($dbReadEndTime - $dbReadStartTime) / 1e+6;
// Set the Server-Timing header:
header('Server-Timing: db;desc="Database";dur=' . $dbReadTotalTime);
?>
在实际环境中，任何设置了 Server-Timing 响应标头的网页都会在 Navigation Timing API 中填充 serverTiming 属性：
// Get the serverTiming entry for the first navigation request:
performance.getEntries('navigation')[0].serverTiming.forEach(entry => {
// Log the server timing data:
console.log(entry.name, entry.description, entry.duration);
});
在实验室中，来自 Server-Timing 响应标头的数据会在 Chrome 开发者工具中网络标签页的时间面板中直观呈现：
在这里，Server-Timing 用于衡量资源请求是否命中了 CDN 缓存，以及请求命中 CDN 的边缘服务器然后命中源服务器所需的时间。
服务器计时也会显示在 Chrome 开发者工具中性能面板的“网络”轨道中：
通过分析可用数据确定 TTFB 存在问题后，您就可以着手解决问题。
优化 TTFB 的方法
优化 TTFB 最具挑战性的方面在于，虽然 Web 的前端堆栈始终是 HTML、CSS 和 JavaScript，但后端堆栈可能会有很大差异。后端堆栈和数据库产品有很多，每种都有自己的优化技术。因此，本指南重点介绍适用于大多数架构的内容，而不是仅侧重于特定于堆栈的指南。
针对具体平台的指南
您网站所使用的平台可能会对 TTFB 产生重大影响。例如，WordPress 性能会受到插件数量和质量以及所用主题的影响。其他平台在自定义时也会受到类似影响。您应查阅平台文档，获取供应商专属建议，以补充本文中更通用的性能建议。Lighthouse 数据分析还包含一些有限的堆栈专用指南。
Hosting、Hosting、Hosting
在考虑其他优化方法之前，您应该首先考虑托管。我们无法在此提供太多具体指导，但一般经验法则是确保网站的主机能够处理您发送给它的流量。
共享托管通常速度较慢。如果您运行的是一个主要提供静态文件的小型个人网站，这可能没问题。使用以下一些优化技术，尽可能缩短 TTFB。
不过，如果您运行的是一个大型应用，有许多用户，并且涉及个性化、数据库查询和其他密集型服务器端操作，那么您选择的托管服务对于降低实际 TTFB 至关重要。
选择托管服务提供商时，请注意以下几点：
- 您的应用实例分配了多少内存？如果应用内存不足，就会��生������，难以尽快提供网页。
- 您的托管服务提供商是否会及时更新您的后端堆栈？随着应用后端语言、HTTP 实现和数据库软件的新版本发布，这些软件的性能会不断提升。因此，选择一家重视此类关键维护的托管服务提供商至关重要。
- 如果您有非常具体的应用要求，并且希望对服务器配置文件进行最低级别的访问，请询问是否可以自定义您自己的应用实例的后端。
许多托管服务提供商都会为您处理这些问题，但如果您开始观察到较长的 TTFB 值（即使在专用托管服务提供商中也是如此），则可能表明您需要重新评估当前托管服务提供商的功能，以便提供尽可能出色的用户体验。
使用内容分发网络 (CDN)
CDN 使用是一个老生常谈的话题，但有充分的理由：您的应用后端可能已经过优化，但距离源服务器较远的用户在实际使用中仍可能会遇到较高的 TTFB。
CDN 使用分布式服务器网络，在物理上更靠近用户的服务器上缓存资源，从而解决用户与源服务器之间的距离问题。这些服务器称为“边缘服务器”。
CDN 提供商还可能提供边缘服务器之外的其他优势：
- CDN 提供商通常提供极快的 DNS 解析时间。
- CDN 可能会使用 HTTP/2 或 HTTP/3 等现代协议从边缘服务器提供内容。
- 尤其是 HTTP/3，它通过使用 UDP 协议解决了 TCP（HTTP/2 依赖于此协议）中存在的队头阻塞问题。
- CDN 可能会提供现代版本的 TLS，从而降低 TLS 协商时间所涉及的延迟时间。TLS 1.3 尤其旨在尽可能缩短 TLS 协商时间。
- 一些 CDN 提供商提供通常称为“边缘工作器”的功能，该功能使用类似于 Service Worker API 的 API 来拦截请求、以编程方式管理边缘缓存中的响应或完全重写响应。
- CDN 提供商非常擅长针对压缩进行优化。自行正确压缩并非易事，在某些情况下，如果标记是动态生成的，则必须实时压缩，这可能会导致响应速度变慢。
- 此外，CDN 提供商会自动缓存静态资源的压缩响应，从而实现压缩率和响应时间的最佳组合。
虽然采用 CDN 所需的工作量从微不足道到非常巨大，但如果您的网站尚未使用 CDN，则应优先考虑采用 CDN 来优化 TTFB。
尽可能使用缓存的内容
如果内容配置了适当的 Cache-Control HTTP 标头，CDN 允许将内容缓存在物理位置更靠近访问者的边缘服务器上。虽然这不适用于个性化内容，但如果要求一直返回到源站，则可能会抵消 CDN 的大部分价值。
对于频繁更新内容的网站，即使缓存时间很短，也能显著提升繁忙网站的性能，因为在此期间，只有第一位访问者会经历返回源服务器的完整延迟，而所有其他访问者都可以重复使用边缘服务器中的缓存资源。有些 CDN 允许在网站发布时使缓存失效，从而实现两全其美：缓存时间长，但在需要时可即时更新。
即使正确配置了缓存，也可以通过使用唯一的查询字符串参数进行分析衡量来忽略此问题。尽管内容相同，但 CDN 可能会将其视为不同的内容，因此不会使用缓存版本。
较旧或访问量较少的内容也可能不会被缓存，这可能会导致某些网页的 TTFB 值高于其他网页。延长缓存时间可以减少这种情况的影响，但请注意，缓存时间越长，提供可能过时的内容的可能性就越大。
缓存内容的影响不仅限于使用 CDN 的用户。当缓存内容无法重复使用时，服务器基础架构可能需要通过成本高昂的数据库查找来生成内容。更频繁访问的数据或预缓存的网页通常可以获得更好的性能。
避免多次页面重定向
导致 TTFB 较高的一个常见因素是重定向。当文档的导航请求收到通知浏览器资源存在于其他位置的响应时，就会发生重定向。一次重定向肯定会给导航请求增加不必要的延迟，但如果该重定向指向另一个导致再次重定向的资源，情况肯定会更糟，以此类推。这可能会对通过广告或简报吸引大量访问者的网站产生影响，因为这些网站通常会通过分析服务进行重定向，以便衡量效果。消除您直接控制的重定向有助于实现良好的 TTFB。
重定向分为两种类型：
- 同源重定向，即重定向完全发生在您的网站上。
- 跨域重���向，即重定向最初发生在另一个源（例如社交媒体网址缩短服务），然后才到达您的网站。
重点消除同源重定向，因为这是您可以直接控制的。这包括检查您网站上的链接，看看是否有任何链接会导致 302 或 301 响应代码。这通常是因为未包含 https:// 架构（因此浏览器默认使用 http://，然后进行重定向），或者是因为网址中未适当包含或排除末尾斜杠。
跨域重定向更棘手，因为这些重定向通常不在您的控制范围内，但请尽量避免多次重定向，例如，在分享链接时使用多个链接缩短工具。确保提供给广告客户或简报的网址是正确的最终到达网址，以免在这些服务使用的重定向网址中再添加一个重定向网址。
另一个导致重定向时间过长的常见原因是从 HTTP 到 HTTPS 的重定向。解决此问题的一种方法是使用 Strict-Transport-Security 标头 (HSTS)，该标头会在首次访问源站时强制使用 HTTPS，然后告知浏览器在后续访问中立即通过 HTTPS 架构访问源站。
制定好 HSTS 政策后，您就可以将网站添加到 HSTS 预加载列表，从而加快首次访问源站的速度。
将标记流式传输到浏览器
浏览器经过优化，可在流式传输标记时高效处理标记，这意味着标记在从服务器到达时会分块处理。这对于大型标记载荷至关重要，因为这意味着浏览器可以增量解析标记块，而不是等待整个响应到达后才开始解析。
虽然浏览器非常擅长处理流式标记，但务必尽一切努力保持该流的顺畅，以便尽快传输这些初始标记。如果后端拖了后腿，那就是个问题。由于后端堆栈数量众多，因此本指南无法涵盖每个堆栈以及每个特定堆栈中可能出现的问题。
例如，React 和其他可以在服务器上按需呈现标记的框架，都采用了同步方法进行服务器端呈现。不过，较新版本的 React 实现了用于流式传输标记的服务器方法，以便在标记呈现时进行流式传输。这意味着，您无需等待 React 服务器 API 方法渲染完整个响应后再发送。
另一种确保标记快速流式传输到浏览器的方法是依赖静态渲染，它会在构建时生成 HTML 文件。由于完整文件立即可用，Web 服务器可以立即开始发送文件，而 HTTP 的固有特性会产生流式标记。虽然这种方法并不适用于每个网站上的每个网页（例如那些需要动态响应作为用户体验一部分的网页），但对于那些不需要针对特定用户进行个性化标记的网页来说，这种方法可能很有用。
使用 Service Worker
Service Worker API 可能会对文档及其加载的资源的 TTFB 产生重大影响。这是因为 Service Worker 充当浏览器和服务器之间的代理，但对网站 TTFB 的影响取决于您如何设置 Service Worker，以及该设置是否符合应用要求。
- 对资源使用过时重新验证策略。如果某个资源（无论是文档还是文档所需的资源）位于 Service Worker 缓存中，stale-while-revalidate 策略会首先从缓存中提供该资源，然后在后台下载该资源，并从缓存中提供该资源，以供日后互动使用。
- 如果您有不经常更改的文档资源，使用 stale-while-revalidate 策略可以使网页的 TTFB 几乎瞬间完成。不过，如果您的网站发送动态生成的标记（例如，根据用户是否经过身份验证而变化的标记），则此方法不太适用。在这种情况下，您始终需要首先访问网络，以便文档尽可能保持最新。
- 如果您的文档加载了非关键资源，这些资源会不时发生变化，但提��过时资源不会对用户体验产生重大影响（例如某些图片或其他非关键资源），则可以使用 stale-while-revalidate 策略大幅缩短这些资源的 TTFB。
- 为客户端渲染的应用使用应用 shell 模型。此模型最适合单页应用 (SPA)，其中网页的“shell”可以从 Service Worker 缓存中即时传送，而网页的动态内容会在网页生命周期的后期填充和呈现。
对渲染关键资源使用 103 Early Hints
无论应用后端经过多么出色的优化，服务器仍可能需要完成大量工作才能准备好响应，包括昂贵（但必要）的数据库工作，这会延迟导航响应尽快到达。这可能会导致一些后续的关键渲染资源延迟，例如 CSS 或（在某些情况下）在客户端上呈现标记的 JavaScript。
103 Early Hints 标头是一种早期响应代码，当后端忙于准备标记时，服务器可以向浏览器���送该代码。此标头可用于向浏览器提示，在准备标记时，页面应开始下载对渲染至关重要的资源。对于支持的浏览器，这可以加快文档渲染 (CSS) 和网页加载速度。
103 Early Hints 的一个缺点是，与缓存一样，它们可能会掩盖网站的“真实”TTFB。如果服务器基础架构运行缓慢（因为性能不足或代码需要优化），那么在使用 103 Early Hints 时，这一点可能不太明显，因为 TTFB 看起来很快。使用 103 Early Hints 的网站应考虑衡量实际服务器时间（通过 PerformanceNavigationTiming API 的 Server-Timing 或 finalResponseHeadersStart）。
总结
由于后端应用堆栈的组合非常多，因此没有一篇文章可以涵盖您为降低网站 TTFB 所能做的所有事情。不过，您可以考虑采取以下措施，尝试在服务器端加快处理速度。
与优化每个指标一样，优化 TTFB 的方法也大体相似：在现场衡量 TTFB，使用实验室工具深入探究原因，然后尽可能应用优化。虽然有些方法可能不适用于您的情况，但有些方法可能适用。一如既往，您需要密切关注现场数据，并根据需要进行调整，以确保尽可能快的用户体验。