网站性能排查
网站打开很慢，先定位慢在哪一段
不要先猜服务器、图片或 CDN。先观察主文档、慢请求和浏览器执行发生在哪里，再选择对应优化动作。
先说清楚“慢”发生在哪一段
页面慢可以是很久才收到第一个响应，也可以是 HTML 很快但图片一直加载，或者内容已经出现、点击却迟迟没有反馈。三种现象不能用同一个优化动作解决。
| 你看到的现象 | 优先看什么 | 常见下一步 |
|---|---|---|
| 很久才开始出现内容 | DNS、连接、服务器等待时间 | 看主文档请求的 Timing/TTFB，再区分网络与后端 |
| 文字先出现，图片/视频拖很久 | 资源体积、格式、缓存、CDN | 找最长和最大的资源请求，核对实际展示尺寸 |
| 请求都很快，但页面操作卡 | JavaScript、主线程、设备性能 | 转到 Performance/交互分析，不要继续只压图片 |
| 只有某个地区或网络明显慢 | 网络路径、缓存位置、服务距离 | 固定 URL，在不同网络/地点做可比测试 |
| 实验室很快，真实用户数据差 | 设备、地区和长期真实访问条件 | 分开看实验室测试与真实用户数据 |
用 Network 面板时，先看三个东西
- 主文档请求：它能帮助判断页面起步是否就在等待连接或服务器。
- 最慢/最大的请求：不要先猜图片、字体或第三方脚本，先看实际请求。
- Timing / Waterfall：把等待服务器、连接和资源下载分开，才能知道改哪里。
Chrome DevTools 的 Network 面板可以查看请求状态、大小、耗时、瀑布和 Timing；这些数据比“体感慢”更适合定位瓶颈。
| 观察到的结果 | 更值得先查 | 不要先下的结论 |
|---|---|---|
| 主文档很久才开始返回 | 连接阶段、服务器处理、缓存命中 | 不要先把问题归咎于图片 |
| HTML 很快，但大图/字体拖很久 | 资源尺寸、格式、缓存、CDN | 不要先换后端服务器 |
| 请求都不慢，但点击和输入卡 | JavaScript、主线程长任务、第三方脚本 | 不要只看下载带宽 |
| 实验室测试快，真实用户数据差 | 地区、设备、长期流量与真实用户分布 | 不要用单次本地测试否定真实用户问题 |
不要把性能分数当成问题本身
Core Web Vitals 用 LCP、INP、CLS 等指标描述加载、交互响应和视觉稳定性，但用户问题仍要回到具体页面和具体阶段。一个分数变差只是线索，不等于自动得出“换服务器”或“加 CDN”的结论。
图片值得优先检查，但不是万能答案
大图、尺寸远高于展示尺寸、没有合适压缩和过早加载大量媒体都很常见。若 HTML 等待本身就很长，单纯压图片不会解决服务器等待；反过来，主文档很快而媒体资源占满瀑布时，图片优化才更值得先做。
比较优化前后时，保持测试条件
至少保持同一个 URL、相近测试位置、设备/网络条件和缓存策略。一次偶然高分或低分都不适合证明长期变化；如果站点有真实访问数据，应把实验室结果和真实用户数据分开理解。
先区分服务器慢与页面资源慢
打开浏览器开发者工具的 Network 面板，刷新页面并查看最初的 HTML 请求。如果主要等待发生在接收 HTML 之前，应先核对服务器响应、缓存和网络路径；如果 HTML 很快返回，却在图片、字体或脚本阶段迟迟不能使用页面，继续检查资源大小、加载顺序与主线程任务。
测速时同时记录移动/桌面条件、测试地点、缓存状态，以及是否使用同一个 URL。性能测试工具入口可从 网站性能测试分类 找到。仅凭一次 Lighthouse 分数，无法证明真实访客体验已经改善。
先改最大的可确认瓶颈。如果主文档等待明显最长，就先查后端/缓存；如果少数资源占了绝大多数传输体积，就先处理这些资源。不要一次同时换主机、CDN、图片格式和前端框架，否则很难知道哪项改动真正有效。