浏览器加载解析过程

Posted 2020-09-23 太上老俊

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