一句话回答
首字节时间(TTFB)是从开始导航到收到页面响应第一个字节的时间,包括重定向、DNS 查询、建立连接和 TLS 握手,以及服务端处理。不超过 800 毫秒算良好。
公式: TTFB = 重定向 + Service Worker 启动 + DNS + 连接和 TLS + 请求和服务端处理
什么是首字节时间?
首字节时间(TTFB)是从开始导航到收到 HTML 第一个字节,浏览器等了多久。在它之前页面上什么都渲染不了,所以它决定了 首次内容绘制(FCP) 和 LCP 的下限。
| 评级 | TTFB |
|---|---|
| 良好 | 不超过 800 毫秒 |
| 需改进 | 800 毫秒–1.8 秒 |
| 较差 | 超过 1.8 秒 |
TTFB 包含什么
| 部分 | 耗时来自 |
|---|---|
| 重定向 | 每跳一次(http → https → www)就多一个往返 |
| DNS 查询 | 解析域名 |
| 连接和 TLS | 建立连接、完成安全握手 |
| 服务端处理 | 数据库查询、页面渲染、没有缓存的页面 |
一个示例拆解
示例数据:某商店的 P75 TTFB 是 1.4 秒:两次重定向 0.3 秒(广告链接 http:// 跳 https:// 再跳 www),DNS 0.05 秒,连接和 TLS 0.15 秒,服务端生成一个没有缓存的分类页 0.9 秒。
两项优化:广告链接直接指向最终地址(重定向没了);分类页 HTML 在 CDN 上缓存几分钟(服务端 0.9 → 0.2 秒)。新的 TTFB:0.05 + 0.15 + 0.2 = 0.4 秒。
怎么降低 TTFB
- 链接直接指向最终地址,去掉重定向链。
- 在边缘节点缓存 HTML,哪怕只缓存很短时间。
- 用 CDN,让连接在离访客近的地方建立。
- 排查慢的服务端工作:渲染时发起的数据库查询和第三方接口调用。
- 按国家和设备看 TTFB;本地市场快,可能掩盖了其他地区慢。
在 TapCub 里看首字节时间
TapCub 用站点脚本从真实访问里采集 Web Vitals(第一个页面隐藏时上报一次;用 data-vitals="false" 关闭)。在网站统计 › 监测 › 性能里,卡片可在 P75、中位数、P95 和平均值之间切换,分组可按页面、设备、浏览器、国家和操作系统拆分,「最慢页面」按 P75 最大内容绘制排序。详见性能文档。 那里的加载拆分图还会把每次加载分成后端响应(首字节)、网络传输和前端渲染三段。
这个解释清楚吗?
我们会根据反馈修改和补充这篇内容。
提交没有成功,请稍后再试。
谢谢你的反馈,我们会据此改进这篇内容。你已经反馈过这篇了,谢谢。
