用户甩来一句“你这网站怎么这么慢”，你自己点开却觉得还行。慢是个相对概念，同一份页面，在宽带电脑上、在信号一般的手机上、在外地访客那里，体验能差出一大截。所以谈优化之前得先把口径统一：多测几次取中间值，盯着用户实际在意的那个阶段，别拿自己的一次刷新下结论。口径定完，再按请求走过的顺序，从服务器一路优化到前端，每段都有值得做和不必做的地方。
一、先把服务器资源这一层排干净
前端的功夫做得再足，后端资源吃满也白搭。判断方法很直接：看负载是不是长期超过 CPU 核数，看内存是不是被吃到要靠 swap 撑，看磁盘 IO 是不是常年跑满。负载高、swap 频繁读写、IO 等待明显，说明用户等的时间根本不在页面上，而在机器上，先扩容或者优化程序，别急着压图片。
先从机器本身看。下面这几条命令把负载、内存、磁盘使用率和 IO 等待一次打出来，这几项正常再往下查。
# 负载与运行时长（load 长期高于核数就要警觉）
uptime
# 内存与 swap（swap 用得多说明物理内存不够）
free -m
# 磁盘使用率与 IO 等待
df -h
iostat -x 1 3
# 找出最吃 CPU 的进程
top -b -n 1 | head -20这里有个常见的误判：看到 CPU 不高就以为服务器没问题。实际上不少慢站卡在磁盘 IO 或者内存换页上，CPU 反而挺闲。iostat 的等待时间和 free 里的 swap 使用量，是这两类瓶颈的直接证据。
二、数据库这一层，慢查询是隐形大户
同一条 SQL，有没有走索引，耗时能差出几个数量级。把慢查询日志打开，阈值设成 1 秒，跑一天，然后按耗时排序看前二十条。绝大多数情况会发现：某几个查询没走索引，或者在循环里被反复调用。给这几个查询补上索引、把循环查询合并成一次批量查询，带来的提速往往比前端折腾一个月还明显。
三、程序层，缓存和外部调用
页面每次请求都重新查一遍数据库、渲染一遍模板，是非常普遍的浪费。给不常变的内容加一层页面缓存或者对象缓存，命中之后数据库压力立刻降下来。缓存的对象要挑，经常变的内容缓存了反而出问题，登录态、订单详情这类数据一旦缓存，用户就可能看到别人的信息。另一个高频问题是对外部接口的调用没有设超时，对方一慢，你的页面就跟着一起挂住。所有跨机器调用都应该有超时时间和失败兜底，这是底线，不是优化。
四、传输层，让文件变小、变少、走得更近
到这一层才轮到大多数站长熟悉的招数：开压缩、加缓存头、上 CDN。压缩能让文本类文件体积掉一大截，缓存头能让回头客不重复下载，CDN 能把内容放到离用户更近的节点。这三件事配置成本低、收益直接，优先做。
到了 Web 服务这一层，下面这段 nginx 配置可以直接抄：开文本压缩、给静态资源加长缓存。改动前记得先备份原配置。
server {
listen 443 ssl;
server_name www.example.com;
# 开文本压缩，图片和视频不要压，压了也没效果还费 CPU
gzip on;
gzip_comp_level 5;
gzip_min_length 1024;
gzip_types text/plain text/css application/json application/javascript application/xml image/svg+xml;
# 静态资源加长缓存，靠文件名版本号来更新
location ~* \.(css|js|png|jpg|jpeg|gif|webp|svg|woff2)$ {
expires 30d;
add_header Cache-Control "public, max-age=2592000";
access_log off;
}
# HTML 不缓存或者只缓存很短时间，避免用户看到旧页面
location ~* \.(html)$ {
expires 5m;
add_header Cache-Control "public, max-age=300";
}
}配置里有个细节值得强调：静态资源的缓存时间可以放长，因为改版时你会换文件名；HTML 的缓存必须短，否则用户改版后还在看旧页面，投诉就来了。两者弄反，比不缓存还麻烦。
五、前端层，图片和阻塞资源
首屏里最大的那个文件，通常是图片。上传前压一遍、按实际展示尺寸裁一遍、能用新格式就用新格式，这三点做掉，图片体积往往能减一半以上。另外要把渲染阻塞的资源处理掉：首屏不需要的脚本延迟加载，样式表里塞了整站用不到的框架 CSS，该拆就拆。还有个成本容易被忽略，每多一个资源就多一次请求，请求数和单个文件大小要一起看，有时候合并文件比压缩单个文件更有效。用户感知的慢，很多时候第一屏就定死了。
六、动手顺序：从下往上，从收益大的先做
顺序建议是：服务器资源 → 数据库 → 程序缓存 → 传输压缩与 CDN → 前端资源。原因很实在，越靠下的问题影响面越大，修一处全站受益；越靠上的改动越细，收益还容易被下层瓶颈吃掉。反过来先做前端，很可能前端指标变好了，用户体感一点没变。
七、改完怎么验证
每改一处，用同一种测量方式再测一遍，看那个具体指标有没有动，没动就说明改错了方向或者改得不彻底。一次只改一个变量，改完对比，这是唯一能说清“是哪个动作起了作用”的办法。全堆在一起改，最后看到变快了也不知道该保留什么。
相关阅读：
A5创业网 版权所有