页面渲染深入解析_html/css_WEB-ITnose

用户请求的资源通过浏览器的网络层到达渲染引擎后，渲染工作开始。每次渲染文档通常不会超过8K的数据块，其中基础的渲染过程如下图所示:

第一步：渲染引擎首先解析HTML文档，转换为一棵DOM树；

第二步：接下来不管是内联式，外联式还是嵌入式引入的CSS样式也会被解析，渲染出另 外一棵用于渲染DOM树的树-渲染树(render tree) ，渲染树包含带有颜色，尺寸等显示属性的矩形，这些矩形的顺序与显示顺序一致；

第三步：然后就是对渲染树的每个节点进行布局处理，确定其在屏幕上的显示位置；

第四步： 就是遍历渲染树并用上一章提到的ＵＩ后端层将每一个节点绘制出来。

以上步骤是一个渐进的过程，为了提高用户体验，渲染引擎试图尽可能快的把结果显示给最终用户。它不会等到所有ＨＴＭＬ都被解析完才创建并布局渲染树。它会在从网络层获取文档内容的同时把已经接收到的局部内容先展示出来。

上面只是介绍了渲染引擎一般的处理流程，针对不同的渲染引擎具体步骤可能有所不同，就拿常见的webkit跟gecko来说吧。

首先是webkit的详细渲染流程:

火狐等浏览器的gecko渲染流程:

从上面两幅图可以看出，尽管两者使用了不同的“专业术语”，但是从图上可以看出，两者的渲染过程可谓大同小异，正是于此，我们可以再把具体的过程统一分离出来。

那么如何写出高效的css代码呢？在这个问题之前我们先来看看那些不高效的代码的书写方式：

a、使用通配符

body * {...}hide-scrollbars * {...}

b、 用标签做关键选择符

ul li a {...} #footer h3 {...} * html #atticPromo ul li a {...}

c、画蛇添足的写法

ul#top_blue_nav {...} form#UserLogin {...}

d、 给非连接标签添加 :hover 伪类，这会对用了strict doctype的页面在IE7和IE8下变的很慢。

h3:hover {...} .foo:hover {...} #foo:hover {...} div.faa :hover {...}

为什么不高效呢？

首先弄清浏览器解析html代码的过程：构建一个dom树，页面要显示的各元素都会创建到这个dom树当中。每当一个新元素加入到这个dom树当中，浏览器便会通过css引擎查遍css样式表，找到符合该元素的样式规则应用到这个元素上。css引擎查找样式表，对每条规则都按从右到左的顺序去匹配。

了解过程后，我们可以看出可以从两方面优化我们的css代码：

1，定义的css样式规则条数越少越好，所以赶紧删除css文件中不必要的样式定 义；

2，优化每条规则的选择符书写方式，尽量让css引擎一看就知道这个规则是否需要应用到当前这个元素上，让引擎少走不必要的弯路。

优化建议：

a, 避免使用通配符；

b, 让css引擎快速辨别该规则是否适用于当前元素：多用id或class选择符，少用标签选择符；

c, 不要画蛇添足把id和class或标签和class等连着写；

d, 尽量避免使用后代选择符，去除不必要的祖先元素，可以考虑使用class选择符来替换后代选择符；

/*给无序和有序的li定义不同颜色，你可能会这样写：*/ ul li {color: blue;} ol li {color: red;} /*给li添加class，这样定义效率会更高：*/ .unordered-list-item {color: blue;} .ordered-list-item {color: red;}

e, 避免给非连接标签添加 :hover 伪类。

接着还有下面几个也是需要注意的：

一，避免使用css表达式

css表达式仅在ie浏览器下才起作用，微软已在ie8后不推荐使用，因为它会严重影响页面性能：任何时候，不管任何一个事件被触发，例如窗口的 resize 事件，鼠标的移动等等，css表达式都会重新计算一遍。

二，把css文件放在页面顶部

把外联或内联样式表放在body部分会影响页面渲染的速度，因为浏览器只有在所有样式表下载完成后才会继续下载页面其他内容。另外，内联样式表（放在