TTFB（Time To First Byte）是用户拿到第一个字节前的等待，它决定了后续一切速度的起点。TTFB 高，再怎么优化前端都救不回首屏，是速度问题里最该先治的根。
速度是技术 SEO 主线之一，系统讲法见技术SEO 实战手册的速度章节，本文专讲 TTFB 怎么压下来。
快速结论
- TTFB 是速度起点，高则首屏必慢。
- 先定位瓶颈在 DNS、连接、还是源站处理。
- 源站加页面缓存、优化慢查询是主战场。
- CDN 与就近节点能显著缩短物理距离。
TTFB 是什么、为何关键
从浏览器发出请求，到收到服务器第一个字节，这段耗时就是 TTFB。它涵盖 DNS 解析、建立连接、服务器处理并生成响应。前端优化只影响”收到首字节之后”的渲染，而 TTFB 是之前的”等待”，再好的前端也补不回开头的延迟，所以它是速度的真正地基。
对 SEO，TTFB 直接影响 LCP 与整体体验，也是服务器健康度的镜子。它高往往意味着源站忙、逻辑重或链路远，这些问题不解决，后面再怎么压缩图片都事倍功半。把 TTFB 当头号指标来打，是提速里性价比最高的认知，方向对了力气才不白花。
先定位瓶颈在哪一层
TTFB 高要分因：是 DNS 慢、TCP 握手慢、还是服务器处理慢。用 waterfall 视图看各阶段耗时就知道——若连接阶段长，问题在网络/基础设施；若等待（服务器）阶段长，问题在源站逻辑。不同因解法完全不同，盲目动前端毫无用处，先测再治。
一个常见误判是把所有慢归咎于”没上 CDN”。若瓶颈在源站处理（等待阶段长），CDN 只能缓存结果、对未缓存请求仍要回源，于事无补。定位清楚，才知道该投在缓存、数据库还是网络上。诊断优先，是 TTFB 优化不跑偏的前提，也呼应抓取预算优化的”先找主因”。
源站优化：缓存与查询
对动态站点（如 WordPress），最立竿见影的是页面缓存：把”每次请求都查库拼页面”变成”第一次生成后存静态、后续直接返”，TTFB 能从几百毫秒降到几十毫秒。配合对象缓存（如把数据库查询结果缓存进内存），重复请求几乎不碰数据库，源站压力骤减。
再查慢查询：缺索引、复杂联表、N+1 查询都会拖慢响应。用数据库分析工具找出最慢的几条，加索引或改写，往往单点就能砍掉大半等待。源站优化是 TTFB 的主战场，做好了 CDN 只是锦上添花；做不好，CDN 也救不了回源慢，次序不能颠倒。
用 CDN 缩短物理距离
CDN 把内容放到离用户近的边缘节点，DNS 与连接阶段都更短，已缓存内容直接边缘返回，TTFB 显著下降。对全球或跨地域用户多的站，CDN 是缩短物理距离最有效的手段，把”从地球另一端取”变成”从隔壁取”，起点就赢了一截。
但要注意：CDN 对”未命中缓存”的请求仍要回源，若源站慢，这部分 TTFB 不受影响。所以 CDN 与源站优化是互补而非替代——源站先做快，CDN 再把快结果推到用户门口。两者叠满，TTFB 才真正压到健康线，单靠一边都有天花板，配合才是完整解法。
服务端配置与运行时
运行环境本身有油水：启用持久连接（HTTP 复用）、开 Gzip/Brotli 压缩响应、用新协议（HTTP/2、HTTP/3）减少握手开销，都能降 TTFB。PHP 等运行时调高 OPcache、避免每次重新编译，也能砍掉可观等待。这些多在主机层面配置，部分零成本。
另要盯住资源占用：共享主机邻居抢资源、进程数不足、内存 swap，都会让响应变慢。升级方案或限制并发、把重任务异步化，能从运行时层面稳住 TTFB。服务端是速度的发动机，发动机调好，前面的网络与缓存才发挥得出来，全链路一起看才有效。
监控与红线
TTFB 不是一次调好就完。内容增长、流量波动、插件新增都会让它回升。设一条红线（如超过某毫秒数即告警），用真实用户字段数据看各地区的 TTFB 分布，重点盯 P75 而非平均。监控让劣化在影响排名前被发现，而非等用户抱怨慢才查。
建议把 TTFB 纳入每月技术体检，和 LCP、INP 同屏对比。它作为起点指标，任何上涨都会连带拖慢后续，所以最该被优先看护。把”压 TTFB”当持续状态而非一次性项目，站点速度才有长期保障，也省的以后为排名下滑反复救火。
真实场景的取舍
TTFB 优化不是每一项都要做满。小站、本地用户为主时，先抓源站缓存与慢查询这两件零成本大头，往往已够用，CDN 可暂缓；全球站则 CDN 是必选项。按用户分布与预算排优先级，把力气花在瓶颈最长的那环，比平均用力见效快，也避免为用而用。
另一个取舍是缓存粒度：全页缓存最猛但动态内容难即时更新，需配合缓存刷新策略。对频繁变动的页可用片段缓存或对象缓存折中。取舍的本质是快与鲜的平衡，没有万能配置，只有贴合业务的配置，边测边调比一次定死更稳，也更符合真实运维节奏。
别忽视连接复用
一个常被忘的细节是连接复用：开启 HTTP 持久连接与 HTTP/2 多路复用，避免每次请求都重新握手，对 TTFB 尤其是高并发小请求场景帮助明显。它和压缩、新协议同属免费或低价的服务器端优化，配置一次长期受益，值得在调优清单里占一条，别只盯着应用层。
图：TTFB 优化 核心要点（运营GO 整理）
| 瓶颈层 | 解法 | 成本 |
|---|---|---|
| 源站慢 | 页面/对象缓存 | 低 |
| 慢查询 | 加索引改写 | 低 |
| 链路远 | CDN 边缘 | 中 |
| 配置旧 | 新协议/OPcache | 免费 |
下一步行动清单
- 用 waterfall 定位 TTFB 瓶颈在哪一层。
- 启用页面缓存与对象缓存。
- 分析并优化最慢的数据库查询。
- 用 CDN 缩短未缓存外的物理距离。
- 开新协议与压缩，设 TTFB 告警红线。
