第一章：性能瓶颈分析——用Chrome DevTools定位帧率瓶颈

做虚拟仪表盘，最怕什么？

画面卡顿。指针跳动不流畅。数字刷新像PPT翻页。

我刚开始做这类项目时，也踩过这个坑。明明代码逻辑没问题，硬件配置也不差，但帧率就是上不去。后来我才明白——问题往往出在浏览器的渲染流水线上。

1.1 渲染流水线：你得知道浏览器在忙什么

先简单过一遍流程。浏览器渲染一帧，大致要经过这几个阶段：

1. JavaScript：执行你的脚本，比如更新仪表数据
2. Style：计算样式，看哪些元素变了
3. Layout：计算布局，也就是重排（Reflow）
4. Paint：绘制像素，也就是重绘（Repaint）
5. Composite：合成图层，输出到屏幕

这里面，Layout和Paint是最耗时的两个阶段。说白了，重排的代价远大于重绘。为什么？重排要重新计算所有元素的位置和尺寸，而重绘只是重新画一下外观。

1.2 用Performance面板抓“罪魁祸首”

光说不练假把式。咱们直接打开Chrome DevTools的Performance面板，录一段看看。

操作步骤很简单：

1. 按F12打开DevTools，切换到Performance标签
2. 点击左上角的录制按钮（圆点）
3. 在页面上操作你的仪表盘（比如拖动指针）
4. 点击停止，等待分析结果

录完之后，你会看到一条时间轴。重点关注这几个地方：

• FPS图表：绿色条越高越好。如果出现红色条，说明那一帧掉到30fps以下了
• Main线程：这里能看到每个任务的耗时。黄色是JavaScript，紫色是Layout，绿色是Paint
• Summary面板：底部会汇总各类操作的耗时占比

1.3 识别重排与重绘：看颜色就知道

在Performance的Main线程里，每个任务块都有颜色标识：

颜色	阶段	含义
紫色	Layout（重排）	浏览器在重新计算元素位置和尺寸
绿色	Paint（重绘）	浏览器在绘制像素
黄色	JavaScript	你的脚本在执行
灰色	Composite	合成图层，通常很快

举个例子。我在项目中遇到过这样一个场景：仪表盘上的数字每100ms更新一次，结果Performance里Layout块一个接一个，帧率直接掉到20fps。仔细一看，原来是每次更新数字时，都修改了元素的width属性——这玩意儿会触发重排。

1.4 哪些操作会触发重排？

记住这张清单，写代码时绕着走：

• 修改元素的width、height、padding、margin
• 修改display: none（显示/隐藏）
• 修改position为absolute或fixed
• 修改font-size、font-family
• 读取offsetTop、offsetLeft、scrollTop等属性（强制同步布局）

而只触发重绘的操作，相对“便宜”一些：

• 修改color、background-color
• 修改visibility（隐藏但占位）
• 修改outline、box-shadow

1.5 实战：用代码验证一下

咱们写个简单例子，看看重排和重绘的代价差异。

// 触发重排的写法
function updateWithReflow() {
  const el = document.getElementById('gauge');
  for (let i = 0; i < 100; i++) {
    el.style.width = i + 'px';  // 每次循环都触发重排
  }
}

// 只触发重绘的写法
function updateWithRepaint() {
  const el = document.getElementById('gauge');
  for (let i = 0; i < 100; i++) {
    el.style.backgroundColor = i % 2 === 0 ? 'red' : 'blue';  // 只触发重绘
  }
}

在Performance里分别跑一下这两个函数。你会发现，updateWithReflow的Layout耗时是updateWithRepaint的5到10倍。嗯，这就是重排的代价。

1.6 总结一下

定位性能瓶颈，说白了就是三步：

1. 打开Performance面板，录一段操作
2. 看FPS图表，找到掉帧的位置
3. 看Main线程，识别是Layout还是Paint在拖后腿

你想想看，如果连瓶颈在哪都不知道，优化就无从谈起。所以这一章虽然基础，但真的很重要。下一章咱们聊聊怎么用CSS属性来避免不必要的重排，让仪表盘跑得像丝一样顺滑。