原来 CSS 与 JS 是这样阻塞 DOM 解析和渲染的

时间: 2018-12-30阅读: 817标签: 渲染

hello~各位亲爱的看官老爷们大家好。估计大家都听过,尽量将css放头部,js放底部,这样可以提高页面的性能。然而,为什么呢?大家有考虑过么?很长一段时间,我都是知其然而不知其所以然,强行背下来应付考核当然可以,但实际应用中必然一塌糊涂。因此洗(wang)心(yang)革(bu)面(lao),小结一下最近玩出来的成果。

友情提示,本文也是小白向为主,如果直接想看结论可以拉到最下面看的~


由于关系到文件的读取,那是肯定需要服务器的,我会把全部的文件放在github上,给我点个 star 我会开心!掘金上再给我点个 我就更开心了~

node端唯一需要解释一下的是这个函数

function sleep(time) {
  return new Promise(function(res) {
    setTimeout(() => {
      res()
    }, time);
  })
}

嗯!其实就延时啦。如果css或者js文件名有sleep3000之类的前缀时,意思就是延迟3000毫秒才会返回这文件。

下文使用的html文件是长这样的:

    <!DOCTYPE html>
    <html lang="en">
    <head>
    	<meta charset="UTF-8">
    	<title>Title</title>
    	<style>
    		div {
    			width: 100px;
    			height: 100px;
    			background: lightgreen;
    		}
    	</style>
    </head>
    <body>
    	<div></div>
    </body>
    </html>

我会在其中插入不同的JS和CSS。

而使用的common.css,不论有没有前缀,内容都是这样的:

div {
  background: lightblue;
}

好了,话不多数,开始正文!


CSS

关于CSS,大家肯定都知道的是<link>标签放在头部性能会高一点,少一点人知道如果<script>与<link>同时在头部的话,<script>在上可能会更好。这是为什么呢?下面我们一起来看一下CSS对DOM的影响是什么。

CSS 不会阻塞 DOM 的解析

注意哦!这里说的是DOM 解析,证明的例子如下,首先在头部插入<script defer src="/js/logDiv.js"></script>,JS文件的内容是:

const div = document.querySelector('div');
console.log(div);
复制代码

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

之后将<link rel="stylesheet" href="/css/sleep3000-common.css">插入HTML文件的任一位置,打开浏览器,可以看到是首先打印出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 阻塞页面渲染

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

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

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

<header>
    <link rel="stylesheet" href="/css/sleep3000-common.css">
    <script src="/js/logDiv.js"></script>
</header>

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

答案是浏览器会转圈圈三秒,但此过程中不会打印任何东西,之后呈现出一个浅蓝色的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的结构如下:

<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>上面了吗?


来自:https://github.com/ljf0113/how-js-and-css-block-dom


站长推荐

1.云服务推荐: 国内主流云服务商,各类云产品的最新活动,优惠券领取。地址:阿里云腾讯云华为云

2.广告联盟: 整理了目前主流的广告联盟平台,如果你有流量,可以作为参考选择适合你的平台点击进入

链接: http://www.fly63.com/article/detial/1732

关闭

十行代码实现React App 的SEO优化

谷歌已经明确表示,他们会在抓取你的网站之前运行你的JavaScript代码。准确地说,他们的爬虫(crawler)中运用 Chrome 41浏览器打开网站,和真实用户用浏览器打开一样!但是还有其他搜索引擎和社交媒体网站可能并不会这么做

Web网页渲染的几种模式

本文主要内容来源于对上文的翻译,图也来源于此,加上了一点平时工作的理解,英语渣、翻译不是很准确,有条件的可以直接阅读上文链接。本文主要是自己在阅读时做的笔记,供自己以后查看。

vue单页面应用改造为多页面服务端渲染

正在开发中的项目是采用vue,Vue+router搭建的单页面应用,因2C项目有SEO的需求,就需要把当前的项目改为多页面+服务端渲染,调研之后使用了easywebpack-cli脚手架,基于Egg + Vue + Webpack4多页面服务端渲染项目

react 异步加载数据时的渲染问题

当数据需要异步加载时render获取不到数据可能会报一些错误,此时需要在render函数中加一个判断.行到render时,state对象的haveData为false, 所以此时页面展示 loading,当异步获取数据成功时

如何渲染几万条数据并不卡住界面?

如何在不卡住页面的情况下渲染数据,也就是说不能一次性将几万条 都渲染出来,而应该一次渲染部分 DOM,那么就可以通过 requestAnimationFrame 来 每 16 ms 刷新一次。

vue数据渲染

vue 是如何将编译器中的代码转换为页面真实元素的?这个过程涉及到模板编译成 AST 语法树,AST 语法树构建渲染函数,渲染函数生成虚拟 dom,虚拟 dom 编译成真实 dom 这四个过程

CSS 渲染原理以及优化策略

提起 CSS 很多童鞋都很不屑,尤其是看到 RedMonk 2019 Programming Language Rankings 的时候,CSS 竟然排到了第七位。我们先来看看这张排行榜:

web 前端页面的渲染(DOM)

CSS会阻塞渲染树的构建,不阻塞DOM构建,但是在CSSOM构建完成之前,页面不会开始渲染(一片空白),CSSOM构建完成后,页面将会显示出内容。

服务端渲染和客户端渲染:CSR和SSR

现在的web网站都是非常讲究用户体验,一般都会采用服务端渲染加客户端渲染一起实现功能。服务端渲染有利于搜索引擎优化(SEO),利于被网页爬虫抓取数据,多见于电商网站商品信息获取等。客户端渲染不利于搜索引擎优化

让页面更早的渲染:使用 preload 提升资源加载优先级

preload 是一个新的 Web 标准,旨在提高性能以及提供给 web 开发者更多的细粒度加载控制。它可以使开发者自定义加载逻辑而避免以 script 标签加载资源所带来的性能损耗。

点击更多...

内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权或违规,请与小编联系!情况属实本人将予以删除!