简版速记

面试速记用，核心结论一览。

  • 渲染五步（关键路径）：解析 HTML 建 DOM 树 → 解析 CSS 建 CSSOM 树 → DOM + CSSOM 合并为渲染树（Render Tree）→ 布局/回流（Layout/Reflow，算位置与尺寸）→ 绘制 + 合成图层（Paint + Composite，GPU 上屏）。后两步最耗时，俗称「渲染」。
  • 阻塞关系：
    • CSSOM 构建会阻塞渲染（渲染树需要 CSSOM）。
    • <script> 默认阻塞 DOM 解析（停止解析 → 下载 → 执行 JS → 恢复解析）。
    • JS 执行前要等前面的 CSS 解析完成 → CSS 也会间接阻塞 JS，从而间接阻塞 DOM 解析。
  • 脚本加载：<script> 放页面底部；defer（DOM 构建完成后、按顺序、DOMContentLoaded 前执行）、async（下载完立即执行、不保证顺序、不阻塞解析）优化外部脚本。
  • 两个事件：DOMContentLoaded（HTML 解析完成即触发，不等 CSS/JS/图片）vs load（DOM/CSS/JS/图片全部加载完才触发）。
  • 回流 vs 重绘：
    • 回流（Reflow/重排）= 几何属性（位置、尺寸）变化，需重新布局。
    • 重绘（Repaint）= 仅外观变化（如 color），不影响布局。
    • 回流必然触发重绘；重绘不一定触发回流。回流成本远高于重绘。
  • 减少回流/重绘的常见手段：用 transform/translate 替代 top/left；用 visibility 替代 display:none；DOM 离线批量修改；避免循环中读取 offsetTop/offsetWidth 等触发强制同步布局的属性；避免 table 布局；动画用 requestAnimationFrame；频繁动画提升为独立图层（合成层）。
  • 图层（合成层）：translate3d/translateZ、will-change、opacity 动画、position:fixed、video/iframe 等会生成新图层；新图层重绘互不影响，但层过多会反噬内存。
  • 回流与 Event Loop 的关系：每帧（约 16ms，60Hz）在 Microtasks 之后判断是否需更新；resize/scroll 至少 16ms 触发一次（自带节流）；一帧内依次处理 media query、动画、requestAnimationFrame 回调、IntersectionObserver 回调、界面更新；有空闲再跑 requestIdleCallback。

一、浏览器如何渲染网页

概述：浏览器渲染一共有五步

  1. 处理 HTML 并构建 DOM 树。
  2. 处理 CSS构建 CSSOM 树。
  3. 将 DOM 与 CSSOM 合并成一个渲染树。
  4. 根据渲染树来布局，计算每个节点的位置。
  5. 调用 GPU 绘制，合成图层，显示在屏幕上

第四步和第五步是最耗时的部分，这两步合起来，就是我们通常所说的渲染

具体如下图过程如下图所示

img

img

渲染

  • 网页生成的时候，至少会渲染一次
  • 在用户访问的过程中，还会不断重新渲染

重新渲染需要重复之前的第四步(重新生成布局)+第五步(重新绘制)或者只有第五个步(重新绘制)

  • 在构建 CSSOM 树时，会阻塞渲染，直至 CSSOM树构建完成。并且构建 CSSOM 树是一个十分消耗性能的过程，所以应该尽量保证层级扁平，减少过度层叠，越是具体的 CSS 选择器，执行速度越慢
  • 当 HTML 解析到 script 标签时，会暂停构建 DOM，完成后才会从暂停的地方重新开始。也就是说，如果你想首屏渲染的越快，就越不应该在首屏就加载 JS 文件。并且CSS也会影响 JS 的执行，只有当解析完样式表才会执行 JS，所以也可以认为这种情况下，CSS 也会暂停构建 DOM

二、浏览器渲染五个阶段

