浏览器 JS 为什么会阻塞渲染？（面试版）

Wect
0 阅读10分钟

核心定位：前端面试高频基础题，考察对浏览器渲染机制和 JS 执行原理的理解，以下内容结构清晰、重点加粗，可直接背诵，搭配通俗解读帮你快速理解，最后附面试常考题及标准答法。

一、一句话标准答案（面试开篇直接答）

因为 JavaScript 可能修改 DOM（文档结构）和 CSSOM（样式结构），而浏览器渲染页面必须依赖稳定的 DOM 和 CSSOM，所以执行 JS 时，浏览器会暂停 HTML 解析和页面渲染，这就是 JS 阻塞渲染的核心原因。

二、底层原因拆解（通俗+专业，理解后更好背）

先搞懂浏览器渲染的完整流程（记熟这5步，面试多题可复用）：

  1. 解析 HTML 代码 → 构建 DOM 树（页面的结构骨架）；

  2. 解析 CSS 代码 → 构建 CSSOM 树（页面的样式规则）；

  3. DOM 树 + CSSOM 树 → 合并成 Render Tree（渲染树，确定哪些元素要显示、显示成什么样）；

  4. Layout（布局）：计算每个元素的位置和大小；

  5. Paint（绘制）：将渲染树渲染到页面上，呈现最终视觉效果。

关键：JS 能做什么，导致浏览器必须“暂停”？

通俗说：JS 是“破坏王”，能直接改动渲染的“原材料”（DOM 和 CSSOM），比如：

  • 修改 DOM：新增、删除、修改页面元素（如 document.body.innerHTML = "修改内容"）；

  • 修改样式：改变元素的 CSS 样式（如 element.style.color = "red"）；

  • 读取布局信息：触发页面回流（比如 getComputedStyle(element)）。

专业解读：如果浏览器一边解析 HTML 构建 DOM，一边执行 JS 修改 DOM，之前构建的 DOM 结构就会失效，后续渲染也会出错。因此浏览器必须遵循“先执行 JS，再继续解析渲染”的规则，这就是阻塞的本质。

三、script 标签为什么会阻塞？（结合实例，好记）

看一个简单实例，就能理解执行流程：

<body>
  <div>1</div>
  <script>
    console.log(document.querySelector("div")) // 能拿到第一个div
  </script>
  <div>2</div>
</body>

执行流程（记熟，面试可直接说）：

  1. 浏览器解析 HTML，遇到 <div>1</div>，构建 DOM 节点；

  2. 遇到 <script> 标签，立即暂停 HTML 解析（不继续解析后面的 <div>2</div>）；

  3. 执行 script 里的 JS 代码；

  4. JS 执行完毕，才继续解析后面的 HTML，构建 <div>2</div> 的 DOM 节点。

核心原因：JS 可能直接清空 DOM（如 document.body.innerHTML = ""），如果不暂停解析，后面的 HTML 解析和 DOM 构建就会白费功夫，浏览器为了避免资源浪费，必须暂停。

四、JS 为什么会阻塞渲染（而不只是解析）？（面试加分点）

很多人只记“阻塞解析”，却忽略这一点，记住两个核心结论：

  • 浏览器的渲染操作（Layout、Paint）和 JS 执行，共用同一个主线程（Renderer Process 主线程）；

  • 浏览器是“单线程模型”，同一时间只能执行一个任务，不能同时做“渲染”和“JS 执行”。

通俗说：主线程就像一条单车道，JS 执行是一辆大货车，渲染是一辆小汽车，大货车占用车道时，小汽车只能等着，所以 JS 执行时，渲染会被阻塞，页面就会“卡住”。

五、真实例子（加深记忆，面试可举例）

示例：长任务阻塞渲染（最常见场景）

<body>
  <button>Click</button>
  <script>
    const start = Date.now()
    // 模拟一个5秒的长任务（占用主线程）
    while (Date.now() - start < 5000) {}
  </script>
</body>

现象（面试可直接描述）：页面白屏5秒，按钮无法点击，页面完全无响应；

原因：JS 长任务长时间占用主线程，渲染任务无法执行，导致页面卡死。

六、进阶追问：CSS 为什么会影响 JS？（面试高频延伸题）

很多面试官会追问这题，记住核心逻辑：JS 可能需要读取 CSS 样式，而读取样式必须依赖 CSSOM。

