最近系统梳理HTML5
所有涉及到的标签时,梳理至和
标签时,碰巧想到一个困扰很久的问题,即一般把
放在
尾部,
标签放在
内部,而页面通过
CDN
引入第三方框架或库时,基本都是将其标签放在
标签前面。
可能此方式已经成为了约定俗成,但是究竟其好处在哪里,或者说其它的方式为什么不可取,想必你也和我有同样的疑问,那就接着来往下看吧。
首先需要做的准备工作是,搭建一个服务器,目的是为了返回css
样式和js
脚本,并且让服务器根据传递的参数,固定延时返回数据。
其目录结构如下,其中index.js
和style.css
就是用于返回的数据,app.js
为服务器启动文件,index.html
是用来测试案例的文件,剩余文件或文件夹可以忽略。
├── static
│ ├── index.js
│ ├── style.css
├── app.js
├── index.html
├── package.json
├── node_modules/
涉及的相关代码也贴一下吧,方便复制调试。有必要说明一下,本地运行node app.js
启动后,浏览器输入http://127.0.0.1:3000/
就能访问到index.html
,而访问style.css
可以输入http://127.0.0.1:3000/static/style.css?sleep=3000
,其中sleep
参数则可自由控制css
文件延时返回,例如想要文件5s
后返回就设置sleep=5000
。
// app.js
const express = require('express')
const fs = require('fs')
const app = new express()
const port = 3000
const sleepFun = time => {
return new Promise(res => {
setTimeout(() => {
res()
}, time)
})
}
const filter = (req, res, next) => {
const { sleep } = req.query || 0
if (sleep) {
sleepFun(sleep).then(() => next())
} else {
next()
}
}
app.use(filter)
app.use('/static/', express.static('./static/'))
app.get('/', function (req, res, next) {
fs.readFile('./index.html', 'UTF-8', (err, data) => {
if (err) return
res.send(data)
})
})
app.listen(port, () => {
console.log(`app is running at http://127.0.0.1:${port}/`)
})
// static/index.js
var p = document.querySelector('p')
console.log(p)
// static/style.css
p {
color: lightblue;
}
接着就是index.html
的准备工作,其中HTML
部分的架子就长下面那样,然后你只需要记住DOMContentLoaded
事件将在页面DOM
解析完成后触发。
<!DOCTYPE html>
<html lang="zh-CN">
<head>
<script>
document.addEventListener('DOMContentLoaded', () => {
var p = document.querySelector('p')
console.log(p)
})
</script>
</head>
<body>
<p>hello world</p>
</body>
</html>
首先在index.html
插入如下标签,然后在浏览器输入
http://127.0.0.1:3000/
访问此页面。
<head>
<script>
document.addEventListener('DOMContentLoaded', () => {
var p = document.querySelector('p')
console.log(p)
})
</script>
<link rel="stylesheet" href="./static/style.css?sleep=3000">
</head>
<body>
<p>hello world</p>
</body>
页面初始显示为空白,控制台打印出了p
元素,同时浏览器标签页上加载loading
,3s
后页面显示出浅蓝色的hello world
。
以上情况也就说明,CSS
不会阻塞DOM
的解析,如果说CSS
阻塞DOM
解析的话,那么p
标签不会被解析,进而DOM
不会被解析完成,CSS
请求过程中也就不可能会触发DOMContentLoaded
事件。而且在css
请求过程中,控制台立即打印出了p
元素,因此CSS
不会阻塞DOM
的解析。
另一个情况就是,虽然DOM
很早就被解析完成,但是p
标签却迟迟没有渲染,原因在于CSS
样式还未请求完成,在样式获取后hello world
才被渲染出来,所以说CSS
会阻塞页面渲染。
简单阐述一下浏览器的解析渲染过程,解析DOM
生成DOM Tree
,解析CSS
生成CSSOM Tree
,两者结合生成render tree
渲染树,最后浏览器根据渲染树渲染至页面。由此可以看出DOM Tree
的解析和CSSOM Tree
的解析是互不影响的,两者是并行的。因此CSS
不会阻塞页面DOM
的解析,但是由于render tree
的生成是依赖DOM Tree
和CSSOM Tree
的,因此CSS
必然会阻塞DOM
的渲染。
更为严谨一点的说,CSS
会阻塞render tree
的生成,进而会阻塞DOM
的渲染。
为了避免加载CSS
造成的干扰,如下仅关注JS
的执行情况,其中for
循环的循环体中逻辑暂不考虑,仅仅是让JS
执行更多时间。
<head>
<script>
document.addEventListener('DOMContentLoaded', () => {
var p = document.querySelector('p')
console.log(p)
})
</script>
</head>
<body>
<script>
const p = document.querySelector('p')
console.log(p)
for (var i = 0, arr = []; i < 100000000; i++) {
arr.push(i)
}
</script>
<p>hello world</p>
</body>
浏览器访问页面,初始时为空白且控制台打印null
,浏览器loading
短暂延时后,控制台打印出p
标签同时页面渲染出hello world
。
以上情况很容易说明JS
会阻塞DOM
解析了,JS
执行初控制台打印null
,因为此时p
标签还未被解析,for
循环执行时,可以明显感觉到执行耗时,执行完成p
标签被解析,此时触发DOMContentLoaded
事件,控制台打印出p
标签,同时页面渲染出hello world
。
比较合理的解释就是,首先浏览器无法知晓JS
的具体内容,倘若先解析DOM
,万一JS
内部全部删除掉DOM
,那么浏览器就白忙活了,所以就干脆暂停解析DOM
,等到JS
执行完成再继续解析。
如下在页内JS
脚本前插入标签,并且延时
3s
获取CSS
样式。
<head>
<script>
document.addEventListener('DOMContentLoaded', () => {
var p = document.querySelector('p')
console.log(p)
})
</script>
<link rel="stylesheet" href="./static/style.css?sleep=3000">
<script src="./static/index.js"></script>
</head>
<body>
<p>hello world</p>
</body>
初始页面空白,浏览器loading
加载3s
后,控制台打印出null
,紧接着打印出p
标签,同时页面渲染出浅蓝色p
标签。
此情况好像是CSS
不仅阻塞了DOM
的解析,并且也阻塞了DOM
渲染。
但是首先要思考下是什么阻塞了DOM
的解析,刚刚已经证明了CSS
不会阻塞DOM
的解析,所以只可能是JS
阻塞了DOM
解析。但是JS
只有两行代码,不会阻塞长达3s
左右的时间。所以只有一个可能就是CSS
会阻塞JS
的执行。
因此输出结果也能大致分析出来了,首先解析到第一个标签,
document
绑定上DOMContentLoaded
事件,紧接着解析到link
标签,浏览器请求CSS
样式,由于CSS
不会阻塞DOM
解析,因此浏览器继续向下解析,发现第二个标签,浏览器请求
JS
脚本,此时JS
获取完成,但是由于CSS
还在获取,JS
需要一直等待其获取完成,所以不能立即执行。
而第二个不能立即执行,导致它后面的
p
标签也没办法解析,原因则是JS
会阻塞DOM
解析。只有等待到CSS
样式获取成功后,此时JS
立即执行,控制台输出null
,然后浏览器继续解析到p
标签,解析完成,DOMContentLoaded
事件触发,控制台输出p
标签,最后浅蓝色hello world
渲染至页面。
其实这样做也是有道理的,设想JS
脚本中的内容是获取DOM
元素的CSS
样式属性,如果JS
想要获取到DOM
最新的正确的样式,势必需要所有的CSS
加载完成,否则获取的样式可能是错误或者不是最新的。因此要等到JS
脚本前面的CSS
加载完成,JS
才能再执行,并且不管JS
脚本中是否获取DOM
元素的样式,浏览器都要这样做。
回溯文章开头的那个疑问,所以一般将放在
标签前面是有道理的。
如下CSS
采用页内方式,其中颜色名及其rgb
值分别为浅绿色lightgreen
(rgb(144, 238, 144)
)、粉色pink
(rgb(255, 192, 203)
)。
// index.html
<head>
<style>
p {
color: lightgreen;
}
</style>
</head>
<body>
<p>hello</p>
<script src="./static/index.js?sleep=2000"></script>
<p>beautiful</p>
<style>
p {
color: pink;
}
</style>
<script src="./static/index.js?sleep=4000"></script>
<p>world</p>
<style>
p {
color: lightblue;
}
</style>
</body>
// static/index.js
var p = document.querySelector('p')
var style = window.getComputedStyle(p, null)
console.log(style.color)
页面初始渲染出浅绿色hello
,紧接着2s
后渲染出粉色hello beautiful
且控制台打印rgb(144, 238, 144)
,然后又2s
后渲染出浅蓝色hello beautiful world
且控制台打印rgb(255, 192, 203)
。
上述结果大致分析为浏览器首先解析第一个标签和
hello
文本的p
标签,此时继续向下解析发现了第一个标签,紧接着触发一次渲染,由于此过程非常快所以页面初始就能看到浅绿色
hello
。
然后浏览器发出JS
请求,2s
后JS
获取完成立即运行控制台输出rgb(144, 238, 144)
,JS
运行完成后浏览器继续向下解析到beautiful
文本的p
标签和第二个标签,再继续向下解析发现了第二个
标签,触发一次渲染,这个过程也是非常快,所以可以看到控制台输出结果和渲染粉色
hello beautiful
几乎是同时的。
解析到第二个标签时,浏览器不会发出请求(稍作解释),
2s
后获取到JS
脚本并执行,控制台输出rgb(255, 192, 203)
,紧接着浏览器继续向下解析到world
文本的p
标签和第三个标签,此时
DOM
解析完成,再进行正常的渲染,这个过程也是非常快,所以也能看到控制台输出结果和渲染浅蓝色hello beautiful world
几乎是同时的。
现在来解答刚才那个问题,浏览器解析DOM
时,虽然会一行一行向下解析,但是它会预先加载具有引用标记的外部资源(例如带有src
标记的标签),而在解析到此标签时,则无需再去加载,直接运行,以此提高运行效率。所以就会有上述两个输出结果间隔
2s
的情况,而不是4s
,因为浏览器预先就一起加载了两个脚本,第一个
脚本加载完成时,第二个
脚本还剩大概
2s
加载完成。
而这个结论才是解释为何CSS
会阻塞JS
的执行的真正原因,浏览器无法预先知道脚本的具体内容,因此在碰到标签时,只好先渲染一次页面,确保
脚本内能获取到
DOM
的最新的样式。倘若在决定渲染页面时,还有尚未加载完成的CSS
样式,只能等待其加载完成再去渲染页面。
来看一个较为特殊的情况。
<head>
<script>
document.addEventListener('DOMContentLoaded', () => {
var p = document.querySelector('p')
console.log(p)
})
</script>
</head>
<body>
<p>hello</p>
<link rel="stylesheet" href="./static/style.css?sleep=3000">
<p>world</p>
</body>
按照上述的所有结论,预先分析一下运行结果,首先浏览器解析脚本,
document
上绑定了DOMContentLoaded
事件,紧接着浏览器继续向下解析,发现了文本为hello
的p
标签和标签,浏览器发起
CSS
请求,由于CSS
不会阻塞DOM
解析,浏览器继续向下解析至文本为world
的p
标签,此时页面解析完成,DOMContentLoaded
事件触发控制台输出p
标签,3s
后页面渲染出浅蓝色hello world
。
因此初始时页面空白,浏览器loading
加载3s
后,控制台打印出p
标签,同时页面渲染出浅蓝色hello world
。
但是实际结果并不是这样,先来看看Chrome
浏览器下的表现。
再来看看Firefox
浏览器下的表现。
接着再来看看Opera
浏览器下的表现。
IE11
及以下浏览器的表现。
Edge
浏览器下的表现。
怎么样,蒙了吧,5
种浏览器3
种表现形式,并且没有一种表现与预先分析的一致。
其实造成这种差异的原因,是一种被称为浏览器样式闪烁(FOUC,Flash of Unstyled Content
)的现象。
由于浏览器引擎的架构方式不一致,在浏览器解析到Body
内的CSS
的时候,浏览器引擎是可以做出选择的。
一种选择是它可以在请求CSS
的时候暂停后续DOM
的解析,在CSS
加载完成后再继续往后解析,此情况就会造成CSS
阻塞DOM
的解析,导致页面DOM
解析及其样式渲染推迟,而此表现形式就与JS
的情况相似。
另一种选择是它也可以在请求CSS
的时候继续往后解析,此时CSS
的加载与DOM
的解析就是并行的,等到CSS
加载完成后再更新样式,此情况下部分DOM
样式就会从默认样式立即跳转到有样式状态,形成样式闪烁。
此小结不必太过于纠结,只需记住Body
内的CSS
会由于浏览器的差异,呈现不同的表现形式,而这种现象一般称为FOUC
,代码中应当极力避免此种情况发生即可。
综合上述所有情况,可以得出如下结论。
CSS
不会阻塞DOM
解析,但是会阻塞DOM
渲染,严谨一点则是CSS
会阻塞render tree
的生成,进而会阻塞DOM
的渲染JS
会阻塞DOM
解析CSS
会阻塞JS
的执行
标签且没有defer
或async
属性时会触发页面渲染Body
内部的外链CSS
较为特殊,会形成FOUC
现象,请慎用伙伴们,如果你已经看到了这里,觉得这篇文章有帮助到你的话不妨点赞或 Star ✨支持一下哦!
手动码字,如有错误,欢迎在评论区指正~
你的支持就是我更新的最大动力~
GitHub / Gitee、GitHub Pages、掘金、CSDN 同步更新,欢迎关注~