移动 DOM 节点和浏览器重绘性能答案

【问题标题】：Moving a DOM node and browser repaint performance移动 DOM 节点和浏览器重绘性能
【发布时间】：2013-05-30 09:10:46
【问题描述】：

假设我有一个页面，其中有一堆 div 一个接一个地堆叠。在某一时刻，我将第 30 个节点从其下方位置移动到位置，例如 5。这会导致旧节点 5 到 29 向下移动一个槽。

忽略 div 中的内容，此操作对相对性能的影响有多大？如果我正确理解了重绘的概念，这将导致大量的重绘，因为许多可见项目的位置都发生了变化。但我认为浏览器会使用一些技巧来优化这么简单的东西。

免责声明：我确实尝试在 Chrome 上测试重绘，但我想我的方法不够充分，我无法辨别太多。

这是后续问题： 假设我移动了其中一些 div。在性能方面什么会更好：单独移动每个节点，或者说，只是简单地重新附加每个节点？我的想法是，在某个时候，最好只重新附加整个内容一次，而不是移动 6 或 7 个 div 并每次重新绘制大约一半的屏幕（如果确实如此的话）。

谢谢。

【问题讨论】：

那么这应该在jsperf中测试或使用BenchmarkJS。
不要使用innerHTML作为“重绘”的“优化”——它可能实际上会让浏览器不得不做更多工作并将内容解析为新的 DOM 子树。使用现有节点对 DOM 进行更改，请跳过此步骤。只要 智能地移动 DOM 节点（例如，插入之后而不是一些可怕的 O(n^2) 循环），那么对于大多数情况它应该足够快。除非存在 [可验证的] 性能问题，否则不会出现性能问题。
@user2246674 innerHTML 只是一个例子，因为我想不出一个快速的说法。我会修改我的帖子。
@chenglou 将innerHTML 替换为someCleverHack，我的评论成立。浏览器在 reflowing（定位元素，比如在 DOM 或 CSS 更新之后）和 repainting（将元素渲染到视口）方面非常快。非常复杂的网站“在眨眼之间”呈现；有一些退化的情况（例如使用“自动布局”的深层嵌套表），但不要“过早优化”。
@user2246674 感谢您的回复。我更新了我的问题：忘记innerHTML，只是重新附加所有内容（这不会是黑客，对吧）？

【解决方案1】：

不久前我通读了这篇文章，它教会了我很多东西：

例如：

" 将动画应用于位置固定或绝对的元素。它们不会影响其他元素的布局，因此它们只会导致重绘而不是完全回流。这成本要低得多”

那里还有很多有用的提示。

【讨论】：