先量化：把“慢”拆成可定位的指标
“打开很慢”不是可执行的结论。动手之前，先把体验拆成几个可测量的指标：首字节时间（TTFB，反映服务端与网络链路）、首次内容绘制（FCP，反映首屏可见时间）、最大内容绘制（LCP，反映主要内容加载完成时间），以及交互延迟相关指标。
数据来源分两类，两者都要看：
- 实验室数据：用性能审计工具在受控环境下跑分，便于复现与逐项对比，但不代表真实用户；
- 真实用户监控（RUM）：采集真实访客在不同网络与设备上的表现，反映分布情况，但单次采集噪声较大。
实验室数据用来定位问题，真实用户数据用来验证效果，两者混用会导致误判。
七个手段与作用层级
| 序号 | 手段 | 作用层级 | 主要改善 |
|---|---|---|---|
| 1 | 图片优化（压缩、现代格式、按尺寸加载、懒加载） | 资源 | 传输体积与 LCP |
| 2 | 资源压缩与精简（CSS/JS 压缩、去除未使用代码） | 资源 | 传输体积与解析时间 |
| 3 | 缓存策略（浏览器缓存、页面缓存、对象缓存） | 服务端与客户端 | TTFB 与重复访问速度 |
| 4 | CDN 与就近分发 | 网络 | 全球访问的 TTFB |
| 5 | 首屏关键路径优化（关键 CSS 内联、字体加载策略、非关键脚本延迟） | 渲染 | FCP 与 LCP |
| 6 | 数据库与查询优化（慢查询、索引、减少重复查询） | 服务端 | TTFB |
| 7 | 渲染与交互优化（减少重排重绘、长列表虚拟化、骨架屏） | 渲染 | 交互流畅度与感知速度 |
优先级排序的依据是“收益 ÷ 成本”。多数站点上，图片与缓存两项往往能解决大部分问题，应优先处理；数据库与查询优化取决于站点后端的实际结构；渲染细节则往往在最后打磨。
优化中的取舍
性能优化不是“越极致越好”，需要权衡：
- 缓存与时效：缓存时间越长，性能越好，但内容更新的可见延迟越大，需要按内容类型分别设定；
- 内联与复用：把关键 CSS 内联能加快首屏，但会牺牲跨页缓存复用，需按页面结构权衡；
- 懒加载与体验：过度懒加载会让用户在滚动时看到大片空白，得不偿失；
- 第三方脚本：统计、客服、地图等功能会显著拖慢页面，应按需精简而不是默认全上。
持续监控，防止回退
性能优化不是一次性项目。一次改版、一个新插件、一张未压缩的图片都可能让成果退回原点。建议把关键指标纳入常规巡检：定期跑一次审计并与基线对比；上线新功能前后各测一次；把资源体积阈值写进构建流程，超标时给出提示。
小结
性能优化的正确顺序是测量 → 定位 → 分层治理 → 回归验证。先确认瓶颈在哪一层，再选择对应手段，最后用同一套指标验证效果。把“从 3 秒到 1 秒”当作目标区间而非口号——目标值应结合业务与用户网络环境确定，并靠持续监控守住。