文章目录
目录导航
快速定位文章内容
正文
前端页面变慢时，我一般不是先优化代码，而是先定位瓶颈
很多性能优化最后没有效果，不是因为方案错了，而是因为问题根本不在你动手改的地方。页面慢，有时候是接口慢，有时候是 JS 计算重，有时候是图片太大，也有时候只是某个列表在重复渲染。对我来说，真正的优化起点不是“先上优化技巧”，而是先判断瓶颈到底在哪里。
我先分四类问题
页面卡顿时，我通常先把问题粗分成四类：
- 网络请求慢
- 资源加载重
- 渲染和重排频繁
- JavaScript 计算过多
这个分类很重要，因为不同问题的处理方式完全不一样。接口慢，你去抠组件 memo 基本没意义；图片太大，你去拆 hook 也不会有本质改善。
首先看是不是网络问题
如果页面是“白着等很久”或者数据迟迟不回来，我会先看请求瀑布图。
重点会看：
- 是首个接口就慢
- 还是很多请求串行触发
- 是服务端响应慢
- 还是前端发请求太晚
很多首屏慢，并不是接口本身慢，而是组件挂载后才一层层触发请求，导致本来可以并行的事情变成串行。
再看资源是不是过重
如果页面一打开下载很多 JS、图片或字体，我会怀疑问题出在资源体积上。
常见信号有这些：
- 首屏图片很大
- 非首屏组件也被一起打进首包
- 图表库、编辑器这类重模块提前加载
- 字体文件过多或没有按需加载
这类问题通常比“代码写得优不优雅”更直接，因为用户连资源都没下完，页面当然快不起来。
页面能打开，但交互卡，就看渲染和计算
有些页面不是慢在加载，而是慢在操作，比如输入卡顿、切 tab 卡顿、滚动掉帧、打开弹窗顿一下。这时候我会重点看：
- 有没有大列表整块重渲染
- 有没有高频 state 更新
- 有没有把重计算放在渲染路径里
- 有没有不必要的 effect 连锁触发
const filteredList = list.filter((item) => heavyMatch(item, keyword))
像这种计算如果每次输入都整页重跑，性能差几乎是必然的。先确认它是不是热点，再决定要不要缓存、拆分或者延后计算。
我很少一上来就“全面优化”
经验越多，我越不喜欢那种没有结论就先做一堆优化动作：
- 到处加 memo
- 先上虚拟列表
- 先拆几十个组件
- 先改成更复杂的状态管理
这些动作不是永远没用，而是如果你还没找到真正热点，就很容易花很多时间，却只换来一点点表面改善。
我现在更常用的顺序
- 先复现慢在哪个环节。
- 再用面板确认是网络、资源、渲染还是计算。
- 找到最重的那一个点。
- 最后才决定具体优化方案。
这个顺序能让我少做很多“看起来很努力，实际上没打中问题”的优化。
结语
前端性能优化最有价值的能力，不是记住多少技巧，而是先把问题归因归对。定位对了，很多优化都很直接；定位错了，再高级的优化动作也可能只是心理安慰。