核心是定位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 等合成属性