本文收录于 Zeso 技术百科与核心文档库。你也可以在 完整技术文档.
技术百科与问答2 分钟阅读·267 字

什么是首字节时间(TTFB)——阈值是多少,以及这个数字不是什么

核心定义与要点提炼

首字节时间(TTFB)量的是从请求发出到服务器开始回答之间的全部延迟。谷歌自己的性能文档给出了阈值,也说明它不是核心网页指标——那份文档说得很清楚。

首字节时间(Time to First Byte,简称 TTFB)量的是从有人发出请求、到服务器开始回答之间的 那段距离:域名解析、连接建立、服务器自己的处理,以及中间的网络往返。最大内容绘制(LCP) 量的是访客看到什么,而 TTFB 量的是答案有没有开始。

它也是最常被人挂上一个「谁都没公布过」的数字的指标。谷歌自己的性能文档给了阈值,而且 并不苛刻:0.8 秒及以下算「好」,大于 1.8 秒算「差」,而文档明说 TTFB 不是核心网页指标 (Core Web Vitals)——这些阈值只是「粗略指引」,要结合一个站点如何交付内容来看。所以有 用的问题不是「我的 TTFB 是不是低于 50ms」,而是「我的第一个字节在干什么,它后面的所有东西 还要等多久」。

TTFB 的四个组成阶段

每次访问网页时,TTFB 由以下四个连续环节构成:

  1. DNS 域名解析:将网址域名转换为物理服务器 IP 地址的时间。
  2. TCP 连接与 TLS 握手:客户端与边缘节点建立安全加密连接(协商 TLS 1.3 加密算法)的时间。
  3. 服务器计算与处理:服务器从内存或存储中读取、编译并生成 HTML 响应文档的时间。
  4. 物理网络传输延迟:数据包通过海底光缆和骨干路由跨越大洋与洲际回传到用户设备的时间。

上面这份清单列的是四项成本。按它们真正发生的顺序,是这样:

text
DNS lookup → TCP + TLS → request → processing → response └────────────┴───────────┴─────────┴────────────┼───────▶ ▲ first byte

请求的去程与响应的回程合起来就是网络传输,它夹在服务器工作的两侧。第一个字节在响应开始返回的那一刻落地,所以那条线左边的一切,就是 TTFB 在测量的东西。

好的 TTFB 是多少,那个数字从哪来

web.dev 的 TTFB 文章——Chrome 团队的官方文档,最后更新于 2025-11-28——是阈值的出处:

TTFBweb.dev 怎么称呼它
0.8 秒及以下好(good)
大于 1.8 秒差(poor)
中间需要改进

它那条要点是大多数站点跳过的:因为 TTFB 不是核心网页指标,一个站点不必达到「好」的阈值, 只要它不妨碍那些真正重要的指标。它举的两个对照就是整个论证:

  • 一个站点很快把标记送出来、却还要靠 JavaScript 才有内容(单页应用),需要尽可能低的

TTFB,因为客户端渲染发生在字节到达之后。

  • 一个服务端渲染、客户端工作更少的站点,TTFB 可以更高,而 FCP 与 LCP 却比完全由客户端

渲染的站点更好。

所以 TTFB 是一份预算,不是一个分数。它量的是:在页面其余部分开始之前,第一个字节先 吃掉了访客多少耐心。

怎么量它

web.dev 给了三种方式,而选哪一种会改变这个数字的含义:

在哪量它告诉你什么怎么量
真实用户(field)真实访客经历到了什么Chrome 用户体验报告(CrUX),以及谷歌的 web-vitals JavaScript 库
实验室(lab)一次受控请求做了什么Chrome 开发者工具的网络面板,以及 WebPageTest
在自己的代码里同一件事Navigation Timing API 配合 PerformanceObserver 监听 navigation 条目,或用 web-vitals 的 onTTFB

有两个前提决定这个数字可不可信:

  • 跨源请求在真实用户环境里量不出来,除非对方服务器发了 Timing-Allow-Origin 标头。

一个由第三方源站提供的资源,可能报出 TTFB 为零。

  • CrUX 之类的真实用户工具可能只提供主导航请求的 TTFB,所以资源的 TTFB 常常是「缺失」

而不是「很快」。

TTFB 不是什么

  • 它不是排名因素。 谷歌自己关于搜索里生成式 AI 功能的说明、关于页面体验的说明,都没把

低 TTFB 变成名次。它是让那些确实是信号的指标够得着的前提。

  • 它不是核心网页指标。 那三个是 LCP、INP 与 CLS,全都在第一个字节之后才量。
  • 它不是「站点快」的代名词。 4 秒渲染前面放一个 30ms 的首字节,是快的字节、慢的页面。

低 TTFB 真正买到的东西更窄,但确实存在:标记尽早到达客户端,浏览器在网络还没传完时就开始 干活,而预算有限的爬虫拿到的是有东西可读,而不是什么都没有。

静态边缘如何改变这个数字

传统建站工具通常将数据库和服务器部署在单一机房(如美东或法兰克福)。当亚太地区或欧洲的 用户发起访问时,仅仅光纤往返延迟就高达 150 至 250 毫秒。

Zeso 通过将网站编译为不可变的静态资源,就近分发至全球 ${EDGE_CLAIMS.locations} 个 Anycast 边缘节点,由距离访问者物理距离最近的城市机房直接响应,实现全网中位数 ${EDGE_CLAIMS.medianTtfb} 的首字节极速呈现——比谷歌自己给出的「好」那一档还低十六倍,而且 没有源站要等。

出处

在你的独立域名上体验边缘极速

全球 330+ 边缘节点、中位数低于 50ms 的 TTFB、Anycast 任播路由与全自动免费 SSL 证书。

60 秒极速部署

相关指南与关联页面