核心是定位paint阶段在主线程的实际开销并关联视觉变化，需开启screenshots和memory、设cpu为4x slowdown，分析paint与composite layers耗时，结合rendering面板的paint rectangles和forced synchronous layout警告排查重绘根源。
要分析页面绘制过程耗时，核心是定位「Paint」阶段在主线程上的实际开销，并关联视觉变化。Chrome DevTools 的 Performance 面板提供了从帧级到像素级的完整链条，关键不在于只看绿色块，而在于理解它为什么发生、在哪发生、是否必要。
开启带截图的性能录制
绘制分析必须依赖视觉反馈，否则无法判断哪一帧卡顿或重绘异常：
- 用无痕窗口打开页面，禁用所有扩展，避免干扰
- Performance 面板右上角⚙️ → 勾选 Screenshots（必选）和 Memory（辅助判断内存压力是否诱发绘制延迟）
- CPU Throttling 设为 4x slowdown，模拟中低端设备真实表现
- 点击 Record 按钮后，执行目标操作（如滚动、悬停、动画播放），2–5 秒内停止
聚焦 Paint 和 Composite Layers 轨道
绘制耗时分散在两个关键环节：CPU 绘制（Paint）和 GPU 合成（Composite Layers），两者缺一不可：
- 在火焰图下方轨道中，找到标为 Paint（绿色）和 Composite Layers（浅绿/灰白）的条目
- 单击任一 Paint 条目，在 Summary 面板查看「Duration」和「Layer」信息——若某次 Paint 耗时 >16ms 或反复出现，说明绘制过重
- 双击 Composite Layers 条目，可跳转至 Layers 面板，观察图层数量、大小及是否频繁重组（如「Layer Recomposite」提示）
启用绘制高亮定位重绘区域
光看时间数字不够直观，需确认绘制是否发生在预期位置：
- 按 Cmd+Shift+P（Mac）或 Ctrl+Shift+P（Win），输入「Rendering」→ 选择「Show paint rectangles」
- 页面上会实时显示黄色边框，标出每次重绘的区域；滚动时全屏闪烁，说明未优化滚动重绘
- 配合「Continuous painting mode」（同路径启用），可量化每个元素的绘制频率与耗时，识别高开销 DOM 节点
结合强制布局警告排查根源
很多“绘制慢”其实源于上游阻塞——比如样式计算或布局被 JavaScript 强制打断：
- 在火焰图中查找 Forced Synchronous Layout 提示（常伴随紫色 Layout 块）
- 典型代码模式：
el.offsetHeight+el.style.left = ...，浏览器被迫同步回流再重绘 - 这类操作会让后续 Paint 推迟，且无法被合并；修复方式是批量读取尺寸、延迟写入样式，或改用 transform/opacity 等合成属性