浏览器关键渲染路径：HTML 解析为 DOM 树、CSS 解析为 CSSOM 树，二者合并为渲染树，再经 Layout、Paint、Composite 上屏；标注 JS 阻塞解析、CSS 阻塞渲染

2.1 第一步：解析HTML标签，构建DOM树

在这个阶段，引擎开始解析html，解析出来的结果会成为一棵dom树 dom的目的至少有2个

  • 作为下个阶段渲染树状图的输入
  • 成为网页和脚本的交互界面。(最常用的就是getElementById等等)

当解析器到达script标签的时候，发生下面四件事情

  1. html解析器停止解析,
  2. 如果是外部脚本，就从外部网络获取脚本代码
  3. 将控制权交给js引擎，执行js代码
  4. 恢复html解析器的控制权

由此可以得到第一个结论1

  • 由于<script>标签是阻塞解析的，将脚本放在网页尾部会加速代码渲染。
  • defer和async属性也能有助于加载外部脚本。
  • defer使得脚本会在dom完整构建之后执行；
  • async标签使得脚本只有在完全available才执行，并且是以非阻塞的方式进行的

补充(现代做法)：defer 与 async 都只对外部脚本（带 src）生效，对内联脚本无效。两者都在下载阶段不阻塞 HTML 解析，区别在于执行时机：

  • defer：下载与解析并行，等到 DOM 解析完成后、DOMContentLoaded 触发前执行，且多个 defer 脚本按文档顺序执行。适合有依赖关系、需要操作完整 DOM 的脚本。
  • async：下载与解析并行，下载完成后立即执行（可能打断解析），执行顺序不保证、谁先下载完谁先跑。适合独立的第三方脚本（如统计、广告）。
  • ES Modules（<script type="module">）默认就具备 defer 行为；可叠加 async 改为下载即执行。
  • 现代浏览器还会做「预加载扫描」（preload scanner），即使主解析被脚本阻塞，也会提前并行下载后续资源；配合 <link rel="preload"> / rel="modulepreload"> 可进一步提示关键资源优先级。

2.2 第二步：解析CSS标签，构建CSSOM树

  • 我们已经看到html解析器碰到脚本后会做的事情，接下来我们看下html解析器碰到样式表会发生的情况
  • js会阻塞解析，因为它会修改文档(document)。css不会修改文档的结构，如果这样的话，似乎看起来css样式不会阻塞浏览器html解析。但是事实上 css样式表是阻塞的。阻塞是指当cssom树建立好之后才会进行下一步的解析渲染

通过以下手段可以减轻cssom带来的影响

  • 将script脚本放在页面底部
  • 尽可能快的加载css样式表
  • 将样式表按照media type和media query区分，这样有助于我们将css资源标记成非阻塞渲染的资源。
  • 非阻塞的资源还是会被浏览器下载，只是优先级较低

补充(现代做法)：严格来说 CSS 不阻塞 DOM 树的「构建」，但它阻塞渲染（渲染树需要 CSSOM）；同时由于 JS 可能读取样式，CSS 也会阻塞其后的 <script> 执行，从而间接阻塞解析。

  • 用 media 属性拆分非关键 CSS：<link rel="stylesheet" href="print.css" media="print"> 不阻塞首屏渲染。
  • 关键 CSS 内联（Critical CSS），非关键 CSS 异步加载：<link rel="preload" href="x.css" as="style" onload="this.rel='stylesheet'">。
  • 现代构建工具（Vite/webpack）支持 CSS 代码分割，按路由/组件加载，减小首屏阻塞 CSS 体积。

2.3 第三步：把DOM和CSSOM组合成渲染树（render tree）

img

2.4 第四步：在渲染树的基础上进行布局，计算每个节点的几何结构

布局(layout)：定位坐标和大小，是否换行，各种position, overflow, z-index属性

2.5 调用 GPU 绘制，合成图层，显示在屏幕上

将渲染树的各个节点绘制到屏幕上，这一步被称为绘制painting

