浏览器渲染与加载机制
<script>标签可以放在html文件中的任何位置,但一般放在head或body标签里面。上次在视频中听老师讲到最后放入head标签中,避免页面出现抖屏现象,所以决定深入了解一下浏览器的渲染和加载机制。
<script>标签位置
1. 放在<head>里
<head>标签仅次于<title>标签,放在<head>中则此js代码会在整个网页最开始解析时就加载执行,然后依次向下解析渲染。
注意:进行页面显示初始化的js必须放在head里面
2. 放在<body>里
浏览器按照页面标签的顺序依次解析,在读取到js代码时会执行js语句。
注意:对于通过事件调用的JS函数,具体放在页面的哪个位置并不影响其发挥作用的时间,因此,考虑到前端性能方面的问题,可以把不是最先执行的和事件调用的JS代码放在body的最下面。
浏览器加载和渲染的顺序
- IE下载的顺序从上到下,渲染顺序也是从上到下,下载和渲染同时进行。
- 在渲染到页面的某一部分时,其上面的所有部分都已经下载完成(并不是说所有相关联的元素都已经下载完)。
- 如果遇到语义解释性的标签嵌入文件(JS脚本,CSS样式),那么此时IE的下载过程会启用单独连接进行下载。
- 样式表在下载完成后,将和以前下载的所有样式表一起进行解析,解析完成后,将对此前所有元素(含以前已经渲染的)重新进行渲染。(也就是上面说的可能出现抖屏现象)
- JS、CSS中如有重定义,后定义函数将覆盖前定义函数。
JS的加载
- 不能并行下载和解析(阻塞下载)。
- 当引用了JS的时候,浏览器发送1个js request就会一直等待该request的返回。因为浏览器需要1个稳定的DOM树结构,而JS中很有可能有代码直接改变了DOM树结构,比如使用document.write或apppendChild,甚至是直接使用location.href进行跳转,浏览器为了防止出现JS修改DOM树,需要重新构建DOM树的情况,所以 就会阻塞其他的下载和呈现
加快HTML页面加载速度
-
页面减肥:
a. 页面的肥瘦是影响加载速度最重要的因素。
b. 删除不必要的空格、注释。
c. 将inline的script和css移到外部文件。
d. 可以使用HTML Tidy来给HTML减肥,还可以使用一些压缩工具来给JavaScript减肥。 -
减少文件数量:
a. 减少页面上引用的文件数量可以减少HTTP连接数。
b. 许多JavaScript、CSS文件可以合并最好合并,人家财帮子都把自己的JavaScript. functions和Prototype.js合并到一个base.js文件里去了。 -
减少域名查询:
a. DNS查询和解析域名也是消耗时间的,所以要减少对外部JavaScript、CSS、图片等资源的引用,不同域名的使用越少越好。 -
缓存重用数据:
a. 对重复使用的数据进行缓存。 -
优化页面元素加载顺序:
a. 首先加载页面最初显示的内容和与之相关的JavaScript和CSS,然后加载HTML相关的东西,像什么不是最初显示相关的图片、flash、视频等很肥的资源就最后加载。 -
减少inline JavaScript的数量:
a. 浏览器parser会假设inline JavaScript会改变页面结构,所以使用inline JavaScript开销较大。
b. 不要使用document.write()这种输出内容的方法,使用现代W3C DOM方法来为现代浏览器处理页面内容。 -
使用现代CSS和合法的标签:
a. 使用现代CSS来减少标签和图像,例如使用现代CSS+文字完全可以替代一些只有文字的图片。
b. 使用合法的标签避免浏览器解析HTML时做“error correction”等操作,还可以被HTML Tidy来给HTML减肥。 -
Chunk your content:
a. 不要使用嵌套table,而使用非嵌套table或者div。将基于大块嵌套的table的layout分解成多个小table,这样就不需要等到整个页面(或大table)内容全部加载完才显示。 -
指定图像和table的大小:
a. 如果浏览器可以立即决定图像或table的大小,那么它就可以马上显示页面而不要重新做一些布局安排的工作。
b. 这不仅加快了页面的显示,也预防了页面完成加载后布局的一些不当的改变。
c. image使用height和width。
HTML页面加载和解析流程
-
用户输入网址(假设是个html页面,并且是第一次访问),浏览器向服务器发出请求,服务器返回html文件。
-
浏览器开始载入html代码,发现<head>标签内有一个<link>标签引用外部CSS文件。
-
浏览器又发出CSS文件的请求,服务器返回这个CSS文件。
-
浏览器继续载入html中<body>部分的代码,并且CSS文件已经拿到手了,可以开始渲染页面了。
-
浏览器在代码中发现一个<img>标签引用了一张图片,向服务器发出请求。此时浏览器不会等到图片下载完,而是继续渲染后面的代码。
-
服务器返回图片文件,由于图片占用了一定面积,影响了后面段落的排布,因此浏览器需要回过头来重新渲染这部分代码。
-
浏览器发现了一个包含一行Javascript代码的<script>标签,赶快运行它。
-
Javascript脚本执行了这条语句,它命令浏览器隐藏掉代码中的某个<style>(style.display=”none”)。杯具啊,突然就少了这么一个元素,浏览器不得不重新渲染这部分代码。
-
终于等到了</html>的到来,浏览器泪流满面……
-
等等,还没完,用户点了一下界面中的“换肤”按钮,Javascript让浏览器换了一下<link>标签的CSS路径。
-
浏览器召集了在座的各位<div><span><ul><li>们,“大伙儿收拾收拾行李,咱得重新来过……”,浏览器向服务器请求了新的CSS文件,重新渲染页面。
- 问题1
加载过程中遇到外部css文件,浏览器另外发出一个请求,来获取css文件。遇到图片资源,浏览器也会另外发出一个请求,来获取图片资源。这是异步请求,并不会影响html文档进行加载,但是当文档加载过程中遇到js文件,html文档会挂起渲染(加载解析渲染同步)的线程,不仅要等待文档中js文件加载完毕,还要等待解析执行完毕,才可以恢复html文档的渲染线程。 - 原因:
JS有可能会修改DOM,最为经典的document.write,这意味着,在JS执行完成前,后续所有资源的下载可能是没有必要的,这是js阻塞后续资源下载的根本原因。 - 办法:
可以将外部引用的js文件放在</body>前。
- 问题:
虽然css文件的加载不影响js文件的加载,但是却影响js文件的执行,即使js文件内只有一行代码,也会造成阻塞。 - 原因:
可能会有 var width = $('#id').width(),这意味着,js代码执行前,浏览器必须保证css文件已下载和解析完成。这也是css阻塞后续js的根本原因。 - 办法:
当js文件不需要依赖css文件时,可以将js文件放在头部css的前面。
- 注意:
不要在外部调用的js文件中调用运行时间较长的函数,如果一定要用,可以使用setTimeout函数。 - 原因:
浏览器有以上五个常驻线程
-- 浏览器GUI渲染线程
-- javascript引擎线程
-- 浏览器定时器触发线程(setTimeout)
-- 浏览器事件触发线程
-- 浏览器http异步请求线程(.jpg <link />这类请求)
由于 javascript引擎线程为单线程,当js引擎线程(第二个)进行时,会挂起其他一切线程,所以代码都是先压到队列,采用先进先出的方式运行,这个时候3、4、5这三类线线程也会产生不同的异步事件。
预加载
-
现代浏览器存在 prefetch 优化,浏览器会另外开启线程,提前下载js、css文件,需要注意的是,预加载js并不会改变dom结构,他将这个工作留给主加载。
-
预加载网页,利用空余时间来提前加载该网页的后续网页
<link rel="prefetch" href="http://">
为js脚本添加defer属性,使得浏览器不等js脚本加载执行完,就加载后面的图片
<script defer="true" src="JavaScript.js" type="text/javascript"/>
解析
- DOM树构建过程是深度遍历过程,当前节点的所有子节点都构建好后才会去构建当前节点的下一个兄弟节点。
2 . 将CSS解析成 CSS Rule Tree 。
-
根据DOM树和CSSOM来构造 Rendering Tree。注意:Rendering Tree 渲染树并不等同于 DOM 树,因为一些像 Header 或 display:none 的东西就没必要放在渲染树中了。
-
有了Render Tree,浏览器已经能知道网页中有哪些节点、各个节点的CSS定义以及他们的从属关系。下一步操作称之为Layout,顾名思义就是计算出每个节点在屏幕中的位置。
-
再下一步就是绘制,即遍历render树,并使用UI后端层绘制每个节点。
image.png
上述这个过程是逐步完成的,为了更好的用户体验,渲染引擎将会尽可能早的将内容呈现到屏幕上,并不会等到所有的html都解析完成之后再去构建和布局render树。它是解析完一部分内容就显示一部分内容,同时,可能还在通过网络下载其余内容。
Reflow(回流):
浏览器要花时间去渲染,当它发现了某个部分发生了变化影响了布局,那就需要倒回去重新渲染。
Repaint(重绘):
如果只是改变了某个元素的背景颜色,文字颜色等,不影响元素周围或内部布局的属性,将只会引起浏览器的repaint,重画某一部分。
Reflow要比Repaint更花费时间,也就更影响性能。所以在写代码的时候,要尽量避免过多的Reflow。
引起reflow的原因
- 页面初始化
- 某些元素的尺寸变了
- 某些CSS的属性发生变化了,如display:none
- 操作DOM时,如添加子节点
减少 reflow/repaint
- 不要一条一条地修改 DOM 的样式。与其这样,还不如预先定义好 css 的 class,然后修改 DOM 的 className。
- 要把 DOM 结点的属性值放在一个循环里当成循环里的变量。
- 为动画的 HTML 元件使用 fixed 或 absoult 的 position,那么修改他们的 CSS 是不会 reflow 的。
- 千万不要使用 table 布局。因为可能很小的一个小改动会造成整个 table 的重新布局
CSS规范
CSS选择符是从右到左进行匹配的。从右到左!所以,#nav li 我们以为这是一条很简单的规则,秒秒钟就能匹配到想要的元素,但是,但是,但是,是从右往左匹配啊,所以,会去找所有的li,然后再去确定它的父元素是不是#nav。,因此,写css的时候需要注意:
- dom深度尽量浅。
- 减少inline javascript、css的数量。
- 使用现代合法的css属性。
- 不要为id选择器指定类名或是标签,因为id可以唯一确定一个元素。
- 避免后代选择符,尽量使用子选择符。原因:子元素匹配符的概率要大于后代元素匹配符。-后代选择符;#tp p{} 子选择符:#tp>p{}
- 避免使用通配符,举一个例子,.mod .hd *{font-size:14px;} 根据匹配顺序,将首先匹配通配符,也就是说先匹配出通配符,然后匹配.hd(就是要对dom树上的所有节点进行遍历他的父级元素),然后匹配.mod,这样的性能耗费可想而知.
总结
- JS的下载和执行会阻塞DOM树的构建以及其它资源的下载。原因是浏览器需要一个稳定的DOM树结构 ,来防止JS修改DOM树,导致需要重新构建DOM树的情况
- JS载入后马上执行,如果JS代码中有执行时间长的函数,用SetTimeOut()
- CSS文件的加载虽不影响JS文件的加载,但却可能影响到JS文件的执行造成阻塞。因此必须保证CSS文件已下载和解析完成。
4.关于顺序的问题,可以将CSS文件在最前面加载,再载入JS。并且对于事件调用型js代码可以放到<body>标签的最末端 。