浏览器渲染过程：
- 用户输入网址（假设是个 HTML 页面，并且是第一次访问），浏览器向服务器发出请求，服务器返回 HTML 文件；
- 浏览器开始载入 HTML 代码，发现 <head> 标签内有一个 <link> 标签引用外部 CSS 文件；
- 浏览器又发出 CSS 文件的请求，服务器返回这个 CSS 文件；
- 浏览器继续载入 HTML 中 <body> 部分的代码，并且 CSS 文件已经拿到手了，可以开始渲染页面了；
- 浏览器在代码中发现一个
<img>标签引用了一张图片，向服务器发出请求。此时浏览器不会等到图片下载完，而是继续渲染后面的代码； - 服务器返回图片文件，由于图片占用了一定面积，影响了后面段落的排布，因此浏览器需要回过头来重新渲染这部分代码；
- 浏览器发现了一个包含一行 JavaScript 代码的 <script> 标签，赶快运行它；
- JavaScript 脚本执行了这条语句，它命令浏览器隐藏掉代码中的某个 <div>（style.display=”none”）。由于突然少了一个元素，浏览器不得不重新渲染这部分代码；
- 终于等到了 </html> 的到来，浏览器泪流满面……
- 等等，还没完，用户点了一下界面中的“换肤”按钮，JavaScript 让浏览器换了一下 <link> 标签的 CSS 路径；
- 浏览器召集了在座的各位
<div><span><ul><li>们，“大伙儿收拾收拾行李，咱得重新来过……”，浏览器向服务器请求了新的CSS文件，重新渲染页面。
简单来说，浏览器渲染一共有五步，
1.解析HTML标签，构建DOM树。
- 在这个阶段，引擎开始解析html，解析出来的结果会成为一棵dom树
dom的目的至少有2个：
－ 作为下个阶段渲染树状图的输入
－ 成为网页和脚本的交互界面。(最常用的就是getElementById等等)
当解析器到达script标签的时候，发生下面四件事情
1.html解析器停止解析,
2.如果是外部脚本，就从外部网络获取脚本代码
3.将控制权交给js引擎，执行js代码
4.恢复html解析器的控制权
＝＝＝由此可以得到第一个结论1＝=＝＝
由于<script>标签是阻塞解析的，将脚本放在网页尾部会加速代码渲染。
defer和async属性也能有助于加载外部脚本。
defer使得脚本会在dom完整构建之后执行；
async标签使得脚本只有在完全available才执行，并且是以非阻塞的方式进行的。
2.解析CSS标签，构建CSSOM树。
我们已经看到html解析器碰到脚本后会做的事情，接下来我们看下html解析器碰到样式表会发生的情况
js会阻塞解析，因为它会修改文档(document)。css不会修改文档的结构，如果这样的话，似乎看起来css样式不会阻塞浏览器html解析。但是事实上 css样式表是阻塞的。阻塞是指当cssom树建立好之后才会进行下一步的解析渲染。
- 通过以下手段可以减轻cssom带来的影响
将script脚本放在页面底部
尽可能快的加载css样式表
将样式表按照media type和media query区分，这样有助于我们将css资源标记成非阻塞渲染的资源。
非阻塞的资源还是会被浏览器下载，只是优先级较低。
所有的样式表都会被解析成cssom对象模型(就和dom树一样展现结构)，每一个页面element都会被许多css规则匹配
- 匹配顺序：origin => weight => specificity
- css origin
-作者自定义
－浏览器使用者定义
－userAgent 定义
－ css weight
-normal weight
-!important weight
- css specificity (我们最应该关注的点)
注意：!important 已经被css的作者引入了浏览器，用来覆盖页面样式。
本来这个方式并不是给开发者使用的，在样式表中使用!important 会让我们忽略specificity 真正工作的原理。
－ specificity 是css令人困惑的主要来源。specificity规则由(a,b,c,d)的规则决定。
－a : 值为1(当样式放在style属性中的时候)，0为其它情况
－b : id在样式规则中出现的次数 eg:#slide #hello p的值就是2
－c : class，伪类，和属性在样式中出现的次数 eg:input[type=email]值就是2
－d : 标签个数(tag names)和伪类元素出现的次数
例如：
Example:
HTML
<div id=”sidebar”>
<div id=”widget” class=”class-div”>
<span class=”span-class” style=”color: red”>Hello, world!</span>
</div>
</div>
CSS
.span-class { /* Specificity (0, 0, 1, 0) */
color: green;
}
#sidebar #widget { /* Specificity (0, 2, 0, 0) */
color: orange;
}
#sidebar { /* Specificity (0, 1, 0, 0) */
color: yellow;
}
#sidebar .class-div { /* Specificity (0, 1, 1, 0) */
color: blue;
}
The inline rule, will have a specificity of (1, 0, 0, 0).
接下来的优先级是(0, 2, 0, 0)；以此类推
－ 使用!important 的样式覆盖都可以通过css优先级机制(比如加个样式等来提高优先级)
－ 总结：
－元素样式的应用按照如下规则排列
-origin
-weight
-specificity
-order of definition
specificity只有在origin和weight一致的情况下才有效，再次就是定义的顺序
最后定义的样式会覆盖之前的样式。
- 在解析css的过程中，cssom树并不是浏览器构建的唯一数据结构,css样式匹配是件重活
为了尽可能快的加载样式，每一种最精确的匹配规则都会被加入众多哈希表中的一张 。
有针对id,class类名，标签名和一些其他不符合任何规则的哈希表。
当浏览器试图寻找哪个样式表加载到元素上的时候，它没必要查看所有的规则，而只需要查看哈希表。
这又引导我们到另一个重要的知识:我们从一个元素开始，寻找它的id,class,标签等，然后在多个字典中查找他们，
我们总是匹配**最右边**的(rightmost)的选择器，这个选择器称为**主选择器(key selector).**
这个概念开始的时候可能有些难以理解，但是它对我们如何写更快的css规则至关重要。
让我们看个例子：
HTML
<div id=”container1”>
… thousands of <a> elements here …
<a> … </a>
… thousands of <a> elements here …
</div>
<div id=”container2”>
<a class=”a-class”>...</a>
</div>
我们假如要选择container2种的a标签
This selector:
#container2 a {...}
这个选择器将会严重影响加载性能，如果从左到右读取，那就是先找到#container2然后再找a标签
，然而浏览器将会从右往左读取，它会先读取所有的a标签，然后再沿着dom往上走，直到找到#container.
这意味着这个规则会寻找所有的a，但是实际上很多a在#container1之中。
我们可以写一个更有效率的样式表:#container2 .a-class {...}。
这个特性可以在javascript或者jquery中得到很好的发挥:
eg:将$(‘#container .class-name’)改为$(‘.class-name’, ‘#container’)可以很好的性能。
－前者会先去寻找.class-name然后再沿着dom树寻找#container元素
－后者会先找到#container，然后再沿着子树寻找.class-name的元素
3.把DOM和CSSOM组合成渲染树（render tree）。
-
render树
4.在渲染树的基础上进行布局，计算每个节点的几何结构。
布局(layout)：定位坐标和大小，是否换行，各种position, overflow, z-index属性 ……
5.把每个节点绘制到屏幕上（painting）,正式开画！