<link rel="stylesheet" href="style.css">
<script>
  // JS 读取元素的计算样式，需要 CSSOM 构建完成
  console.log(getComputedStyle(document.body))
&lt;/script&gt;

执行流程：

  1. 浏览器解析到 link 标签，开始加载 CSS 并构建 CSSOM；

  2. 遇到 script 标签，发现 JS 需要读取 CSS 样式；

  3. 暂停 JS 执行，等待 CSS 加载完成、CSSOM 构建完毕；

  4. 执行 JS，再继续后续解析和渲染。

结论：CSS 不会直接阻塞 JS 执行，但会间接阻塞——如果 JS 依赖 CSSOM，浏览器会先完成 CSS 解析，再执行 JS。

七、解决方案：async 和 defer 为什么能解决阻塞？（面试必背）

先明确：默认的 script 标签（无任何属性），会阻塞 HTML 解析和渲染，流程是：解析 HTML → 暂停 → 下载 JS → 执行 JS → 继续解析。

而 async 和 defer 能优化这种阻塞，核心是“并行下载 JS”，但两者有区别（记表格更清晰，面试可直接说）：

属性下载方式执行时机是否阻塞解析
async和 HTML 解析并行下载下载完成后立即执行（可能打断 HTML 解析）执行时阻塞，解析时不阻塞
defer和 HTML 解析并行下载HTML 解析全部完成后执行（在 DOMContentLoaded 之前）完全不阻塞 HTML 解析

通俗区分：async 是“下载完就跑”，执行顺序不确定；defer 是“下载完等一等，等页面解析完再跑”，执行顺序和标签顺序一致。

八、其他：preload / prefetch（面试知道即可）

两者均为浏览器资源预加载方案，用于优化资源加载顺序，减少阻塞，面试无需深入，记住核心区别即可：

  • preload：优先加载当前页面必须用到的关键资源（如核心JS、CSS），会阻塞页面渲染，确保资源提前准备好，避免后续使用时卡顿；

  • prefetch：预加载当前页面可能用到的资源（如后续页面的JS、图片），不阻塞页面渲染，空闲时加载，提升后续操作的响应速度。

总结：preload 优先保障当前页面，prefetch 提前准备后续资源，均为优化手段，面试提及即可得分。

九、面试高频追问（必背，覆盖延伸考点）

追问1：为什么 JS 不能多线程？

标准答法：因为 JS 核心功能之一是操作 DOM，而 DOM 不是线程安全的。如果多个线程同时操作 DOM（比如线程A修改DOM，线程B读取DOM），会导致数据不一致、渲染错乱。为了避免这种问题，浏览器设计时给 JS 设定了单线程模型。

追问2：为什么 requestAnimationFrame 不阻塞渲染？

标准答法：requestAnimationFrame 是浏览器专门为渲染设计的 API，它的执行时机是“浏览器下一帧渲染前”，属于渲染调度的一部分，不会像同步 JS 那样长时间占用主线程，因此不会阻塞渲染。

追问3：微任务会阻塞渲染吗？

标准答法：会。因为微任务的执行时机是“当前宏任务执行结束后，浏览器渲染前”，会先清空微任务队列，再进行渲染。如果微任务无限循环（比如 Promise 链式调用），会导致微任务队列永远清空不完，页面永远无法渲染，出现卡死。

十、面试终极标准回答结构（万能模板，直接背诵）

当面试官问“JS 为什么会阻塞渲染？”，按这个结构答，逻辑清晰、得分高：

  1. 核心前提：JS 执行和浏览器渲染共用主线程，浏览器是单线程模型，同一时间只能执行一个任务；

  2. 关键原因：JS 具有修改 DOM 和 CSSOM 的能力，而渲染必须依赖稳定的 DOM 和 CSSOM；

  3. 浏览器机制：为了保证 DOM 构建的完整性，避免渲染出错，浏览器在执行 JS 时，会暂停 HTML 解析和页面渲染；

  4. 具体表现：长任务会长时间占用主线程，导致渲染任务无法执行，页面出现白屏、无响应；

  5. 总结：本质是“单线程模型 + DOM 非线程安全”导致的必然结果。

十一、高级认知（面试加分，拉开差距）

很多人混淆“浏览器多进程”和“JS 多线程”，记住这句话：

