大型 SPA 的性能问题，往往不是某一天突然出现的。
它更像一条慢慢累积的曲线：
- 页面越来越多
- 状态越来越复杂
- 功能越来越交叉
- 一个改动开始影响更大范围的渲染
很多团队在这时会先想到几个经典动作：
- 分包
- 懒加载
- 图片压缩
这些都重要，但它们通常只解决了问题的一部分。大型 SPA 真正的难点，是性能问题已经从“资源加载”扩展成“系统结构”问题。
第一类瓶颈通常是加载，第二类瓶颈通常是更新
团队最容易发现的是首屏慢：
- 包太大
- 路由切换第一次进入太重
- 依赖膨胀
但项目进入中后期，更伤体验的常常是更新链路：
- 某次筛选导致整页重渲染
- 某个 store 改动带动多个区域一起刷新
- 某些组件本来无关，却被父层状态连带更新
如果团队只盯加载，不处理更新链路，SPA 依然会越来越卡。
大型 SPA 要先识别“重页面”与“重交互”
不是每个页面都需要同样的优化手段。
更稳的做法是先分类：
- 重页面：模块多、依赖多、首次进入重
- 重交互：筛选、拖拽、表格、编辑器、图表等高频操作重
前者更偏向资源和路由层优化，后者更偏向渲染和状态层优化。
状态扩散是大型 SPA 最容易被低估的性能源头
很多性能问题，表面上看像组件慢，实际上是状态边界过宽：
- 一个全局 store 承担太多职责
- 某个页面局部状态被错误提升到全局
- 同一份数据在多个区域重复订阅
结果就是很小一次变化，也会触发更大范围的重渲染。
大型 SPA 的优化，很多时候不是“让组件更快”，而是“让状态影响范围更小”。
路由分割只是起点，不是终点
代码分割当然仍然重要，但大型 SPA 常见的问题是：
- 路由分开了，公共 chunk 还是过大
- 首屏之外的预取策略不合理
- 某些页面组件内部依然一次性装入太多依赖
所以更稳的判断方式不是“做没做分包”，而是：
- 用户当前路径真正需要哪些资源
- 哪些资源必须现在拿，哪些可以延后
- 哪些重模块可以只在特定交互后加载
失败案例：首屏优化做了很多，业务高频页依然卡
这类情况非常常见：
- Lighthouse 看起来进步明显
- 首屏资源也降下来了
- 但用户抱怨最多的仍然是后台列表、筛选和编辑场景
原因往往是优化集中在“看得到的入口页”，而高频业务页的渲染与状态成本没有被治理。
这说明大型 SPA 的性能工作不能只围绕首屏，而要围绕真实使用路径。
优化顺序要从“最值钱的慢点”开始
一个更现实的顺序通常是：
- 先找高访问且高交互的慢页面
- 再拆资源和状态边界
- 再治理长任务和渲染范围
- 最后再做更细节的微优化
这样做更容易把性能投入转成真实业务收益。
一份可直接复用的检查清单
- 当前性能问题主要在加载链路，还是更新链路
- 页面是否区分了重页面和重交互场景
- 状态是否被限制在最小必要范围内
- 路由分割之后，关键公共依赖是否仍然过重
- 优化是否围绕高频使用路径而不是只围绕首屏
总结
大型 SPA 性能优化的核心，不是单点技巧堆叠，而是把资源、状态、渲染和交互一起当成系统问题来治理。只要先找到真正值钱的慢点，再缩小影响范围，SPA 就能从“越做越重”重新回到“可持续演进”。
进一步阅读：
