本文目录
"网站很慢"是个笼统的描述。有人说的慢是首屏白了三秒，有人说的慢是点了链接要等两秒才跳转，还有人说的慢是图片一张张往下蹦。定位方式完全不同。
先分段测
用浏览器开发者工具的网络面板，看三个数字：DNS 与连接耗时、首字节时间（TTFB）、页面完全加载时间。
- TTFB 超过 800 毫秒：问题在服务端或数据库
- 连接耗时长：问题在 DNS 或机房线路
- TTFB 正常但加载慢：问题在前端资源
这三个数字能砍掉一半的猜测。很多人一上来就压缩图片，结果服务器本身要两秒才响应，怎么压都没用。
服务端常见原因
没开缓存、每次请求都查数据库、图片没有做缩略图导致原图直出、PHP 进程数不够、服务器在境外但用户在国内。前四个都能在一天内解决，最后一个要换机房或加 CDN。
还有一种隐蔽的情况：日志写入过于频繁。有些插件把每次访问都同步写文件，访问量一上来，磁盘 IO 就成了瓶颈。
前端常见原因
图片没压缩、字体文件加载了五六个字重、JS 在头部同步加载、第三方统计和客服脚本堆了七八个。检查方法：按体积排序资源列表，前五项基本就是元凶。
第三方脚本要特别留意。一个客服插件可能带来三百 KB 的 JS 和两个额外的域名解析，而它对转化的贡献往往并不大。
移动端要单独测
同一页面在 4G 下的表现和在办公室 WiFi 下完全是两件事。测试时要用真实的移动网络，不要只用桌面浏览器模拟——模拟只改窗口尺寸，不改网络延迟。
优化顺序
先修 TTFB，再压图片，再处理第三方脚本，最后才是代码层面的合并压缩。顺序反了，会在 5% 的收益上花掉 80% 的时间。
每改一项就复测一次，记录前后数字。没有基线的优化，最后只能靠感觉判断有没有效果，也没法向老板解释钱花在哪。
CDN 不是万能药
很多人第一反应是上 CDN，但如果慢在数据库查询，CDN 只能缓存静态资源，动态页面照样慢。判断方法：看缓存命中率，命中率低于六成，说明大部分请求仍然回到源站。
另一个常见误区是把所有图片都交给 CDN，却不改尺寸。一张四兆的原图，走再快的节点也要几秒才能下完。先按展示尺寸裁切压缩，再谈分发。
如果预算有限，优先把钱花在机房与带宽上，而不是堆插件。线路问题靠软件解决不了，这是很多团队绕了两年的弯路。
最后的判断标准
优化到什么程度算够？给一个可用的标准：手机上用 4G 打开，两秒内能看到主要内容。达不到就继续，达到了就先停下来做内容，速度的边际收益会越来越小。
速度优化的第一步不是优化，是测量。先有基线，再谈提升。
如果只做三件事
把上面的方法压缩成一份执行清单，按顺序做：
- 分段测，先分清是网络、服务端还是前端；
- 压图片与视频，这一项通常收益最大；
- 查第三方脚本，统计、客服、广告往往才是拖慢首屏的主因；
三件事做完再谈细节，顺序反了，投入很容易打水漂。