补充(现代做法)：现代浏览器（Chrome Blink）的绘制后还有**合成（Composite）**阶段：页面被切分为多个图层（layer），分别栅格化（raster）成位图，再由合成线程（compositor thread）在 GPU 上拼合上屏。

  • 仅触发合成的属性（transform、opacity）可跳过 Layout 和 Paint，直接由合成线程在 GPU 上处理，因此动画最流畅，且不阻塞主线程。
  • 这就是「用 transform: translate() 替代 top/left 做动画」性能更好的底层原因。

三、渲染优化相关

一帧（约 16ms）内的渲染时间线：Run JS/Microtasks → requestAnimationFrame → Style 计算 → Layout(回流) → Paint(重绘) → Composite → Display；回流必触发重绘，重绘不必触发回流

3.1 Load 和 DOMContentLoaded 区别

  • Load 事件触发代表页面中的 DOM，CSS，JS，图片已经全部加载完毕。
  • DOMContentLoaded 事件触发代表初始的 HTML 被完全加载和解析，不需要等待 CSS，JS，图片加载

3.2 图层

一般来说，可以把普通文档流看成一个图层。特定的属性可以生成一个新的图层。不同的图层渲染互不影响，所以对于某些频繁需要渲染的建议单独生成一个新图层，提高性能。但也不能生成过多的图层，会引起反作用。

通过以下几个常用属性可以生成新图层

  • 3D 变换：translate3d、translateZ
  • will-change
  • video、iframe 标签
  • 通过动画实现的 opacity 动画转换
  • position: fixed

补充(现代做法)：图层（合成层）虽然能隔离重绘、加速动画，但每个合成层都占用 GPU 内存（栅格化后的位图），过多图层会导致「层爆炸」拖慢合成与内存。

  • will-change 应在动画开始前临时添加、结束后移除，避免常驻造成内存浪费。
  • 可在 Chrome DevTools 的 Layers 面板查看页面实际的合成层及其生成原因，用 Rendering → Layer borders 直观调试。

3.3 重绘（Repaint）和回流（Reflow）

重绘和回流是渲染步骤中的一小节，但是这两个步骤对于性能影响很大

  • 重绘是当节点需要更改外观而不会影响布局的，比如改变 color 就叫称为重绘
  • 回流是布局或者几何属性需要改变就称为回流。

回流必定会发生重绘，重绘不一定会引发回流。回流所需的成本比重绘高的多，改变深层次的节点很可能导致父节点的一系列回流

以下几个动作可能会导致性能问题

  • 改变 window 大小
  • 改变字体
  • 添加或删除样式
  • 文字改变
  • 定位或者浮动
  • 盒模型

很多人不知道的是，重绘和回流其实和 Event loop 有关

  • 当 Event loop 执行完Microtasks 后，会判断 document 是否需要更新。因为浏览器是 60Hz 的刷新率，每 16ms 才会更新一次。
  • 然后判断是否有 resize 或者 scroll ，有的话会去触发事件，所以 resize 和 scroll 事件也是至少 16ms才会触发一次，并且自带节流功能。
  • 判断是否触发了 media query
  • 更新动画并且发送事件
  • 判断是否有全屏操作事件
  • 执行 requestAnimationFrame 回调
  • 执行 IntersectionObserver 回调，该方法用于判断元素是否可见，可以用于懒加载上，但是兼容性不好
  • 更新界面
  • 以上就是一帧中可能会做的事情。如果在一帧中有空闲时间，就会去执行 requestIdleCallback 回调

补充(现代做法)：IntersectionObserver 如今兼容性已经很好（所有现代浏览器及 Safari 12.1+ 均支持），是懒加载图片、无限滚动、曝光埋点的首选方案，性能远优于监听 scroll 事件逐帧计算位置。原文「兼容性不好」的说法已过时。

