首页 > 代码库 > 浏览器加载解析过程
浏览器加载解析过程
为了搞清楚js css到底在页面加载的哪个环节中被执行使用了,就找了一些文章看了下,感觉没有理解的很透彻,但也比之前有更近一步认识。
解析html以构建dom树 -> 构建render树 -> 布局render树 -> 绘制render树
上面这个流程是最基本的了,但实际上从文档被请求回来之后,一步步的执行,结合几个比较重要的点,我自己理解如下,若有问题,望指正:
重要点:
最重要的:渲染引擎将会尽可能早的将内容呈现到屏幕上,并不会等到所有的html都解析完成之后再去构建和布局render树。它是解析完一部分内容就显示一部分内容,同时,可能还在通过网络下载其余内容。
dom的解析是深度遍历,所有子元素遍历完后,在解析下一个兄弟元素
css的选择符从右到左解析。
所以当文档从上到下解析的时候,
1、若遇到css,则构建css rule tree,
2、若遇到html标签,则构建dom tree,
3、若遇到js,则什么都不干,等js解析执行完成,js可能在此阶段修改dom tree 或css rule tree,浏览器希望等所有的都定下来后,再往下走。
-------以上为构建dom
4、然后等到某一部分内容都解析完成了,比如一个<div>...</div>这里所有的内容都解析完了,就利用这部分内容的相关的dom tree 和 css rule tree 生成一个render树(此过程中会将一些display none的元素干掉),
--------以上为构建render树
5、浏览器开始为每个元素定位
--------以上为布局render树
6、然后通过浏览器的绘制展现实际的元素给用户。
--------以上为绘制render树
7、然后浏览器接着往下执行,在后面的任何地方,若有对之前渲染过的部分有(布局)影响,就reflow之前的布局,重新走一遍流程,若只是对颜色等做了修改,不影响布局,则repain;reflow性能比repain 低。
了解后的启发:
js要放在最后,
css选择符从右到左寻找,故尽量使用子选择符 #tp > p{},而不是后代选择符 #tp p,更不要用通配符*
dom的结构,尽量减少嵌套深度
对于动画的部分(频繁修改的dom元素),采用脱离文档流的布局(fixed absoult),避免reflow
尽量用css类来定义或改变dom元素的样式,而不是直接对dom进行一个个属性设置,减少repain次数
尽量给图片等元素加上宽高,因为图片请求加载后,浏览器继续渲染,等图片回来后,宽高变了,影响了布局,浏览器不得不对这部分内容进行reflow,
浏览器加载解析过程