从大红书中学习到的<script>的位置对页面渲染的影响
HTML文档解释方式：
- 按照HTML文档中顺序依次从上到下解释
- 解释过程中遇到
<link>就会异步的下载css然后继续向下解释 - 遇到
<img>就会异步的下载图片，然后继续向下解释 - 遇到
<script>会立刻停止继续向下解释，然后开始同步请求js文件，然后逐句执行JS文件中的代码，直到代码都执行完，然后再回去解释HTML
<script>标签的位置
我们该如何缓解同步执行的script脚本阻塞HTML的解释呢？
-
将
<script>放在<body>最后一部分 -
给
<script>加defer属性：用途：告知浏览器立即下载这个JS文件但是等到解释到
</html>之后再执行JS中的代码
缺陷：如果有多个外联的JS脚本，没有办法确定脚本执行的先后顺序
对大红书中学习到的<script>的位置的问题
将<script>放在<body>最后一部分可以减少浏览器空白时间
-
Q:浏览器工作流程：
- 解析HTML文档生成DOM树
- 解析CSS生成CSSOM树
- CSSOM树和DOM树结合形成Rendering Tree
- Layout
- 渲染
那么问题来了，rendering tree生成完计算完位置才会渲染页面，那么
<script>标签不论放在哪里怎么会对浏览器渲染有影响，毕竟<script>也是DOM树的一部分啊？ -
Q：使用defer属性可以理解为将DOM树生成完毕Render树生成完毕Layout和渲染都做完再执行JS吗？似乎看起来安全性也比较高，因为毕竟所有的DOM都挂载好了不会出现
getElementBy**为空了
实际情况
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
</head>
<body>
<div>
加载前
</div>
<script src="https://cdnjs.cloudflare.com/ajax/libs/mustache.js/2.3.0/mustache.min.js"></script>
<div id="list">
加载后
</div>
</body>
</html>
- 然后调整
Chrome devTool的network为slow 3G - 发现页面出现的效果是，首先出现
加载前过了一段时间出现了加载后
---> 这样的现象确实验证了大红书所说无误，那么该怎么解释render tree的问题呢？
解答
- 先说结果吧：
-
JS 会阻塞 DOM 解析，也就是说JS会阻塞DOM TREE的生成
- 因此如果你将
<script>放在<head>中，会阻塞解析body的DOM和生成可见DOM TREE的过程
- 因此如果你将
-
浏览器遇到 <script>且没有defer或async属性的 标签时，会触发页面渲染（前提：CSSOM TREE构建完毕）
- 因此解释了刚刚的demo（demo中没有css文件）中，浏览器将script标签之前的内容都展示了出来
-
JS 会阻塞 DOM 解析，也就是说JS会阻塞DOM TREE的生成
答案知识补充
css会阻塞Render Tree生成
等价于： css会阻塞页面Layout和渲染
解释：
- css文件不会阻塞DOM Tree生成过程
- Render Tree必须等待DOM Tree和CSSOM Tree创建完
- css文件阻塞了页面渲染
- 之前提到浏览器遇到
<script>会渲染一次页面，如果在Head中遇到<script>同样也会渲染，虽然没有DOM树，但是如果之前有css那么就必须要等待CSSOM TRee生成之后才能渲染，因此- css同样也会阻塞JS的执行
理解：
- 这样是很好解释的，毕竟css的出现一般都会影响到页面的Layout以及渲染，所以等待css执行完毕再渲染页面这样耗损也最少
JS会阻塞DOM Tree的完整创建
解释
- 如果JS放在Head中，遇到
<script>渲染不出任何东西，然后中断解析body创建DOM Tree， 然后运行JS，导致首屏空白时间变长 - 如果JS放在Body的中间，遇到
<script>渲染出JS之前的DOM TREE内容，首屏空白时间不会受影响，但是会延迟完整DOM TREE的展示 - 如果JS放在Body的最后，遇到
<script>渲染出JS之前的创建好的整个DOM TREE，首屏空白时间不会受影响，并且可以渲染出完整的body中内容
理解
- 浏览器并不知道脚本的内容是什么，如果先行解析下面的DOM，万一脚本内全删了后面的DOM，浏览器就白干活了。浏览器无法预估JS里面的内容，那就干脆全部停住，等脚本执行完再干活就好了。
网友评论