现代浏览器是多进程架构（比如 Chrome 中，每个标签页是一个独立的渲染进程），但每个渲染进程内部，JS 仍然是单线程主线程模型。也就是说，多进程 ≠ JS 多线程，JS 始终是单线程执行的。

十二、面试常考真题（含标准答法，直接背诵）

真题1：JS 为什么会阻塞 HTML 解析？

答：因为 JS 可能修改 DOM 结构（如新增、删除节点），如果浏览器一边解析 HTML 构建 DOM，一边执行 JS 修改 DOM，会导致之前构建的 DOM 失效，造成资源浪费。因此浏览器会暂停 HTML 解析，先执行 JS，执行完毕后再继续解析。

真题2：JS 为什么会阻塞渲染？和阻塞解析有什么区别？

答：① 阻塞渲染的原因：JS 执行和渲染共用主线程，单线程模型下同一时间只能执行一个任务，JS 执行时会占用主线程，导致渲染任务无法执行，从而阻塞渲染；② 区别：阻塞解析是“暂停 HTML 解析”，阻塞渲染是“暂停 Layout 和 Paint 操作”；解析是构建 DOM 的过程，渲染是将 DOM+CSSOM 呈现到页面的过程，两者是渲染流程的不同阶段，但都被 JS 阻塞。

真题3：async 和 defer 的区别是什么？分别适用于什么场景？

答：区别：① 下载方式：两者都能和 HTML 解析并行下载 JS，不阻塞解析；② 执行时机：async 下载完成后立即执行，执行顺序不确定；defer 等 HTML 解析完成后执行，执行顺序和标签顺序一致；③ 阻塞情况：async 执行时会阻塞解析，defer 完全不阻塞。 适用场景：async 适用于不依赖 DOM、不依赖其他 JS 的独立脚本（如统计脚本）；defer 适用于依赖 DOM、需要按顺序执行的脚本（如操作页面元素的脚本）。

真题4：CSS 会阻塞 JS 执行吗？为什么？

答：会间接阻塞。因为 JS 可能读取元素的计算样式（如 getComputedStyle），而读取样式必须依赖 CSSOM（CSS 解析完成后构建的样式树）。如果 CSS 未加载、CSSOM 未构建完成，浏览器会暂停 JS 执行，等待 CSS 解析完成后再执行 JS，因此 CSS 会间接阻塞 JS 执行。

真题5：如何解决 JS 阻塞渲染的问题？（至少说3种方法）

答：① 使用 async 或 defer 属性加载外部 JS，实现 JS 并行下载，减少阻塞；② 将长任务拆分，使用 setTimeout、requestAnimationFrame 或微任务拆分耗时操作，避免长时间占用主线程；③ 动态加载 JS（如 document.createElement('script')），按需加载脚本，避免不必要的脚本阻塞；④ 把 JS 脚本放在 body 标签末尾，让 HTML 先解析完成，再执行 JS。

十三、总结文章（面试快速回顾，串联核心考点）

本文围绕“JS 为什么会阻塞渲染”这一前端面试高频题，从核心原因、底层机制、实际场景、解决方案到面试追问，层层拆解，核心考点可总结为3点，方便面试快速回顾：

  1. 核心逻辑：JS 阻塞渲染的本质是“单线程模型 + DOM 非线程安全”——JS 和渲染共用主线程，且 JS 可修改 DOM/CSSOM，浏览器为保证渲染正确，必须暂停解析和渲染，等待 JS 执行完成。

  2. 关键考点：script 标签默认阻塞 HTML 解析；async/defer 是核心解决方案，两者核心区别在执行时机；CSS 会间接阻塞 JS（依赖 CSSOM）；长任务、无限微任务会直接阻塞渲染。

  3. 面试技巧：回答核心问题时，先讲一句话标准答案，再拆解底层原因，最后结合实例补充；延伸追问（如 JS 单线程、preload/prefetch）记住核心结论即可，无需展开过多；真题答法按文档给出的标准结构，确保逻辑清晰、要点齐全。

整体而言，本知识点核心考察对浏览器渲染流程和 JS 执行机制的理解，记住“阻塞的本质、解决方案、延伸追问”三大模块，即可轻松应对面试各类相关问题，结合实例背诵，效果更佳。

avatar
文章
阅读
粉丝