网站打开慢，用户往往等不到三秒就关掉了。但“慢”只是一个结果，真正的原因可能出在好几个环节。这篇教程带你按顺序一层层排查，不需要专业的运维背景也能上手。
第一步：先确认慢在哪一步
不要一上来就改配置，先定位。用浏览器自带的开发者工具（一般按 F12 打开，切到“网络”面板），刷新页面，就能看到每一个文件的加载耗时。
重点看两个数字：一是网页文档本身的等待时间，二是所有资源加载完的总时间。如果文档等待时间很长，问题多半在服务器；如果文档很快就回来了，但后面的图片和脚本拖了很久，问题就在前端资源。
另外可以换几个不同地区的在线测速工具跑一遍，排除是自己本地网络的问题，避免白忙一场。
第二步：服务器响应是否偏慢
从用户发出请求，到服务器返回第一个字节的时间，业内叫 TTFB。它反映的是服务器的处理能力，可以粗略理解成“服务器想了多久才开口说话”。
- TTFB 在 200 毫秒以内属于正常，超过 500 毫秒就值得查原因。
- 看服务器 CPU、内存是否长期跑满，带宽是否被占满。
- 看程序里有没有慢查询，例如数据量大却没有加索引。
- 看有没有开启页面缓存，动态页面每次都重新生成会明显拖慢速度。
如果是共享主机，还要考虑同一台机器上其他站点是否在抢占资源。
第三步：图片和静态资源有没有“超重”
大部分网站之所以慢，是因为图片太大。手机随手拍的一张照片就有好几兆，直接上传到网页上，用户就得下载好几兆。
- 按实际展示尺寸裁图，不要用大图缩小显示。
- 压缩图片体积，优先使用 WebP 这类体积更小的格式。
- 把多个脚本、样式文件合并压缩，减少请求次数。
- 开启服务器端的传输压缩（Gzip 或 Brotli），让文本类文件传输时变小。
- 首屏之外的图片加上懒加载，滚动到可见位置时再加载。
这些改动通常不需要改代码逻辑，但带来的提速往往最明显。
第四步：CDN 与网络链路是否正常
CDN 就是内容分发网络，它把图片、脚本这类静态文件复制到各地的节点上，用户就近获取，不用每次都跑到你的源服务器。用了 CDN 却不快，通常是下面几个原因。
- 缓存命中率低：说明大量请求还是回到了源站，配置需要检查。
- 回源速度慢：源站本身响应就慢，CDN 也救不了，要先解决第二步的问题。
- 只把网页走了 CDN，图片和脚本没走，等于没发挥它的作用。
- 缓存过期时间设置过短，文件频繁失效重新拉取。
一张自查清单，按顺序做一遍
- 用开发者工具记录一次加载，找出最耗时的三个文件。
- 看 TTFB，判断问题偏向服务器还是前端资源。
- 服务器侧：检查资源占用、慢查询、是否开启缓存。
- 前端侧：压缩图片、合并压缩脚本样式、开启传输压缩、加懒加载。
- 检查 CDN 的缓存命中率与回源速度，确认静态资源都接入了。
- 改完再测一遍，和之前的数字做对比。
排查的核心思路是“先定位、再动手”。每次只改一个地方并记录数据，才能知道到底是哪一步起了作用，也避免把问题越改越乱。