CSS 与 JS 阻塞 DOM 解析和渲染大家肯定都知道的是标签放在头部性能会高一点，少一点人知道如果script与li

CSS

大家肯定都知道的是标签放在头部性能会高一点，少一点人知道如果script与link同时在头部的话，script在上可能会更好。这是为什么呢？

CSS 不会阻塞 DOM 的解析

注意哦！这里说的是DOM 解析，证明的例子如下

HTML代码如下

 <!DOCTYPE html>
  <html lang="en">
  <head>
      <meta charset="UTF-8">
      <title>Title</title>
  </head>
  <body>
      <div></div>
      	<link rel="stylesheet" href="/css/sleep3000-common.css">
          <script defer src="/js/logDiv.js"></script>
  </body>
  </html>

，logDiv.js 文件的内容是：

const div = document.querySelecot('div');
console.log(div);

defer属性相信大家也很熟悉了，MDN对此的描述是用来通知浏览器该脚本将在文档完成解析后，触发 DOMContentLoaded 事件前执行。设置这个属性，能保证DOM解析后马上打印出div。

之后将<link rel="stylesheet" href="/css/sleep3000-common.css">插入HTML文件的任一位置，该css文件延迟3秒后端返回， css 文件内容是：

div {
  background: red;
}

打开浏览器，可以看到是首先打印出div这个DOM节点，过3s左右之后才渲染出一个红色的div。这就证明了CSS 是不会阻塞 DOM 的解析的，尽管CSS下载需要3s，但这个过程中，浏览器不会傻等着CSS下载完，而是会解析DOM的。

这里简单说一下，浏览器是解析DOM生成DOM Tree，结合CSS生成的CSS Tree，最终组成render tree，再渲染页面。由此可见，在此过程中CSS完全无法影响DOM Tree，因而无需阻塞DOM解析。然而，DOM Tree和CSS Tree会组合成render tree。

那CSS会不会阻塞页面渲染呢？

CSS顺理成章地阻塞页面渲染。


 <!DOCTYPE html>
   <html lang="en">
  <header>
  	<style>
   	div {
   		width: 100px;
   		height: 100px;
   		background: lightgreen;
   	}
   </style>
   <link rel="stylesheet" href="/css/sleep3000-common.css">
   <script src="/js/logDiv.js"></script>
  </header>
   <body>
       <div></div>

   </body>
   </html>

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

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

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

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

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);

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

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

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

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

<head>
	<meta charset="UTF-8">
	<title>Title</title>
	<style>
		div {
			width: 100px;
			height: 100px;
			background: blue;
		}
	</style>
</head>
<body>
    <div></div>
    <script src="/js/sleep3000-logDiv.js"></script>
    <style>
        div {
            background: lightgrey;
        }
    </style>
    <script src="/js/sleep5000-logDiv.js"></script>
    <link rel="stylesheet" href="/css/common.css">
</body>

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

综上所述，我们得出这样的结论：

CSS 不会阻塞 DOM 的解析，但会阻塞 DOM 渲染。
JS 阻塞 DOM 解析，但浏览器会"偷看"DOM，预先下载相关资源。
浏览器遇到 <script>且没有defer或async属性的标签时，会触发页面渲染，因而如果前面CSS资源尚未加载完毕时，浏览器会等待它加载完毕在执行脚本。

所以，你现在明白为何<script>最好放底部，<link>最好放头部，如果头部同时有<script>与<link>的情况下，最好将<script>放在<link>上面了吗？

js中 defer与async的区别

图解：蓝色线代表网络读取，红色线代表执行时间，这两个都是针对脚本的；绿色线代表 HTML 解析。通过上图和之前的分析，我们可以得出：

       defer 和 async 在网络读取（脚本下载）这块儿是一样的，都是异步的（相较于 HTML 解析）两者的差别：在于脚本下载完之后何时执行。
       显然 defer 是最接近我们对于应用脚本加载和执行的要求的。defer是立即下载但延迟执行，加载后续文档元素的过程将和脚本的加载并行进行（异步），但是脚本的执行要在所有元素解析完成之后，DOMContentLoaded 事件触发之前完成。
      async是立即下载并执行，加载和渲染后续文档元素的过程将和js脚本的加载与执行并行进行（异步）。

关于 defer，我们还要记住的是它是按照加载顺序执行脚本的标记为async的脚本并不保证按照指定它们的先后顺序执行。对它来说脚本的加载和执行是紧紧挨着的，所以不管你声明的顺序如何，只要它加载完了就会立刻执行。