TTFB 高的时候，先别换机房。今年 1 月我们查过一个 SaaS 的首页，移动端首字节 1.4 秒，团队第一反应是"服务器不行"，准备换云厂商。查下来 800 毫秒花在服务端自己身上，换到哪儿都一样。
先把 TTFB 拆开看。用 curl 的耗时分解，一个请求能拆成五段：
curl -o /dev/null -s -w "dns:%{time_namelookup} tcp:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer}\n" https://example.com/
time_starttransfer 减去前面几段，剩下的才是服务端处理时间。这个站 DNS 30 毫秒、TLS 120 毫秒、传输 90 毫秒，剩下 800 毫秒就是后端在算。
服务端那 800 毫秒在干什么
那个站一次页面请求串行调了 6 个接口，最慢的一个 340 毫秒。6 个加起来 1.1 秒，有并发，实际 800 毫秒。前端一直以为是网络问题，因为监控上只看到"页面慢"三个字。
查法是看应用侧的链路追踪，或者最土的办法：在服务端入口加时间日志，记每个接口的耗时。这个客户加完日志第二天就定位了，比讨论一周有用。
改法：能并行的并行，能缓存的缓存
我们做了两件事：6 个接口里 4 个改成并行，总耗时从 800 降到 260 毫秒；首页那块"最新公告"从实时查库改成 60 秒缓存。TTFB 从 1.4 秒降到 480 毫秒，同一批机器。
什么情况才该怀疑网络
三种情况我才会建议查链路：TTFB 在 200 到 400 毫秒之间但各地差异大；静态资源也慢；TLS 握手占 300 毫秒以上。这三种通常指向线路或者 CDN 节点问题，和服务端代码无关。
还有个粗糙但好用的判断：如果你的静态 HTML 的 TTFB 就很高，那是基础设施；如果只有动态页慢，那基本是代码。这个判断一分钟能做完，比开会讨论有用。
一个容易误判的情况
首页慢、产品页快，这种情况很常见，因为首页的接口最多。我们查过一个站，产品页 TTFB 210 毫秒，首页 1.3 秒，团队按首页的平均值去投诉机房，方向完全错了。
正确做法是按页面类型分组统计 TTFB，每种取 P75。营销页、文档页、后台页分开看，差异往往比你想的大。
我们给客户的检查顺序
第一步，挑三个页面（首页、一个产品页、一个文档页）用 curl 各跑五次，记下五段耗时。第二步，把服务端那一段和接口日志对上。第三步，才决定是改代码、加缓存还是查线路。
这个顺序的好处是成本低。三步做完，半小时，能排除八成误判。最怕的是先入为主地认为是网络问题，换了一圈机房，最后发现是接口没并行。
最后一句：换机房是成本最高、见效最不确定的一招。我们接手过的性能项目里，真正靠换机房解决问题的只有两次，都是国内单线机房那种情况。
元析智能
为软件公司做 SEO 和 GEO 优化