浏览器加载解析渲染过程
为什么需要了解？
- 加载：我们可以在引用外部样式文件，外部js时，将他们放到合适的位置，使浏览器以最快的速度将文件加载完毕。
- 解析：我们可以在构建DOM结构，组织css选择器时，选择最优的写法，提高浏览器的解析速率。
- 渲染：明白渲染的过程，我们在设置元素属性，编写js文件时，可以减少”重绘“”重新布局“的消耗。
-
这三个过程在实际进行的时候又不是完全独立，而是会有交叉。会造成一边加载，一边解析，一边渲染的工作现象。
二：用户访问网页都发生了什么。
- 用户访问网页，DNS服务器（域名解析系统）会根据用户提供的域名查找对应的IP地址，找到后，系统会向对应IP地址的网络服务器发送一个http请求。
- 网络服务器解析请求，并发送请求给数据库服务器。
- 数据库服务器将请求的资源返回给网络服务器，网络服务器解析数据，并生成html文件，放入http response中，返回给浏览器。
- 浏览器解析 http response。
1~4步骤需要了解HTTP协议。
访问服务器端可能遭遇的问题：如果网络服务器无法获取数据库服务器返回的资源文件（http response 404），或者由于并发原因暂时无法处理用户的http请求（http response 500） - 浏览器解析 http response后，需要下载html文件，以及html文件内包含的外部引用文件，及文件内涉及的图片或者多媒体文件。
三：HTML页面加载和解析流程
1. 用户输入网址（假设是个html页面，并且是第一次访问），浏览器向服务器发出请求，服务器返回html文件；
2. 浏览器开始载入html代码，发现＜head＞标签内有一个＜link＞标签引用外部CSS文件；
3. 浏览器又发出CSS文件的请求，服务器返回这个CSS文件；
4. 浏览器继续载入html中＜body＞部分的代码，并且CSS文件已经拿到手了，可以开始渲染页面了；
5. 浏览器在代码中发现一个＜img＞标签引用了一张图片，向服务器发出请求。此时浏览器不会等到图片下载完，而是继续渲染后面的代码；
6. 服务器返回图片文件，由于图片占用了一定面积，影响了后面段落的排布，因此浏览器需要回过头来重新渲染这部分代码；
7. 浏览器发现了一个包含一行Javascript代码的＜script＞标签，赶快运行它；
8. Javascript脚本执行了这条语句，它命令浏览器隐藏掉代码中的某个＜div＞ （style.display=”none”）。突然少了这么一个元素，浏览器不得不重新渲染这部分代码；
9. 终于等到了＜/html＞的到来，浏览器泪流满面……
10. 等等，还没完，用户点了一下界面中的“换肤”按钮，Javascript让浏览器换了一下＜link＞标签的CSS路径；
11. 浏览器召集了在座的各位＜div＞＜span＞＜ul＞＜li＞们，“大伙儿收拾收拾行李，咱得重新来过……”，浏览器向服务器请求了新的CSS文件，重新渲染页面。
“值得注意的是，这个过程是逐步完成的，为了更好的用户体验，渲染引擎将会尽可能早的将内容呈现到屏幕上，并不会等到所有的html都解析完成之后再去构建和布局render树。它是解析完一部分内容就显示一部分内容，同时，可能还在通过网络下载其余内容。”
当浏览器获得一个html文件时，会“自上而下”加载，并在加载过程中进行解析渲染。
解析：
加载
即为获取资源文件的过程，不同浏览器，以及他们的不同版本在实现这一过程时，会有不同的实现效果(资源间互相阻塞)，。
加载过程中遇到外部css文件，浏览器另外发出一个请求，来获取css文件(会影响js的执行)。
遇到图片资源，浏览器也会另外发出一个请求，来获取图片资源。这是异步请求，并不会影响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的前面。
当然除了，<link href="" />这种形式，内部<style></style>这种样式定义，在考虑阻塞时也要考虑。
解析
解析的概念有些多，需要另写一篇文章。于是我就先简单的写一下。
1. 浏览器会将HTML解析成一个DOM树，DOM 树的构建过程是一个深度遍历过程：当前节点的所有子节点都构建好后才会去构建当前节点的下一个兄弟节点。
2. 将CSS解析成 CSS Rule Tree 。
3. 根据DOM树和CSSOM来构造 Rendering Tree。注意：Rendering Tree 渲染树并不等同于 DOM 树，因为一些像 Header 或 display:none 的东西就没必要放在渲染树中了。
4.有了Render Tree，浏览器已经能知道网页中有哪些节点、各个节点的CSS定义以及他们的从属关系。下一步操作称之为Layout，顾名思义就是计算出每个节点在屏幕中的位置。
5.再下一步就是绘制，即遍历render树，并使用UI后端层绘制每个节点。
渲染
即为构建渲染树的过程，它是原来DOM树的可视化表示，构建这棵树是为了以正确的顺序绘制文档内容。
渲染树和DOM树的关系，不可见的dom元素（<head>…</head> display=none）不会被插入渲染树中。还有像一些节点的位置为绝对或浮动定位（需要css知识理解），这些节点会在文本流之外，因此会在两棵树上的不同位置，渲染树标识出真实的位置，并用一个占位结构标识出他们原来的位置。
渲染最大的一个困难就是为每一个dom节点计算符合他的最终样式。
- 为每一个元素查找到匹配的样式规则，需要遍历整个规则表。关于遍历规则表的方法，我之前理解错啦。
#test p{ color:#999999}
为什么：可以去看之前css解析时，生成的样式对象，遍历的顺序，自然是从树的低端向上遍历。
计算样式的一些困难：
- 样式数据是非常大的结构，保存这样是的数据是很耗内存的。
- 选择器迭代太深，造成太多的无用遍历。
- 样式规则涉及非常复杂的级联，定义了规则的层次（理解：
<head>里引用的外部样式表，会被局部样式表中同一属性的设置取代。还有例如body内对font的设置本来会应用于孩子元素，但是如果body的孩子元素定义font属性，则会被后者取代）。
解决办法：共享样式数据。（元素可以共享样式数据的条件就是他们的状态是”一致“的。）
webkit渲染
计算样式并生成渲染对象的过程为attachment，每个dom节点有一个attach方法，attachment的过程是同步的，调用新节点的attach方法插入到dom树中。
parser：解析， Render Tree:渲染树 Layout:安排布局
渲染过程中，webkit使用一个标志位标志所有顶层样式都已经被加载完毕，如果dom元素进行attach时，css元素并没有被加载完毕，则放置占位符，并在文档中标记，当样式表加载完毕，则重新进行计算。
说明，文档的渲染还是要等待顶层css加载完毕。接下来的gecko应该也是需要等待顶层css加载完毕，否则“css规则树”（见下文）无法建立啊
Gecko渲染
图2：Mozilla的Geoko渲染引擎主流程
webkit渲染是一个元素与样式规则匹配的过程，Gecko则需要构建样式计算规则书，然后与dom树对应生成样式上下文数（及渲染树）。例子：
<html>
<body>
<div class=”err” id=”div1″>
<p>
this is a <span class=”big”> big error </span>
this is also a <span class=”big”> very big error</span>
</p>
</div>
<div class=”err” id=”div2″>
another error
</div>
</body>
</html>
//规则
1. div {margin:5px;color:black}
2. .err {color:red}
3. .big {margin-top:3px}
4. div span {margin-bottom:4px}
5. #div1 {color:blue}
6. #div2 {color:green}
解释一下：A：任意一个父级元素。B、E：代表元素选择器，B指div，E指div下的span。C、G：代表类选择器。D、F：代表：id选择器。后面的123456，代表匹配的规则。
解释一下：当遇到一个dom节点，例如：第二个div，根据css解析结果，进行规则匹配发现符合126这条规则线，我们发现，当遇到第一个div时已经匹配过12这条规则线，所以只需为规则6新增一个节点至样式上下文树的div：F节点。样式上下文树，是元素匹配样式的最终结果（原本是比例的也要换算成具体的px）。 Gecko利用样式规则树，有效的实现了样式共享。Webkit没有规则树，则需要对css解析结果进行多次遍历。出现多次的属性将会被按照正确的级联顺序进行处理最后一个生效。
根据对计算样式困难的理解，我们在编写css样式表时应该注意一下：
- dom深度尽量浅。
- 减少inline javascript、css的数量。
- 使用现代合法的css属性。
- 不要为id选择器指定类名或是标签，因为id可以唯一确定一个元素。
- 不要给类选择器指定标签，类，代表具有一类属性的标签，不仅是一个，虽然可以实现，但是降低了效率。
- 避免后代选择符，尽量使用子选择符。原因：子元素匹配符的概率要大于后代元素匹配符。后代选择符;#tp p{} 子选择符：#tp>p{}
- 避免使用通配符，举一个例子，.mod .hd *{font-size:14px;} 根据匹配顺序,将首先匹配通配符,也就是说先匹配出通配符,然后匹配.hd（就是要对dom树上的所有节点进行遍历他的父级元素）,然后匹配.mod,这样的性能耗费可想而知.
