首字节时间（TTFB）慢的优化思路

TTFB（Time To First Byte，首字节时间）指从浏览器发出请求到收到响应第一个字节的时间，用户感觉站点灵不灵，很大程度看这个数。优化之前，先把它拆开看，搞清楚时间花在哪一段，才不会修错地方白忙一场。单次测量受偶发因素影响，多测几次取中位数更接近真实水平，办公网和手机流量各测一组对比着看。 一条命令拆解耗时 curl -o /dev/null -s -w "dns:%{time_namelookup} conn:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer}\n" https://example.com 输出四段：DNS 解析、TCP 连接、TLS 握手、到首字节。相邻两段相减，就知道时间花在哪一段。通常 ttfb 减去前几段之后剩下的大头，是服务器内部的处理时间，也是优化空间最大的部分。 服务器处理是大头 动态页面每次请求都完整走一遍 PHP 加数据库，处理几百毫秒很常见。两个改动小、收益直接的方向：给慢 SQL 建索引，把数据库的慢查询日志打开，long_query_time 先设 0.2 秒，跑一天就能抓到全部嫌疑语句，用 EXPLAIN 看执行计划确认没有全表扫描；php.ini 打开 opcache（opcache.enable=1），PHP 字节码不再每次请求重新编译，CPU 占用立竿见影地降下来，流量大的站点光这一项就省出一笔升级费用。 缓存缺失 内容更新不频繁的页面适合整页缓存，把动态请求变成直接吐文件，TTFB 能从几百毫秒降到几十毫秒。Nginx 侧最省事的是 fastcgi_cache，两行核心配置： fastcgi_cache_path /var/cache/nginx levels=1:2 keys_zone=pagecache:10m; fastcgi_cache pagecache; 带登录态的页面注意缓存键要区分用户，或者干脆排除在缓存之外，宁可慢一点也不能串数据，这一点上没有可妥协的空间。 DNS 与重定向 DNS 段超过 100 毫秒就查一查：TTL 是不是设得太短，解析记录里 CNAME 链是不是套了好几层，链路每多一跳就多一次查询。另一个隐性开销是重定向链——http 跳 https 再跳 www，要连跳两次才到真身，把跳转收敛成一次。服务器负载常年跑满的情况，先升配置，再谈代码优化，顺序别反，配置和代码的优化都建立在资源够用的前提上。