JavaScript性能优化

在社区里经常能看到类似的困惑：明明照着“性能优化清单”把能用上的技巧都用了，页面却还是卡顿；而有的网站看起来什么都没做，滚动起来却丝般顺滑。说白了，JavaScript性能优化这件事，方向往往比努力更重要。

市面上流传着太多“唯技巧论”的优化教程，它们热衷于比较`for`循环和`forEach`谁更快、`let`和`var`谁更省内存。这些知识本身没有错，但如果你把大量时间花费在“微优化”上，可能是在浪费生命。真正的性能瓶颈，通常根本不在这里。

真相一：脱离上下文的优化，都是伪优化

在讨论“怎么优化”之前，必须先搞清楚“为什么要优化”。多数现代前端应用的性能瓶颈都指向一个共同根源——DOM操作导致的强制回流与重绘。修修补补语法层面的问题，对体验的提升几乎微乎其微。

举个例子，一个常见的列表排序功能，很多同学的第一个念头是：“数据量大，排序算法要不要换成快排？”其实在数百万级数据下，哪怕是一个冒泡排序的排序过程也只需要几百毫秒，而真正让你页面卡住的那一瞬间，是排序完成后的DOM重新渲染。

// 伪优化：纠结于排序算法本身
const sorted = array.sort((a, b) => a - b); // 快排？

// 真正的优化：限制单次渲染的DOM操作量，或者利用Fragment减少回流

对于任何交互，拿不准的时候直接用`requestAnimationFrame`把复杂更新的渲染时机交给浏览器调度器，往往比折腾底层实现有用得多。

真相二：现代框架拼的不是运行时，是心智模型

React、Vue 这类框架让开发者很少直接操作DOM，但这并不表示性能优化就变得不必要了，只是矛盾发生了转移。现在，最影响体验的是无效渲染。

在函数式组件的模式下，只要父组件状态一变，默认所有子组件都跟着“重跑”一遍，哪怕它们的props完全没变。这个看似无害的默认行为，在复杂页面上会被无限放大，表现为点击按钮后，整个页面的所有组件都在执行计算和协调。

聪明的做法是反向思考：

function ListItem({ item, onSelect }) {
  // 传统的memo包装，但其真实收益往往被高估
  return <div onClick={() => onSelect(item.id)}>{item.content}</div>;
}

// 真正高效的是上面的状态设计：
function App() {
  const [selectedId, setSelectedId] = useState(null);
  return (
    <>
      {/* 只有items变了，这里才需要重新渲染 */}
      {items.map(item => <ListItem key={item.id} ... />)}
      {/* 但selectedId的变化，并不影响item的显示内容 */}
    </>
  );
}

与其反复包`memo`或者微调`shouldComponentUpdate`的比对策略，不如从设计上把“会变化的数据”和“不常变化的数据”进行隔离。数据越稳定，前端运行越轻松，这是一条颠扑不破的真理。

真相三：对“运行时”精打细算，不如对“编译时”下功夫

现在前端工程化已经全面拥抱构建工具。网页首屏加载的性能，很大程度上取决于你在`webpack`或`vite`的配置文件里做了什么。

很多开发者抱怨JS文件太大，其实未必是代码写得多，而是根本没有意识去裁剪掉那些自带的重型依赖。比如为了一个防抖函数引入Lodash，为了格式化日期引入Moment.js，最终的代价是浏览器需要解析上百万行代码。

现代的解决方案往往更优雅：

- 使用现代前端框架的server components能力，把耗逻辑放到后端，给前端瘦身。
- 利用Tree Shaking，在构建时，把没有用到的代码分支在“源头”剔除掉。
- 平时多养成“按需引用”的习惯，而非“全量引入`import * as`”。

性能优化在编译期做，事半功倍；在浏览器运行时强行补救，事倍功半。

给进阶者的两个冷门建议

如果前面这些你都做到了，那么可以看看下面这两个在社区讨论不多、但很关键的细节：

第一，注意“隐藏类”与“内联缓存”。 JS引擎（如V8）会为对象创建“隐藏类”以查找属性。如果你在某函数内部极速地给对象新增/删除属性（动态改变对象形态），引擎基于之前形态建立的优化机制会全部失效，从而降级到字典查找模式。在写代码时尽量保持对象结构的稳定性，会比追求所谓“极客式”的骚操作拥有更安全的性能边际。

第二，重视“长任务”带来的卡顿。 现在的页面不再只是单纯的文档，而是“应用”。优先考虑把Canvas、Web Worker从“锦上添花”变成“必选项”，特别是处理移动端手势、图像滤镜或后台同步数据时。把超长循环或重计算塞进独立线程，才能保证主线程的流畅，不干扰用户交互。

理性看待优化

比较遗憾的一点是，越有经验的开发者，越倾向于把优化理解为一个“设计权衡”的问题，而不是干巴巴地摆放几个工具函数就能解决的排行榜。

与其盲目追求“代码跑得有多快”，更应该关心“感知性能有多高”。用户不会在意Click事件处理是1毫秒还是0.1毫秒，他只会在意点击后1秒内是否有反馈。把精力花在加载进度条、骨架屏、交互状态的及时反馈上，这远比减少几KB包体更能提升产品口碑。

最后想说的是，任何脱离业务场景的性能评估都是耍流氓。在做一个技术方案前，不妨先问自己：“这里真的优化到点子上了吗？”