常见的引起重绘的属性

  • color
  • border-style
  • visibility
  • background
  • text-decoration
  • background-image
  • background-position
  • background-repeat
  • outline-color
  • outline
  • outline-style
  • border-radius
  • outline-width
  • box-shadow
  • background-size

3.4 常见引起回流属性和方法

任何会改变元素几何信息(元素的位置和尺寸大小)的操作，都会触发重排，下面列一些栗子

  • 添加或者删除可见的DOM元素；
  • 元素尺寸改变——边距、填充、边框、宽度和高度
  • 内容变化，比如用户在input框中输入文字
  • 浏览器窗口尺寸改变——resize事件发生时
  • 计算 offsetWidth 和 offsetHeight 属性
  • 设置 style 属性的值

回流影响的范围

由于浏览器渲染界面是基于流式布局模型的，所以触发重排时会对周围DOM重新排列，影响的范围有两种

  • 全局范围：从根节点html开始对整个渲染树进行重新布局。
  • 局部范围：对渲染树的某部分或某一个渲染对象进行重新布局

全局范围回流

    <body>
      <div class="hello">
        <h4>hello</h4>
        <p><strong>Name:</strong>BDing</p>
        <h5>male</h5>
        <ol>
          <li>coding</li>
          <li>loving</li>
        </ol>
      </div>
    </body>

当p节点上发生reflow时，hello和body也会重新渲染，甚至h5和ol都会收到影响

局部范围回流

用局部布局来解释这种现象：把一个dom的宽高之类的几何信息定死，然后在dom内部触发重排，就只会重新渲染该dom内部的元素，而不会影响到外界

补充(现代做法)：CSS 的 contain 属性（contain: layout / contain: strict / contain: content）以及 content-visibility: auto 可以显式告诉浏览器某子树的布局/绘制与外界隔离，从而把回流限制在局部，是现代「局部范围回流」的标准做法，对长列表、卡片流首屏性能提升明显。

3.5 减少重绘和回流

使用 translate 替代 top

    <div class="test"></div>
    <style>
        .test {
            position: absolute;
            top: 10px;
            width: 100px;
            height: 100px;
            background: red;
        }
    </style>
    <script>
        setTimeout(() => {
            // 引起回流
            document.querySelector('.test').style.top = '100px'
        }, 1000)
    </script>
  • 使用 visibility 替换 display: none ，因为前者只会引起重绘，后者会引发回流（改变了布局）
  • 把 DOM 离线后修改，比如：先把 DOM 给 display:none (有一次 Reflow)，然后你修改100次，然后再把它显示出来
  • 不要把 DOM 结点的属性值放在一个循环里当成循环里的变量
    for(let i = 0; i < 1000; i++) {
        // 获取 offsetTop 会导致回流，因为需要去获取正确的值
        console.log(document.querySelector('.test').style.offsetTop)
    }
  • 不要使用 table 布局，可能很小的一个小改动会造成整个 table 的重新布局
  • 动画实现的速度的选择，动画速度越快，回流次数越多，也可以选择使用 requestAnimationFrame
  • CSS选择符从右往左匹配查找，避免 DOM深度过深
  • 将频繁运行的动画变为图层，图层能够阻止该节点回流影响别的元素。比如对于 video标签，浏览器会自动将该节点变为图层。

补充(现代做法)：上面循环读取 offsetTop 的例子本质是「强制同步布局 / 布局抖动（Layout Thrashing）」——在同一帧里交替「读」几何属性和「写」样式，会迫使浏览器反复同步计算布局。

  • 正确做法：先批量读，再批量写（读写分离），或用 requestAnimationFrame 把写操作推迟到下一帧。
  • 构造 DOM 时用 DocumentFragment 一次性插入，避免逐个插入触发多次回流。
  • 测量与读取布局可借助 IntersectionObserver / ResizeObserver 异步获取，避免主动调用 getBoundingClientRect() 触发强制回流。

img

img

阅读全文

Last Updated:
Contributors: leeguooooo