一个页面加载慢，可能是首图没压过，可能是后端接口三秒才给响应，也可能是解析绕了远路。凭感觉优化，最常见的结局是前端折腾半个月，最后发现瓶颈在数据库的一条慢查询上。所以这篇不讲优化技巧，只讲一件事：怎么把瓶颈测出来。数据摆到桌面上，改哪儿、值不值得改、改了有没有用，答案自然就出来了。
一、不测就改，是优化里最贵的错误
凭感觉改的人有个共同习惯：看到什么就动什么。图片大就压图片，脚本多就删脚本，改完体感好像顺了一点，其实可能只是那天网络好。真实的页面耗时里，浏览器里花掉的时间往往只占一部分，大头藏在你平时看不见的地方。不测，你根本不知道那部分在哪，自然也无从下手。
二、第一把尺：让 curl 把一次请求拆成几段
最快的测量方式是在命令行里发一次请求，让它把各个阶段的耗时直接打出来。这几段的分界线，正好就是整条链路的关键节点：解析花了多久、建立连接花了多久、HTTPS 握手花了多久、服务器多久给出第一个字节、正文传完又要多久。
下面这条命令发一次请求，把解析、连接、握手、首字节、正文传输各阶段的耗时一次打出来，瓶颈在哪一段一目了然。
# 分段计时：把一个请求各阶段耗时打出来
curl -o /dev/null -s \
-w "dns=%{time_namelookup}s connect=%{time_connect}s tls=%{time_appconnect}s ttfb=%{time_starttransfer}s total=%{time_total}s size=%{size_download}bytes\n" \
https://www.example.com/
# 连测五次，避免拿一次偶然结果下结论
for i in 1 2 3 4 5; do
curl -o /dev/null -s -w "第 $i 次 ttfb=%{time_starttransfer}s total=%{time_total}s\n" https://www.example.com/
done最后那个 ttfb 是最值得盯的一个数，它代表服务器从收到请求到吐出第一个字节花了多久，把后端所有的慢都算进去了。size 那一项则是页面正文的体积，心里有个数，后面判断“是传输慢还是内容大”时用得上。
三、怎么读这组数字
dns 那一段偏大，说明解析慢或者解析服务器响应差，方向是换解析服务商、减少解析层级、缩短链条。connect 偏大，说明网络绕路或者服务器接入层慢，方向是查线路和 CDN 接入。tls 偏大，是 HTTPS 握手开销大，方向是开会话复用。ttfb 偏大，说明后端处理慢，方向是查程序、数据库和资源。total 减去上面几段剩下的部分如果偏大，就是正文体积太大，方向是压缩和瘦身。
读数有个前提：跑一次不算数。至少连测五到十次，看最大最小值差多少。如果每次结果跳动很大，说明这个站的性能本身不稳定，先解决稳定性，均值快慢反而次要。
四、第二把尺：浏览器瀑布图
curl 看的是“一次请求”，浏览器看的是“一整个页面”。打开开发者工具的网络面板刷新一次，按耗时排序，谁是最大的那个文件、哪个接口卡住了、有没有一串文件在排队，全都摊在眼前。看的时候盯两条线：最慢的那个决定首屏能不能出来，数量最多的那一类文件决定总开销有多大。
瀑布图里还有个容易被忽略的信息：请求的开始时间是错开的。如果看到大量资源都在等同一个文件先加载完，那就是典型的阻塞链，把那个文件拆开或者改成异步，收益比压图片更明显。
五、第三把尺：服务器侧，分清是机器吃力还是代码慢
从前面两把尺拿到 ttfb 偏大的结论之后，还要再往下分一层：是机器扛不住，还是代码本身慢。看负载、看内存和 swap、看磁盘 IO 等待，再看数据库的慢查询。这几个数都不高，那多半是程序逻辑的问题，比如在循环里查库、外部接口没设超时。
拿到首字节耗时偏大的结论之后，再用下面这几组命令分一层：是机器扛不住，还是代码本身慢。
# 机器层面：负载、内存、IO 等待
uptime
free -m
iostat -x 1 3
# 数据库层面：按耗时排序看慢查询
mysql -uroot -p -e "show variables like 'slow_query_log';"
mysql -uroot -p -e "show variables like 'long_query_time';"
# Web 层：哪些请求特别慢，看 $request_time 字段
awk '{print $request_time, $7}' /var/log/nginx/access.log | sort -rn | head -20最后那条命令按请求耗时排序，是抓“个别慢请求”的利器。整站平均速度还行，但总有用户投诉某个页面要转半天，答案基本都在这个列表的头几行里。
六、单次快不代表扛得住
自己一个人访问很快，十个用户同时访问就卡，这是完全不同的两件事。用小并发压一压，看平均耗时和失败率随着并发数怎么变。单次测量反映的是最好情况，压力下的表现才接近真实高峰。压测时注意别把生产环境压垮，先从小并发起，看曲线在哪里开始拐弯，那个拐点就是这个站当前的实际承载能力。
七、测完再改，改完再测
测量、定位、只改一处、再测一次，这个循环跑三遍，你对这个站的理解会比看十篇优化教程都深。反过来，跳过测量直接套别人的配置模板，改得越多越乱，最后连哪一步起了作用都说不清楚。瓶颈只有一个，找出来，别在别的地方浪费力气。
相关阅读：
A5创业网 版权所有