2026 年 6 月一个客户说 TTFB 到了 1.4 秒，要换服务器。我们让他先别换，拆开时间一看，后端处理只占 180 毫秒，剩下全是 DNS 和跨地域连接。换机器花钱，解决不了问题。
TTFB 由五段组成
DNS 解析、TCP 连接、TLS 握手、请求排队、后端处理。这五段加起来才是 TTFB。
国内访问一个没做优化的站，DNS 可能 80 毫秒，TCP 加 TLS 又是 200 多毫秒，后端 300 毫秒，加起来就超过 600 了。
很多人只盯着后端，其实前三段在网络层，换服务器不一定能改善。
怎么把时间拆开
一条 curl 命令就够，加 -w 参数输出各阶段耗时，重点看 time_namelookup、time_connect、time_appconnect、time_starttransfer 四个值。
差值的含义很清楚：nameLookup 是 DNS，connect 减 nameLookup 是 TCP，appconnect 减 connect 是 TLS，starttransfer 减 appconnect 就是后端处理加首字节。
我们的习惯是同一个 URL 在不同城市测三次，取中位数。单次数据没意义，网络抖动太常见。
后端慢的三种情况
第一种，慢查询。列表页、搜索页、详情页，一个 SQL 没走索引就能把 TTFB 拖到一秒以上。
第二种，串行调用。服务端渲染时依次请求三个外部接口，每个 200 毫秒，加起来就是 600。
第三种，没缓存。每次请求都重新拼页面、重新查数据库，明明内容十分钟才变一次。
缓存能解决多少
页面缓存是最有效的，命中时 TTFB 能压到 50 毫秒以内。对象缓存次之，能省掉数据库查询。
但要看清缓存命中率。我们见过一个站配了 CDN 缓存，命中率只有 12%，因为缓存键里带了用户 ID，等于没缓存。
什么时候换服务器有用
三种情况：CPU 长期打满、单机磁盘 IO 成为瓶颈、用户和机房跨地域。
跨地域这条最容易被忽略。服务器在美西、用户在国内，TCP 和 TLS 的往返就有 300 毫秒起步，换更贵的机器也没用，得加节点或者用 CDN。
一次真实的拆段
2026 年 4 月我们给一个文档站拆 TTFB，总时长 1.2 秒：DNS 180 毫秒、TCP 220、TLS 260、后端 480。前三段加起来 660 毫秒，比后端还多。
换了 DNS 服务商、把 TLS 升到 1.3、加了一个国内节点之后，前三段降到 210 毫秒。后端一行代码没改，TTFB 变成 690 毫秒。
这件事的教训很直接：网络层和后端层要分开算账，不然会误以为要重写服务。
一个判断标准
TTFB 800 毫秒是我们的分界线。低于这个数，先把 LCP 里的图片和渲染问题解决；高于这个数，先拆时间，别急着动代码。
拆完你会发现，真正需要改代码的情况不到一半，大多数是网络路径和缓存策略的问题。这两件事改起来比重构便宜得多。
元析智能
为软件公司做 SEO 和 GEO 优化