【知识点】你知道CSS 与 JS 是否会阻塞 DOM 解析和渲染吗？，web开发后台开发

用户33914928060
58 阅读4分钟

TCP协议

  • TCP 和 UDP 的区别？
  • TCP 三次握手的过程？
  • 为什么是三次而不是两次、四次？
  • 三次握手过程中可以携带数据么？
  • 说说 TCP 四次挥手的过程
  • 为什么是四次挥手而不是三次？
  • 半连接队列和 SYN Flood 攻击的关系
  • 如何应对 SYN Flood 攻击？
  • 介绍一下 TCP 报文头部的字段
  • TCP 快速打开的原理(TFO)
  • 说说TCP报文中时间戳的作用？
  • TCP 的超时重传时间是如何计算的？
  • TCP 的流量控制
  • TCP 的拥塞控制
  • 说说 Nagle 算法和延迟确认？
  • 如何理解 TCP 的 keep-alive？

浏览器篇

  • 浏览器缓存?
  • 说一说浏览器的本地存储？各自优劣如何？
  • 说一说从输入URL到页面呈现发生了什么？
  • 谈谈你对重绘和回流的理解
  • XSS攻击
  • CSRF攻击
  • HTTPS为什么让数据传输更安全？
  • 实现事件的防抖和节流？
  • 实现图片懒加载？

开源分享：docs.qq.com/doc/DSmRnRG… 其实这一点，刚才的例子已经说明了，如果CSS 不会阻塞页面阻塞渲染，那么CSS文件下载之前，浏览器就会渲染出一个浅绿色的div，之后再变成浅蓝色。浏览器的这个策略其实很明智的，想象一下，如果没有这个策略，页面首先会呈现出一个原始的模样，待CSS下载完之后又突然变了一个模样。用户体验可谓极差，而且渲染是有成本的。

因此，基于性能与用户体验的考虑，浏览器会尽量减少渲染的次数，CSS顺理成章地阻塞页面渲染。

然而，事情总有奇怪的，请看这例子，HTML头部结构如下：

但思考一下这会产生什么结果呢？

答案是浏览器会转圈圈三秒，但此过程中不会打印任何东西，之后呈现出一个浅蓝色的div，再打印出null。结果好像是CSS不单阻塞了页面渲染，还阻塞了DOM 的解析啊！稍等，在你打算掀桌子疯狂吐槽我之前，请先思考一下是什么阻塞了DOM 的解析，刚才已经证明了CSS是不会阻塞的，那么阻塞了页面解析其实是JS！但明明JS的代码如此简单，肯定不会阻塞这么久，那就是JS在等待CSS的下载，这是为什么呢？

仔细思考一下，其实这样做是有道理的，如果脚本的内容是获取元素的样式，宽高等CSS控制的属性，浏览器是需要计算的，也就是依赖于CSS。浏览器也无法感知脚本内容到底是什么，为避免样式获取，因而只好等前面所有的样式下载完后，再执行JS。因而造成了之前例子的情况。

所以，看官大人明白为何<script>与<link>同时在头部的话，<script>在上可能会更好了么？之所以是可能，是因为如果<link>的内容下载更快的话，是没影响的，但反过来的话，JS就要等待了，然而这些等待的时间是完全不必要的。

JS篇

JS，也就是<script>标签，估计大家都很熟悉了，不就是阻塞DOM解析和渲染么。然而，其中其实还是有一点细节可以考究一下的，我们一起来好好看看。

JS 阻塞 DOM 解析

首先我们需要一个新的JS文件名为blok.js，内容如下：

const arr = [];

for (let i = 0; i < 10000000; i++) {

arr.push(i);

arr.splice(i % 3, i % 7, i % 5);

}

const div = document.querySelector('div');

console.log(div);

其实那个数组操作时没意义的，只是为了让这个JS文件多花执行时间而已。之后把这个文件插入头部，浏览器跑一下。

结果估计大家也能想象得到，浏览器转圈圈一会，这过程中不会有任何东西出现。之后打印出null，再出现一个浅绿色的div。现象就足以说明JS 阻塞 DOM 解析了。其实原因也很好理解，浏览器并不知道脚本的内容是什么，如果先行解析下面的DOM，万一脚本内全删了后面的DOM，浏览器就白干活了。更别谈丧心病狂的document.write。浏览器无法预估里面的内容，那就干脆全部停住，等脚本执行完再干活就好了。

对此的优化其实也很显而易见，具体分为两类。如果JS文件体积太大，同时你确定没必要阻塞DOM解析的话，不妨按需要加上defer或者async属性，此时脚本下载的过程中是不会阻塞DOM解析的。

而如果是文件执行时间太长，不妨分拆一下代码，不用立即执行的代码，可以使用一下以前的黑科技：setTimeout()。当然，现代的浏览器很聪明，它会“偷看”之后的DOM内容，碰到如<link>、<script>和<img>等标签时，它会帮助我们先行下载里面的资源，不会傻等到解析到那里时才下载。

浏览器遇到 <script> 标签时，会触发页面渲染

这个细节可能不少看官大人并不清楚，其实这才是解释上面为何JS执行会等待CSS下载的原因。先上例子,HTML内body的结构如下：

div { background: lightgrey; }

这个例子也是很极端的例子，但不妨碍它透露给我们很多重要的信息。想象一下，页面会怎样呢？

答案是先浅绿色，再浅灰色，最后浅蓝色。由此可见，每次碰到<script>标签时，浏览器都会渲染一次页面。这是基于同样的理由，浏览器不知道脚本的内容，因而碰到脚本时，只好先渲染页面，确保脚本能获取到最新的DOM元素信息，尽管脚本可能不需要这些信息。

小结

TCP协议

  • TCP 和 UDP 的区别？
  • TCP 三次握手的过程？
  • 为什么是三次而不是两次、四次？
  • 三次握手过程中可以携带数据么？
  • 说说 TCP 四次挥手的过程
  • 为什么是四次挥手而不是三次？
  • 半连接队列和 SYN Flood 攻击的关系
  • 如何应对 SYN Flood 攻击？
  • 介绍一下 TCP 报文头部的字段
  • TCP 快速打开的原理(TFO)
  • 说说TCP报文中时间戳的作用？
  • TCP 的超时重传时间是如何计算的？
  • TCP 的流量控制
  • TCP 的拥塞控制
  • 说说 Nagle 算法和延迟确认？
  • 如何理解 TCP 的 keep-alive？

开源分享：【大厂前端面试题解析+核心总结学习笔记+真实项目实战+最新讲解视频】

浏览器篇

  • 浏览器缓存?
  • 说一说浏览器的本地存储？各自优劣如何？
  • 说一说从输入URL到页面呈现发生了什么？
  • 谈谈你对重绘和回流的理解
  • XSS攻击
  • CSRF攻击
  • HTTPS为什么让数据传输更安全？
  • 实现事件的防抖和节流？
  • 实现图片懒加载？

avatar
文章
阅读
粉丝