性能优化最怕「到处抠细节却没量过」。建议顺序是：先测量 → 找最大瓶颈 → 改一两处再复测。下面按常见收益排序，方便当作清单勾选。
一、先看清指标
- LCP：最大内容多久画出来（首屏感受）。
- INP / FID：交互是否跟手。
- CLS：布局是否跳动。
- 资源体积、请求数量、主线程长任务。
Chrome DevTools 的 Performance / Lighthouse，或 Web Vitals，都够入门使用。
二、加载阶段（通常收益最大）
- 压缩与缓存：开启 gzip/brotli，静态资源带 hash 长缓存。
- 图片：合适尺寸、现代格式（WebP/AVIF）、懒加载非首屏图。
- 字体：
font-display: swap，只加载用到的字重。 - 关键 CSS/JS 优先；非关键脚本
defer/ 延迟加载。 - 减少重定向与阻塞第三方脚本。
三、渲染与主线程
- 避免在滚动、输入回调里做重计算；必要时节流或交给
requestAnimationFrame。 - 减少强制同步布局（先读几何再写样式的交错）。
- 长列表考虑虚拟化；大 JSON 解析可拆分或延后。
- 动画优先改
transform/opacity，少触发整页重排。
四、交互体验
- 按钮点击后立刻给反馈（禁用态、骨架屏），别等接口回来才动。
- 防抖搜索输入；取消过期请求，避免旧响应覆盖新结果。
- 预取下一页关键数据（在带宽允许时）。
五、一份最小行动清单
[ ] 用 Lighthouse 跑一次移动端评分，记下 LCP / CLS
[ ] 首屏图是否过大？能否压缩或换格式？
[ ] 是否有阻塞渲染的超大 JS？
[ ] 字体是否拖慢文字出现？
[ ] 列表滚动是否掉帧？有无长任务？
[ ] 改完复测，确认指标真的变好优化是取舍：过早微优化会浪费时间。先解决用户感知最明显的那一截延迟。
小结
入门阶段把「测量 → 加载 → 主线程 → 交互反馈」这条线走通，已经能覆盖大部分站点问题。等基础扎实了，再深入缓存策略、边缘渲染、更细的打包分析会更有的放矢。