浏览器如何渲染网页
渲染过程
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 和 CSS 代码质量参差不齐，说不定哪天跑着跑着就挂掉了。好在这个世界还有这么一群人——页面重构工程师，平时挺不起眼，也就帮视觉设计师们切切图啊改改字，其实背地里还是干了不少实事的。
reflow（回流）
说到页面为什么会慢？那是因为浏览器要花时间、花精力去渲染，尤其是当它发现某个部分发生了点变化影响了布局，需要倒回去重新渲染，内行称这个回退的过程叫 reflow（回流，相关链接：reflow（回流））。
reflow 几乎是无法避免的。现在界面上流行的一些效果，比如树状目录的折叠、展开（实质上是元素的显 示与隐藏）等，都将引起浏览器的 reflow。鼠标滑过、点击……只要这些行为引起了页面上某些元素的占位面积、定位方式、边距等属性的变化，都会引起它内部、周围甚至整个页面的重新渲 染。通常我们都无法预估浏览器到底会 reflow 哪一部分的代码，它们都彼此相互影响着。 当 然，reflow 问题是可以优化的，我们可以尽量减少不必要的 reflow。比如开头的例子中的 <img> 图片载入问题，这其实就是一个可以避免的 reflow —— 给图片设置宽度和高度就可以了。这样浏览器就知道了图片的占位面积，在载入图片前就预留好了位置。
浏览器加载和渲染HTML的过程（标准定义的过程以及现代浏览器的优化），加载渲染
先看一下标准定义的浏览器渲染过程（网上找的）：
浏览器打开网页的过程
浏览器加载和渲染html的顺序
JS的加载
- 不能并行下载和解析（阻塞下载）
- web的模式是同步的，开发者希望解析到一个script标签时立即解析执行脚本，并阻塞文档的解析直到脚本执行完；如果脚本是外引的，当引用了JS的时候，浏览器发送一个js request就会一直等待该request的返回，这个过程也是同步的，会阻塞文档的解析直到资源被请求到。因为浏览器需要一个稳定的DOM树结构，而JS中很有可能有代码直接改变了DOM树结构，比如使用 document.write 或 appendChild，甚至是直接使用的location.href进行跳转，浏览器为了防止出现JS修改DOM树，需要重新构建DOM树的情况，所以就会阻塞其他的下载和呈现。这个模式保持了很多年，并且在html4及html5中都特别指定了。开发者可以将脚本标识为defer，以使其不阻塞文档解析，并在文档解析结束后执行。Html5增加了标记脚本为异步的选项，以使脚本的解析执行使用另一个线程。
这里面有几个点需要说明一下：
1.我们知道浏览器的处理过程是:
解析html生成DOM tree -> 根据DOM tree和样式表生成render tree ->
渲染render tree展示。浏览器为了让用户更快的看到页面，所以是边解析html生成局部的DOM tree，浏览器就生成部分render tree然后展示出来。
2.此过程中有两种外部资源是阻塞脚本执行，从而阻塞渲染的，分别是外部js和外部css。外部js是阻塞了DOM tree的生成，因为浏览器需要一个稳固的DOM tree，而js可能破坏这个结构（当然其中也可能会更改样式【注意是样式而不是样式表】，但是这个不阻塞也不会有影响的）；外部css样式表也会阻塞脚本的执行，理论上，既然样式表不改变Dom树，也就没有必要停下文档的解析等待它们，然而，存在一个问题，脚本可能在文档的解析过程中请求样式信息，如果样式还没有加载和解析，脚本将得到错误的值，显然这将会导致很多问题，这看起来是个边缘情况，但确实很常见。Firefox在存在样式表还在加载和解析时阻塞所有的脚本，而Chrome只在当脚本试图访问某些可能被未加载的样式表所影响的特定的样式属性时才阻塞这些脚本。
3.其他外部资源是不阻塞渲染的，比如图片，我们能看到很多时候页面大体的框架都呈现出来了，就是图片的位置没有显示出来的情况，等到图片下载下来以后再重新渲染。
最终决定浏览器表现出来的页面效果的差异是：渲染引擎 Rendering Engine（也叫做排版引擎），也就是我们通常所说的“浏览器内核”，负责解析网页语法（如HTML、JavaScript）并渲染、展示网页。相同的代码在不同的浏览器呈现出来的效果不一样，那么就很有可能是不同的浏览器内核导致的。
我们来看一下加载页面时浏览器的具体工作流程（图一）：
（图一）
1、解析HTML以重建DOM树（Parsing HTML to construct the DOM tree ）：渲染引擎开始解析HTML文档，转换树中的标签到DOM节点，它被称为“内容树”。
2、构建渲染树（Render tree construction）：解析CSS（包括外部CSS文件和样式元素），根据CSS选择器计算出节点的样式，创建另一个树 —- 渲染树。
3、布局渲染树（Layout of the render tree）: 从根节点递归调用，计算每一个元素的大小、位置等，给每个节点所应该出现在屏幕上的精确坐标。
4、绘制渲染树（Painting the render tree） : 遍历渲染树，每个节点将使用UI后端层来绘制。
主要的流程就是：构建一个dom树，页面要显示的各元素都会创建到这个dom树当中，每当一个新元素加入到这个dom树当中，浏览器便会通过css引擎查遍css样式表，找到符合该元素的样式规则应用到这个元素上。
注意了：css引擎查找样式表，对每条规则都按从右到左的顺序去匹配。 看如下规则：
|
|
#nav li {} |
CSS选择符是从右到左进行匹配的。了解这方面的知识后，我们知道这个之前看似高效地规则实际开销相当高，浏览器必须遍历页面上每个li元素并确定其父元素的id是否为nav。
*{} |
额，这种方法我刚写CSS的也写过，殊不知这种效率是差到极点的做法
因为*通配符将匹配所有元素，所以浏览器必须去遍历每一个元素，这样的计算次数可能是上万次！
|
|
ul#nav{} ul.nav{} |
在页面中一个指定的ID只能对应一个元素，所以没有必要添加额外的限定符，而且这会使它更低效。
同时也不要用具体的标签限定类选择符，而是要根据实际的情况对类名进行扩展。例如把ul.nav改成.main_nav更好。
因此, 在CSS书写过程中，总结出如下性能提升的方案：
- 避免使用通配规则 如 *{} 计算次数惊人！只对需要用到的元素进行选择
- 尽量少的去对标签进行选择，而是用class 如：#nav li{},可以为li加上nav_item的类名，如下选择.nav_item{}
- 不要去用标签限定ID或者类选择符 如：ul#nav,应该简化为#nav
- 尽量少的去使用后代选择器，降低选择器的权重值 后代选择器的开销是最高的，尽量将选择器的深度降到最低，最高不要超过三层，更多的使用类来关联每一个标签元素
- 考虑继承 了解哪些属性是可以通过继承而来的，然后避免对这些属性重复指定规则
选用高效的选择符，可以减少页面的渲染时间，从而有效的提升用户体验（页面越快，用户当然越喜欢^_^）,你可以看一下CSS selectors Test，这个实验的重点是评估复杂选择符和简单选择符的开销。也许当你想让渲染速度最高效时，你可能会给每个独立的标签配置一个ID，然后用这些ID写样式。那的确会超级快，也超级荒唐！这样的结果是语义极差，后期的维护难到了极点。
但说到底，CSS性能这东西对于小的项目来讲可能真的是微乎其微的东西，提升可能也不是很明显，但对于大型的项目肯定是有帮助的。而且一个好的CSS书写习惯和方式能够帮助我们更加严谨的要求自己。
浙公网安备 33010602011771号