如有侵权请联系我 ！qq:1339567630
为什么要了解浏览器加载、解析、渲染这个过程？
好，我们先说一下，为什么要了解这些呢？如果想写出一个最佳实践的页面，就要好好了解。
了解浏览器如何进行加载，可以在引用外部样式文件，外部js时，将他们放到合适的位置，使浏览器以最快的速度将文件加载完毕。
了解浏览器如何进行解析，可以在构建DOM结构，组织css选择器时，选择最优的写法，提高浏览器的解析速率。
了解浏览器如何进行渲染，明白渲染的过程，在设置元素属性，编写js文件时，可以减少”reflow“”repaint“的消耗。
正文开始
一、浏览器的主要功能
浏览器的主要功能是将用户选择的web资源呈现出来，它需要从服务器请求资源，并将其显示在浏览器窗口中，资源的格式通常是HTML，也包括PDF、image及其他格式。用户用URI(Uniform Resource Identifier统一资源标识符)来指定所请求资源的位置，通过DNS查询，将网址转换为IP地址。整个浏览器工作的流程，之前博客中有论述：
1、输入网址。
2、浏览器查找域名的IP地址。
3. 浏览器给web服务器发送一个HTTP请求
4. 网站服务的永久重定向响应
5. 浏览器跟踪重定向地址 现在，浏览器知道了要访问的正确地址，所以它会发送另一个获取请求。
6. 服务器“处理”请求，服务器接收到获取请求，然后处理并返回一个响应。
7. 服务器发回一个HTML响应
8. 浏览器开始显示HTML
9. 浏览器发送请求，以获取嵌入在HTML中的对象。在浏览器显示HTML时，它会注意到需要获取其他地址内容的标签。这时，浏览器会发送一个获取请求来重新获得这些文件。这些文件就包括CSS/JS/图片等资源，这些资源的地址都要经历一个和HTML读取类似的过程。所以浏览器会在DNS中查找这些域名，发送请求，重定向等等…
那么，一个页面，究竟是如何从我们输入一个网址到最后完整的呈现在我们面前的呢？还需要了解一下浏览器是如何渲染的：
二、浏览器的渲染
下面是渲染引擎在取得内容之后的基本流程：
解析html以构建dom树 -> 构建render树 -> 布局render树 -> 绘制render树
先来看个图：
所以，浏览器会解析三个东西：
(1) HTML/SVG/XHTML，解析这三种文件会产生一个 DOM Tree。
(2) CSS，解析 CSS 会产生 CSS 规则树。
(3) JavaScript脚本，主要是通过 DOM API 和 CSSOM API 来操作 DOM Tree 和 CSS Rule Tree.
我今天又纠结了一上午，到底是怎么解析怎么渲染的，我的疑问在于，浏览器到底是先解析生成了DOM树，然后再加载CSS JS文件进行渲染，还是在生成DOM的过程中，遇到了 link script 然后就加载CSS JS，边加载边渲染。我有这种疑问的原因在于，看网上的帖子，说的根本不一样好嘛！ 比如这篇 我想说，这个写的让我直接懵逼，真的是直接懵逼啊，学习的过程中，总会遇到困难，但这次，让我真的好难啊。不过正因为不懂才继续查资料继续学习嘛 ==！我又查了一上午，自己测试测试测试，然后觉着，我好像是明白点了。真的推荐大家去认真看《how browsers work》这篇文章，学习不懂得知识的时候，还是要从比较权威的资料看起比较好，也不要像我今天这样，无头苍蝇乱查。
那么就来说一下图中的过程，我是按照自己的理解来说，如果有误，欢迎指正。
当浏览器获得一个html文件时，会“自上而下”加载，并在加载过程中进行解析渲染。
解析：
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后端层绘制每个节点。
重点来了：
上述这个过程是逐步完成的，为了更好的用户体验，渲染引擎将会尽可能早的将内容呈现到屏幕上，并不会等到所有的html都解析完成之后再去构建和布局render树。它是解析完一部分内容就显示一部分内容，同时，可能还在通过网络下载其余内容。(这段话是《how browsers work》里面讲的，让我茅塞顿开)
几个概念：
(1)Reflow(回流)：浏览器要花时间去渲染，当它发现了某个部分发生了变化影响了布局，那就需要倒回去重新渲染。
(2)Repaint(重绘)：如果只是改变了某个元素的背景颜色，文字颜色等，不影响元素周围或内部布局的属性，将只会引起浏览器的repaint，重画某一部分。
Reflow要比Repaint更花费时间，也就更影响性能。所以在写代码的时候，要尽量避免过多的Reflow。
reflow的原因：
(1)页面初始化的时候；
(2)操作DOM时；
(3)某些元素的尺寸变了；
(4)如果 CSS 的属性发生变化了。
减少 reflow/repaint
(1)不要一条一条地修改 DOM 的样式。与其这样，还不如预先定义好 css 的 class，然后修改 DOM 的 className。
(2)不要把 DOM 结点的属性值放在一个循环里当成循环里的变量。
(3)为动画的 HTML 元件使用 fixed 或 absoult 的 position，那么修改他们的 CSS 是不会 reflow 的。
(4)千万不要使用 table 布局。因为可能很小的一个小改动会造成整个 table 的重新布局。
我应该是已经把网上所有的关于浏览器加载 解析 渲染过程的文章都看全了，其中写的比较好的一个版本是下面这个：
与讨论主题相关的其他思考
编写CSS时应该注意：
CSS选择符是从右到左进行匹配的。从右到左！所以，#nav li 我们以为这是一条很简单的规则，秒秒钟就能匹配到想要的元素，但是，但是，但是，是从右往左匹配啊，所以，会去找所有的li，然后再去确定它的父元素是不是#nav。，因此，写css的时候需要注意：
dom深度尽量浅。
减少inline javascript、css的数量。
使用现代合法的css属性。
不要为id选择器指定类名或是标签，因为id可以唯一确定一个元素。
避免后代选择符，尽量使用子选择符。原因：子元素匹配符的概率要大于后代元素匹配符。后代选择符;#tp p{} 子选择符：#tp>p{}
避免使用通配符，举一个例子，.mod .hd *{font-size:14px;} 根据匹配顺序,将首先匹配通配符,也就是说先匹配出通配符,然后匹配.hd(就是要对dom树上的所有节点进行遍历他的父级元素),然后匹配.mod,这样的性能耗费可想而知.
关于script标签的位置
现在，我们大都会将script标签放在body结束标签之前，那原因是什么呢？我今天也做了一个测试。
测试js代码位置var item = document.getElementById("item");
cosole.log(item);
你好
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
181
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
上述代码中有一段js代码，要在控制台打印一个元素，我把script标签放在head里，控制台里打印出来的是null。
我又把js代码放在body结束标签之前，打印出来的就是div元素了
453
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
