前端性能优化是一个很容易被碎片化学习的主题。网上有很多技巧，比如图片懒加载、代码分割、防抖节流、缓存策略、虚拟列表、资源压缩等等。最开始我也是这样学的，看到一个技巧就记一个。但真正做项目之后，我越来越意识到，性能优化最重要的不是记住多少招，而是先判断瓶颈到底出在哪里。
因为性能问题本身就分很多类型。有些页面是首屏慢，问题可能出在资源体积太大；有些页面是操作卡，问题可能出在不必要的重复渲染；有些页面是接口慢，看起来像前端问题，其实是请求链路太长。只有先定位问题来源，后续优化才不会变成盲目堆技巧。
我现在做性能优化时，一般会先从用户体验角度看三个问题。第一，页面第一次打开时慢不慢。第二，用户点击、输入、切换时卡不卡。第三，网络不稳定时页面是否还能给出可接受的反馈。很多时候，用户并不关心你用了什么高级技术，他只关心“我是不是点了之后有反应”“这个页面是不是等太久”。
如果把前端性能问题做一个粗分，我会分成渲染层、网络层和资源层。渲染层主要看组件是不是频繁不必要地更新，列表是不是过大，复杂计算是不是放在了主线程上。网络层主要看接口数量、请求时机、串并行关系以及缓存策略。资源层则看图片、脚本、样式和字体等静态资源是否过重。把问题先归类，会比直接上优化招式更有效。
我平时比较常用的一条思路是这样的：
先观察用户感知
|
+-- 首屏慢 -> 看资源体积、脚本执行、接口阻塞
|
+-- 交互卡 -> 看渲染次数、组件结构、主线程任务
|
+-- 列表慢 -> 看分页、虚拟化、局部更新
|
+-- 请求慢 -> 看接口设计、缓存、并发关系
这个流程的核心，是先从现象出发，而不是一上来就假设问题所在。比如一个页面看起来很卡，我以前可能第一反应是“是不是 React 渲染太多了”；但实际排查时，问题也可能只是某个大图片没有压缩，或者一个接口被顺序等待了。性能优化如果没有先做判断，很容易做了很多事，却没有真正改善体验。
在 React 项目里，我越来越关注“渲染是否值得”。并不是每一次状态变化都必须让整棵子树重新走一遍。如果组件边界划分不合理、父组件状态过多、列表项没有良好隔离，就很容易造成局部改动引发大面积更新。这个时候，优化重点往往不是上来就写各种记忆化，而是先反思组件结构是不是本身就不够清楚。
网络层面我也有一个体会：很多所谓性能差，其实是“拿数据的方式不够聪明”。比如首屏必须的数据和非关键数据没有区分，导致所有请求都堆在首次加载里；或者列表页切换条件时没有做缓存，用户每切一次都从头请求。相比微观优化，我觉得这类数据获取策略的调整，通常更能直接改善真实体验。
当然，性能优化也不能只看数字不看业务。有些优化手段会增加代码复杂度，如果一个页面本来访问量不大、数据量也小，就没必要为了理论上的最佳实践把实现搞得很重。我现在越来越接受一个原则：性能优化是为体验服务的，而不是为了把项目改造成“技术演示场”。
所以如果让我总结自己的性能优化方法，我会说先定位，再分层，再选择最值的方案。前端性能不是靠一个神奇技巧解决的，它更像一个持续的观察和权衡过程。真正成熟的优化，应该让页面更快，同时也尽量不牺牲代码可读性和维护成本。这种平衡感，可能比单纯知道很多技巧更重要。