优化JS性能，减少重绘重排教程

“纵有疾风来，人生不言弃”，这句话送给正在学习文章的朋友们，也希望在阅读本文《减少重绘重排，优化JS性能教程》后，能够真的帮助到大家。我也会在后续的文章中，陆续更新文章相关的技术文章，有好的建议欢迎大家在评论留言，非常感谢！

重排比重绘更昂贵，因重排需重新计算几何属性并影响渲染树；重绘仅更新像素颜色等不改变布局的样式；强制同步布局和频繁DOM操作是主要性能瓶颈。

重排（reflow）和重绘（repaint）到底谁更贵

重排一定触发重绘，但重绘不一定触发重排。真正吃性能的是重排——它需要重新计算元素的几何属性（位置、尺寸），并影响整个渲染树中相关节点。比如修改 offsetTop、clientWidth，或任何会读取布局信息的操作，都可能强制浏览器立即执行一次重排。

• 常见触发重排的操作：offsetLeft、getComputedStyle()（读取某些属性时）、scrollTo()、改变 className 或内联 style 中影响盒模型的属性（如 width、padding、display）
• 只触发重绘的操作：修改 color、background-color、visibility（注意不是 display: none）等不改变几何信息的样式
• 现代浏览器会批量处理样式修改，但一旦你读取布局信息（如 offsetHeight），就会打破队列，强制同步重排

批量读写分离：避免 forced synchronous layout

所谓“强制同步布局”，就是你在 JS 中一边改样式一边立刻读取尺寸，导致浏览器不得不中断当前渲染流程，立刻计算并返回结果。这是最常被忽视的性能杀手。

• ❌ 错误写法：

  element.style.height = '200px';
  console.log(element.offsetHeight); // 强制重排

• ✅ 正确做法：先批量读、再批量写，或用 getBoundingClientRect() 替代多次读取
• 更稳妥的方式是把读操作全部前置，写操作全部后置；或者使用 requestAnimationFrame() 把写操作推迟到下帧开始前

用 transform 和 opacity 做动画替代 top/left/width

只要元素开启了硬件加速（例如有 transform: translateZ(0) 或 will-change: transform），浏览器会把它提升为独立图层，后续对 transform 和 opacity 的修改就只触发合成（composite），完全跳过重排和重绘。

• ❌ 避免：top、left、width、height 动画（每次修改都重排）
• ✅ 推荐：transform: translateX(100px)、transform: scale(1.2)、opacity: 0.5
• will-change 不要滥用：只在动画开始前设置，动画结束及时清除，否则长期占用 GPU 内存

DOM 操作尽量少而集中

频繁增删、移动 DOM 节点会反复触发重排。哪怕只是往 document.body 追加 10 个 div，逐个 appendChild() 也会造成 10 次潜在重排。

• 用 DocumentFragment 批量插入：

  const frag = document.createDocumentFragment();
  for (let i = 0; i 

• 隐藏元素再操作：el.style.display = 'none' → 修改 → el.style.display = ''，适用于复杂子树更新
• 避免在循环中访问 innerHTML 或 innerText，它们会触发解析和重排

实际项目里最容易被忽略的，是那些“看起来无害”的布局读取——比如在 resize 或 scroll 回调里反复调用 getBoundingClientRect()，又没做节流。这类问题不会报错，但会让滚动卡顿得非常明显。

理论要掌握，实操不能落！以上关于《优化JS性能，减少重绘重排教程》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！