浏览器渲染HTML需经解析、构建、布局、绘制流水线；HTML解析阻塞于同步脚本，CSSOM与DOM合成渲染树，重排重绘影响性能，DevTools可定位瓶颈。
浏览器渲染 HTML 页面不是“拿到就画”，而是经历一整套解析、构建、布局、绘制的流水线。跳过原理直接优化，容易改了这儿崩了那儿。
HTML 解析阶段：DOM 树怎么生成的
浏览器从上到下逐字节读取 HTML 字符流，遇到标签就创建对应 Element 节点，文本内容变成 Text 节点，注释被忽略。关键点在于：解析是阻塞的， 标签（无 async 或 defer）会立即暂停 HTML 解析、执行 JS、再继续。
- 避免在
里放同步脚本，尤其是第三方 SDK；改用defer或移到前 -
会阻塞后续 JS 执行（但不阻塞 HTML 解析），CSS 加载慢会导致白屏延长 - 服务端返回带大量内联
或的 HTML，会拖慢首次字节（TTFB）后的解析速度
CSSOM 构建与渲染树合成
CSS 规则被解析成 CSSOM（CSS Object Model），它和 DOM 合成渲染树（Render Tree）——只包含需要显示的节点（display: none 的元素进不去，但 visibility: hidden 的会进）。
-
@import在 CSS 文件中等价于同步加载，会引发额外网络往返，优先用并行加载 - 过度使用通配选择器（如
* { margin: 0 }）或深层嵌套（div div div p span）会显著拖慢 CSSOM 构建和匹配速度 - 媒体查询（
@media (min-width: 768px)）未命中时，对应规则仍会被解析并存入 CSSOM，只是不参与当前渲染树计算
重排（Reflow）和重绘（Repaint）哪里最伤性能
修改影响几何属性（如 width、top、offsetHeight）触发重排；修改不影响布局但影响外观（如 color、background-color）只触发重绘。重排必然导致重绘，但反之不成立。
立即学习“前端免费学习笔记（深入）”；
- 避免在循环中反复读写布局属性：
for (...) { el.offsetWidth; el.style.left = x++ + 'px'; }—— 每次offsetWidth都可能强制同步重排 - 用
transform和opacity替代left/top/width动画，它们走合成层（Compositor Thread），不触发布局计算 -
documentFragment批量插入节点，比逐个appendChild减少重排次数
如何用 DevTools 快速定位渲染瓶颈
Chrome DevTools 的 Rendering 面板（需在 Settings → Preferences → Advanced → Enable paint flashing）能高亮重绘区域；Performance 面板录制后可查看 Layout 和 Paint 阶段耗时。
- 录制时勾选
Enable advanced paint instrumentation，可看到具体哪些层在 Paint - 关注
Layout事件的 “Duration” 列，超过 16ms（即掉帧）说明重排太重 - 用
console.time('layout')+el.offsetLeft这类强制布局操作，粗略验证某段逻辑是否引发意外重排
function forceLayout() {
document.body.offsetHeight; // 强制触发一次同步重排
}
// 不要这么写：
for (let i = 0; i < 100; i++) {
el.style.left = i + 'px';
console.log(el.offsetTop); // 每次都重排
}真正卡顿往往不在首屏 HTML 渲染，而在 JS 动态操作 DOM + 频繁读写布局属性 + 未合理分片的长任务。把“渲染”当成一个有明确阶段、可测量、可拆解的工程问题，而不是玄学优化。
