📐 Layout Thrashing——一个 `offsetHeight` 让你的页面卡成 PPT

性能优化冷门知识点 | 明明没写复杂动画，页面滚动和交互却卡成 PPT？凶手可能就是你随手读的一个布局属性

---

🚨 问题场景

某天用户反馈：后台管理系统在批量选中表格行时，浏览器会卡顿 2-3 秒，Chrome 的帧率从 60fps 掉到个位数。

你检查代码，发现没有复杂计算，没有重渲染，唯一的操作只是循环给选中的行设置 background-color：

const rows = document.querySelectorAll('.data-table tbody tr')
rows.forEach((row, i) => {
  if (selectedIds.includes(row.dataset.id)) {
    row.style.backgroundColor = '#e3f2fd'
  }
})

就改个颜色而已，至于卡成这样吗？至于。而且元凶比你想的隐蔽得多。

---

🔍 原因分析：浏览器渲染流水线

浏览器渲染一帧的流程大致是：

JavaScript → Style → Layout → Paint → Composite

这其中 Layout（布局/回流）是最昂贵的操作之一------浏览器需要重新计算所有元素的位置和尺寸。

什么是 Layout Thrashing？

Layout Thrashing（布局抖动）指的是：在一个连续的 JS 循环中，交替读写布局属性，导致浏览器反复触发强制同步布局（Forced Synchronous Layout）。

看个经典反面教材：

// ❌ 交替读写 → 每一次循环都触发强制布局
const boxes = document.querySelectorAll('.box')
for (let i = 0; i < boxes.length; i++) {
  const width = boxes[i].offsetWidth  // ← 读取布局属性
  boxes[i].style.width = width * 1.5 + 'px'  // ← 写入样式
  // 下一轮循环：读取 offsetWidth 时，浏览器必须先强制布局
}

执行顺序的猫腻：

1. 读取 offsetWidth → 浏览器检查有无待定的样式变更？没有 → 返回当前值（很快）
2. 写入 style.width → 标记为"待布局"（标记阶段，很快）
3. 下一轮循环 读取 offsetWidth → 浏览器发现有待定的样式变更！→ 强制执行同步布局（昂贵！）
4. 写入 style.width → 标记...（重复）

1000 个元素循环 = 1000 次强制布局。如果每个元素内部的子元素也多，布局计算量呈指数级上升。

哪些属性会触发布局？

读取以下属性/方法会强制同步布局（浏览器必须计算精确值才能返回）：

类别	属性/方法
尺寸	offsetWidth offsetHeight clientWidth clientHeight scrollWidth scrollHeight
位置	offsetTop offsetLeft getBoundingClientRect()
滚动	scrollTop scrollLeft scrollIntoView()
计算样式	window.getComputedStyle()（某些属性）
字体	document.fonts.ready

写入以下属性会引起布局失效（标记待布局）：

width height margin padding border top left font-size display position------几乎任何几何相关的 CSS 属性。

---

💊 治疗方案

方案 1：批量读写分离（最常用）

先统一读取 所有需要的数据，再统一写入：

// ✅ 批量读取 → 批量写入 → 只触发布局 2 次（读1次+写1次）
const boxes = document.querySelectorAll('.box')
const widths = []

// 阶段 1：统一读取
for (let i = 0; i < boxes.length; i++) {
  widths.push(boxes[i].offsetWidth)  // ← 首次读取，无待定修改，不强制布局
}

// 阶段 2：统一写入
for (let i = 0; i < boxes.length; i++) {
  boxes[i].style.width = widths[i] * 1.5 + 'px'
  // ← 浏览器在写入这一批后，只做一次布局清算
}

从 1000 次强制布局 → 最多 2 次（读取时的初始布局 + 写入后的批量布局）。

方案 2：使用 requestAnimationFrame 做写操作批处理

如果读和写不能完全分开（比如在滚动事件中动态调整元素），用 rAF 来批处理写入：

let needsUpdate = false

function onScroll() {
  if (!needsUpdate) {
    needsUpdate = true
    requestAnimationFrame(() => {
      // 所有写操作集中在这里
      updateElementPositions()
      needsUpdate = false
    })
  }
  // 读操作可以在这里做，但尽量简单
  const scrollY = window.scrollY
  // ...
}

方案 3：用 content-visibility 跳过不可见元素

对于长列表或表格，让浏览器跳过视口外的布局计算：

/* ✅ 视口外的元素延迟布局，减少强制布局的成本 */
.data-table tr {
  content-visibility: auto;
  contain-intrinsic-size: 48px; /* 给一个占位高度防止滚动条跳动 */
}

这相当于懒加载布局------只有滚动到视口附近的元素才会参与完整布局。

方案 4：直接用 CSS 完成，不走 JS

回到最开始的表格高亮案例：用 CSS class 代替 JS 直接改 style。

// ❌ 直接操作 style → 每一次都触发强制布局
row.style.backgroundColor = '#e3f2fd'

// ✅ 切换 class → 浏览器在下一帧统一处理
row.classList.toggle('selected', selectedIds.includes(row.dataset.id))

.data-table tr.selected {
  background-color: #e3f2fd;
  transition: background-color 0.15s ease;
}

这样不但避免了 Layout Thrashing，还顺带白嫖了 transition 动画。

---

🛠 调试工具：Performance 面板

想知道自己有没有写出 Layout Thrashing？打开 Chrome DevTools → Performance 面板 → 录制交互 → 查看 Layout 和 Recalculate Style 条：

• 🟢 绿色条又宽又密集 → 频繁布局计算
• ⚠️ 悬停条能看到 "Layout Forced" 标记 → 这就是强制同步布局
• 🔴 帧率降到 30fps 以下 → 你需要优化了

也可以搜索 "Forced reflow" 或 "forced layout" 来定位具体代码位置。

---

📝 要点总结

要点	说明
核心原则	绝不在一个循环中交替读写布局属性
批量读写	先统一读出所有值，再统一写入样式
rAF 批处理	滚动事件等高频场景，用 requestAnimationFrame 合并写入
CSS 优先	能用 classList + CSS 解决的，绝不用 JS 直接改 style
content-visibility	长列表开启 content-visibility: auto 懒加载布局
Performance 面板	用 DevTools 查找 "Layout Forced" 定位问题代码

Layout Thrashing 是前端性能优化中最容易被忽略的"隐形杀手"------它不会报错，不会抛异常，只会让你的页面"莫名地卡"。下次写循环时多问自己一句："我是不是在交替读写？"