TTFB是什么？良好数值与优化方法

TTFB（首字节时间，time to first byte）是从导航开始到收到HTML响应第一个字节的时间。web.dev将0.8秒或以下称为良好，超过1.8秒称为较差，并以真实访问的第75百分位计算（web.dev，最后更新于2025年11月）。TTFB不属于Core Web Vitals，但此后的所有指标，包括首次内容绘制和最大内容绘制，都从它之后开始。在手机上，重定向、DNS、TLS和缓慢的服务器也会在这里叠加，因为每一步都至少要穿过一次移动网络。

什么是首字节时间

TTFB是文档第一个字节到达之前所有步骤的总和，包括重定向、DNS和TLS。根据web.dev，它包括：

• 重定向时间；
• Service Worker的启动时间（如果网站有Service Worker）；
• DNS查询；
• 连接和TLS协商；
• 请求本身，直到响应的第一个字节。

因此，服务器很快，TTFB仍然可能很慢。一次从http://example.com开始、重定向到https://example.com、再重定向到https://www.example.com的访问，在最终页面的服务器做任何工作之前，就已经付出了两次重定向和三次连接的代价。

TTFB也不同于旧版Lighthouse报告中的“服务器响应时间”。该审核只衡量等待主文档的时间，不包括DNS查询和重定向，因此它只是TTFB的一部分（Chrome for Developers）。

什么是良好的TTFB

良好的TTFB是0.8秒或以下，web.dev称这些阈值是“粗略的指南”，而不是硬性要求。以下是截至2025年11月的范围，以及更严格的Lighthouse数值：

这两个数字衡量的是不同的东西。Lighthouse的600 ms只涵盖服务器自身的响应时间，而0.8秒的指南涵盖整个TTFB，因此同一个页面可能通过其中一个，却不通过另一个。两者都是Google设定的设计阈值。

手机上达到良好分数的情况有多常见？根据HTTP Archive的Web Almanac 2025（基于2025年7月的数据），44%的移动网站TTFB良好，而桌面端为55%。在移动端，40%需要改进，17%较差（Web Almanac 2025，Performance）。

为什么手机上的TTFB更高

手机上的TTFB更高，是因为首字节之前的每一步都是一次往返，而移动网络上的一次往返比有线网络上耗时更长。对于冷连接下首次通过HTTPS访问，过程如下：

1. DNS查询，找到服务器地址。
2. TCP握手：与服务器往返一次。
3. TLS握手：在TLS 1.3下再往返一次，RFC 8446称之为“1-RTT握手”。
4. HTTP请求和响应的第一个字节：一次往返，加上服务器准备响应所需的时间。

因此，仅网络就要与服务器往返三次，再加上DNS查询，然后才是服务器自身的工作。下表是用两个为说明而选取的往返时间（RTT）进行的计算，并非对任何网络的测量：

在较高的RTT下，一台在400 ms内响应的服务器，加上DNS之后就已经突破了0.8秒的指南。服务器并没有出错；连接建立就占去了超过一半的预算。

有两件事可以减少这部分开销。复用连接：一个仍保持连接的回访者会跳过第1到第3步。使用更新的协议：HTTP/3运行在QUIC之上，其握手“同时协商加密参数和传输参数”（RFC 9000，2021年5月），因此建立连接所需的往返次数少于TCP加TLS。web.dev指出，CDN会通过HTTP/2或HTTP/3等现代协议提供内容（web.dev）。

还有一个与移动端相关的原因：单独的移动版网站。Lighthouse针对重定向的建议是，对于移动用户，应考虑响应式设计，而不是把他们重定向到移动页面（Chrome for Developers）。响应式方案见如何让网站适配手机。

如何测量TTFB

请测量两次：一次在实验室中，看时间花在哪里；一次在现场，看真实手机得到什么。两个数字可能不同：实验室运行是在一台机器上的一次加载，而现场数值是真实访问的第75百分位。

在DevTools中（实验室），打开Network面板，刷新页面，选择第一个请求（文档），然后打开Timing标签。各阶段名为Queueing、Stalled、DNS Lookup、Initial connection、Request sent和Waiting (TTFB)，其中“Waiting (TTFB)”是一次往返加上服务器准备响应的时间（Chrome DevTools参考）。如果Initial connection条很长而Waiting很短，那么修复的重点是连接建立，而不是应用本身。

在页面中（现场），web-vitals库会报告TTFB，其归因版本还会把它拆分为相同的各阶段。根据其文档（web-vitals README），这些阶段分别名为waitingDuration（请求之前的重定向和浏览器工作）、cacheDuration（缓存检查，以及Service Worker的时间）、dnsDuration、connectionDuration和requestDuration（网络时间和服务器处理）：

import {onTTFB} from 'web-vitals/attribution';

onTTFB(({value, rating, attribution}) => {
  // 发送到你的分析接口；这里只打印拆分结果。
  console.log(rating, Math.round(value), {
    redirectsAndWaiting: attribution.waitingDuration,
    cache: attribution.cacheDuration,
    dns: attribution.dnsDuration,
    connection: attribution.connectionDuration,
    request: attribution.requestDuration,
  });
});

按设备类型（现场，无需代码），Chrome用户体验报告API接受formFactor参数，取值为PHONE、TABLET或DESKTOP，并返回experimental_time_to_first_byte的第75百分位（这是API中的一个实验性指标）（CrUX API文档）。数据是28天的滚动平均值。这是快速判断手机TTFB是否比桌面TTFB更差的最快方法。更多速度测试方法见移动页面速度测试指南，Lighthouse如何报告同一问题见Lighthouse移动端审核指南。

