前端性能排查思路：页面卡顿时，不要一上来就怀疑框架
前端性能问题最让人头疼的地方，不只是慢，而是不知道到底哪里慢。
页面卡顿的时候，团队里常见的第一反应通常是：
- 是不是框架太重
- 是不是组件太多
- 是不是状态管理有问题
这些方向当然可能有关，但如果一上来就把问题归因给“大框架”或“大项目”，通常并不能真正解决问题。
先区分是哪一种慢
性能问题不是只有一种。
常见至少有四类：
- 首屏加载慢
- 页面切换慢
- 滚动卡顿
- 输入、点击反馈慢
这四类问题对应的排查方向可能完全不同。
如果一开始不分类，只说“页面有点卡”，后面优化就很容易到处试错。
首屏慢先看资源和请求
如果用户第一次打开页面就慢，优先看：
- JS 包体积
- 图片资源大小
- 接口耗时
- 阻塞渲染的资源
这类问题实际开发中和框架无关，而是资源策略不合理。
例如：
- 首页一次加载太多模块
- 首屏请求串行
- 大图没有做压缩
- 字体加载阻塞首屏文本渲染
交互卡顿先看渲染链路
如果是点击按钮、切换筛选、输入文本时卡，优先排查：
- 是否有大量不必要的重渲染
- 是否在主线程做了重计算
- 是否列表过大但没做虚拟化
- 是否有动画或布局抖动
这类问题比起网络，更常发生在渲染阶段。
不要把“重渲染”当成唯一答案
很多性能文章喜欢把问题都归结为重渲染，但现实中不一定。
页面卡可能来自：
- JS 计算太重
- DOM 数量太多
- 样式重排频繁
- 动画掉帧
- 第三方脚本抢主线程
所以排查时不能只盯着组件 render 次数。
列表问题特别容易放大性能缺陷
列表是最常见的性能放大器。
一个页面在数据量少时运行正常，数据量一大就明显变卡，这通常说明：
- 每项渲染成本高
- 状态更新影响整表
- 没做分页或虚拟滚动
- 键值不稳定导致节点频繁重建
列表优化的关键不是“让每一项更聪明”，而是减少不必要的整体更新。
排查时尽量用证据，不要靠感觉
性能问题最忌讳“我觉得是这里慢”。
更有效的方式是：
- 看 Performance 面板
- 看 Network 请求瀑布
- 看哪些任务阻塞了主线程
- 看长任务出现在哪里
实际开发中，真正耗时的地方和直觉并不一致。
第三方代码也要纳入排查
真实项目里，性能问题不全是自己代码导致的。
例如：
- 埋点 SDK
- 在线客服
- 可视化监控
- 广告脚本
- 富文本编辑器
这些东西一旦在不合适的时机执行，也会明显拖慢页面。
所以排查性能时，不要只看业务代码。
一个实用顺序
页面卡顿时，比较实用的排查顺序通常是：
- 先明确是哪一种慢
- 再看网络还是渲染主导
- 找出最重的资源、请求或任务
- 再决定是拆包、减渲染、改结构，还是延后加载
这个顺序的好处是，能避免一开始就陷入“我是不是该重构整个前端架构”的过度反应。
写在最后
前端性能排查最重要的不是技巧，而是顺序感。
只要你先把问题分类，再用工具找证据，很多看起来复杂的性能问题都会逐渐变清楚。页面卡顿并不等于框架有罪，更常见的情况是资源、渲染和交互链路里某个环节在被放大。