终于考试完了,今天忽然想起来前阵子找实习的时候,今日头条面试官问我,js执行会阻塞DOM树的解析和渲染,那么css加载会阻塞DOM树的解析和渲染吗?因此,接下来我就来对css加载对DOM树的解析和渲染作一个测试。javascript
为了完成本次测试,先来科普一下,如何利用chrome来设置下载速度css
用代码说话:html
<!DOCTYPE html> <html lang="en"> <head> <title>css阻塞</title> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1"> <style> h1 { color: red !important } </style> <script> function h () { console.log(document.querySelectorAll('h1')) } setTimeout(h, 0) </script> <link href="https://cdn.bootcss.com/bootstrap/4.0.0-alpha.6/css/bootstrap.css" rel="stylesheet"> </head> <body> <h1>这是红色的</h1> </body> </html>
假设: css加载会阻塞DOM树解析和渲染java
假设结果: 在bootstrap.css还没加载完以前,下面的内容不会被解析渲染,那么咱们一开始看到的应该是白屏,h1不会显示出来。而且此时console.log的结果应该是一个空数组。webpack
实际结果:以下图web
由上图咱们能够看到,当css还没加载完成的时候,h1并无显示,可是此时控制台输出以下面试
能够得知,此时DOM树至少已经解析完成到了h1那里,而此时css还没加载完成,也就说明,css并不会阻塞DOM树的解析。chrome
由上图,咱们也能够看到,当css还没加载出来的时候,页面显示白屏,直到css加载完成以后,红色字体才显示出来,也就是说,下面的内容虽然解析了,可是并无被渲染出来。因此,css加载会阻塞DOM树渲染。gulp
其实我以为,这可能也是浏览器的一种优化机制。由于你加载css的时候,可能会修改下面DOM节点的样式,若是css加载不阻塞DOM树渲染的话,那么当css加载完以后,DOM树可能又得从新重绘或者回流了,这就形成了一些没有必要的损耗。因此我干脆就先把DOM树的结构先解析完,把能够作的工做作完,而后等你css加载完以后,在根据最终的样式来渲染DOM树,这种作法性能方面确实会比较好一点。
由上面的推论,咱们能够得出,css加载不会阻塞DOM树解析,可是会阻塞DOM树渲染。那么,css加载会不会阻塞js执行呢?bootstrap
一样,经过代码来验证.
<!DOCTYPE html> <html lang="en"> <head> <title>css阻塞</title> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1"> <script> console.log('before css') var startDate = new Date() </script> <link href="https://cdn.bootcss.com/bootstrap/4.0.0-alpha.6/css/bootstrap.css" rel="stylesheet"> </head> <body> <h1>这是红色的</h1> <script> var endDate = new Date() console.log('after css') console.log('通过了' + (endDate -startDate) + 'ms') </script> </body> </html>
假设: css加载会阻塞后面的js运行
预期结果: 在link后面的js代码,应该要在css加载完成后才会运行
实际结果:
由上图咱们能够看出,位于css加载语句前的那个js代码先执行了,可是位于css加载语句后面的代码迟迟没有执行,直到css加载完成后,它才执行。这也就说明了,css加载会阻塞后面的js语句的执行。详细结果看下图(css加载用了5600+ms):
由上所述,咱们能够得出如下结论:
所以,为了不让用户看到长时间的白屏时间,咱们应该尽量的提升css加载速度,好比能够使用如下几种方法:
以上,就是全部内容。以为还不错的点个推荐呗hhhh,欢迎交流