在服务器端，可以添加Server-Timing头，查看哪一个后端步骤较慢。Chrome 65、Firefox 61和Safari 16.4都支持它（MDN browser-compat-data 8.1.7，2026年10月）：

Server-Timing: db;dur=53, app;dur=47.2, cache;desc="miss"

这些值随后会显示在Network面板的Timing标签中，也会出现在上面归因对象的navigationEntry.serverTiming里。

如何降低TTFB

先从拆分结果中耗时最长的阶段入手，因为每项修复只消除它自己的那个阶段。下表把你看到的现象对应到应该改动的地方：

以下修复遵循web.dev的TTFB优化指南（web.dev，2025年11月更新）。

1. 删除重定向。web.dev建议删除同源的301和302重定向，例如缺少https://或末尾斜杠不一致的情况，并把最终URL提供给广告投放方和电子邮件通讯。HSTS会告诉浏览器直接使用https://，而不是先请求http://。
2. 在前端放置CDN。CDN从靠近访问者的边缘服务器作答，缩短了上表中的每一次往返。根据web.dev，它通常还能提供HTTP/3、TLS 1.3和压缩。
3. 缓存HTML。对所有访问者都相同的页面，可以用Cache-Control进行缓存，不必触及应用即可提供。web.dev指出，较短的缓存时间对流量大的网站已经有帮助。在诊断时，可以添加一个URL参数来绕过缓存。
4. 减少服务器工作量。Lighthouse的建议是优化应用逻辑和数据库查询，必要时升级硬件，并对可以在边缘缓存的文档使用CDN。先用Server-Timing找出最慢的步骤。
5. 压缩文本。Lighthouse洞察会标记未经压缩发送的主文档。浏览器通过Accept-Encoding声明自己接受的编码，服务器则通过Content-Encoding作答。
6. 流式输出HTML。web.dev建议保持响应流畅通，在可能的情况下使用流式服务器渲染或静态渲染，让第一批字节尽早发出。提前刷新同样会计入responseStart，因此TTFB看起来可能比页面的实际感受更好；请同时检查首次内容绘制。
7. 发送103 Early Hints。如果服务器需要时间来构建页面，它可以先发送一个带Link头的103响应，让浏览器在等待时就开始preconnect或preload。

HTTP/2 103
Link: </css/app.css>; rel=preload; as=style
Link: <https://cdn.example.com>; rel=preconnect

HTTP/2 200
content-type: text/html

在大多数浏览器中，Early Hints在HTTP/2或更高版本上工作，并且只处理第一个103响应（MDN，2026年6月）。支持始于Chrome 103、Firefox 120和Safari 17。103响应在TTFB中计为第一批字节，而且Chrome已经改变了responseStart报告的时间戳（Chrome 115改为最终响应，Chrome 133又改回第一批字节），因此在不同工具之间比较TTFB时要格外小心（web.dev）。

如果网站有Service Worker，从其缓存中提供外壳也能缩短回访者的TTFB。web.dev建议，对于很少变化的资源使用stale-while-revalidate，对于个性化的HTML则使用网络优先。

静态网站与CMS网站

静态网站已经处于最佳状态：HTML在请求之前就已存在，因此TTFB主要是连接建立，CDN是最主要的修复手段。CMS是在收到请求时才构建页面，因此收益最大的是整页缓存。对于WordPress，Lighthouse文档列出的是轻量主题、整页缓存和减少插件；对于Drupal，是页面缓存、PHP OPcache以及Redis或Memcached；对于Magento，是Varnish（Chrome for Developers，最后更新于2019年，早于Lighthouse 13）。

单独的AMP URL还会增加一个需要与canonical版本保持一致的页面副本；是否仍需要它，见amp 是否需要。

在手机尺寸的页面上检查重定向链

重定向是无需秒表就能看到的TTFB原因之一：手机可能被导向与桌面端不同的地方。Mobile View Extension会以手机的用户代理、屏幕尺寸和像素比重新加载标签页，因此你可以检查自己最终落在哪个URL，以及移动版页面是否以真实的移动版本加载。它不测量TTFB或任何速度指标，并且运行在你的桌面网络和硬件上，因此要获得真实手机上的计时，请使用上面的现场工具。

常见问题

什么是良好的TTFB？

根据web.dev（2025年11月），在第75百分位上，0.8秒或以下为良好，超过1.8秒为较差。这些只是粗略的指南，而且TTFB不属于Core Web Vitals。

TTFB是Core Web Vitals吗？

不是。Core Web Vitals是最大内容绘制、下一次绘制交互和累积布局偏移，web.dev明确指出TTFB不在其中。但它很重要，因为较高的TTFB会延迟首次内容绘制和最大内容绘制。

为什么我的TTFB在Lighthouse和现场数据中不同？

Lighthouse是在一台机器上、带有节流的一次加载，而现场数据涵盖真实网络和缓存下的真实访问。请以现场数值为准，并用实验室运行找出哪个阶段较慢。

TTFB会影响SEO吗？

web.dev称，TTFB不是Core Web Vitals，但它位于首次内容绘制之前，因此较慢的TTFB会延迟其后的指标，主要是最大内容绘制。先修复这些指标，再用TTFB找出它们变慢的原因。