浏览器加载解析过程

为了搞清楚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,

  

  

原文地址:https://www.cnblogs.com/laojun/p/7062348.html