页面渲染深刻解析

基本渲染过程

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

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

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

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

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

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

不一样渲染引擎具体不一样的渲染流程

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

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

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

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

优化css部分

那么如何写出高效的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部分会影响页面渲染的速度，由于浏览器只有在全部样式表下载完成后才会继续下载页面其余内容。另外，内联样式表（放在<style>内的样式）有可能会引发页面从新渲染或显示隐藏页面中的某些元素，建议不要使用内联样式表。

三，指定页面图片的尺寸

指定页面图片尺寸，要符合图片的真实尺寸（不要经过指定尺寸来缩放图片），能够避免尺寸改变致使的页面结构效果的变化，因此对加快页面渲染速度有益。

四，页面头部标明文档编码

HTML文档是以包含文档编码信息的数据流方式在网络间传输。页面的编码信息通常会在HTTP响应的头部信息或在文档内的HTML标记中指明。客户端浏览器只有在肯定了页面编码后才能正确的渲染页面， 因此在绘制页面或执行任何的javascript代码前，大部分的浏览器（ie六、ie七、ie8除外）都会缓冲必定字节的数据来从中查找编码信息，不一样 的浏览器当中预缓冲的字节数是不同的。若是浏览器在接收到了设定的预缓冲数据量后尚未找到页面的编码信息，便会根据各自指定的默认编码开始渲染页面，若是这时再获取到页面编码信息，而又跟如今所用编码不一致，那整个页面就得从新渲染，某些状况下甚至须要从新获取数据。因此，对于大小超过1KB的页面（根据在各浏览器的测试状况，预缓冲数据量最多的也就1KB）应当尽早标明编码信息。

浏览器加载和渲染html的顺序（摘抄）

1.浏览器加载和渲染html的顺序

一、IE下载的顺序是从上到下，渲染的顺序也是从上到下，下载和渲染是同时进行的。

二、在渲染到页面的某一部分时，其上面的全部部分都已经下载完成（并非说全部相关联的元素都已经下载完）

三、若是遇到语义解释性的标签嵌入文件（JS脚本，CSS样式），那么此时IE的下载过程会启用单独链接进行下载。

四、而且在下载后进行解析，解析过程当中，中止页面全部往下元素的下载。阻塞加载

五、样式表在下载完成后，将和之前下载的全部样式表一块儿进行解析，解析完成后，将对此前全部元素（含之前已经渲染的）从新进行渲染。

六、JS、CSS中若有重定义，后定义函数将覆盖前定义函数

2. JS的加载

2.1 不能并行下载和解析（阻塞下载）

2.2 当引用了JS的时候，浏览器发送1个js request就会一直等待该request的返回。由于浏览器须要1个稳定的DOM树结构，而JS中颇有可能有代码直接改变了DOM树结构，好比使用 document.write 或 appendChild,甚至是直接使用的location.href进行跳转，浏览器为了防止出现JS修改DOM树，须要从新构建DOM树的状况，因此 就会阻塞其余的下载和呈现.

3.如何加快HTML页面加载速度

1，页面减肥 

页面的肥瘦是影响加载速度最重要的因素 

删除没必要要的空格、注释 

将inline的script和css移到外部文件 

可使用HTML Tidy来给HTML减肥，还可使用一些压缩工具来给JavaScript减肥 

2，减小文件数量 

减小页面上引用的文件数量能够减小HTTP链接数 

许多JavaScript、CSS文件能够合并最好合并，人家财帮子都把本身的JavaScript. functions和Prototype.js合并到一个base.js文件里去了 

3，减小域名查询 

DNS查询和解析域名也是消耗时间的，因此要减小对外部JavaScript、CSS、图片等资源的引用，不一样域名的使用越少越好 

4，缓存重用数据 

使用缓存吧 

5，优化页面元素加载顺序 

首先加载页面最初显示的内容和与之相关的JavaScript和CSS 

而后加载DHTML相关的东西 

像什么不是最初显示相关的图片、flash、视频等很肥的资源就最后加载 

6，减小inline JavaScript的数量 

浏览器parser会假设inline JavaScript会改变页面结构，因此使用inline JavaScript开销较大 

不要使用document.write()这种输出内容的方法，使用现代W3C DOM方法来为现代浏览器处理页面内容 

7，使用现代CSS和合法的标签 

使用现代CSS来减小标签和图像，例如使用现代CSS+文字彻底能够替代一些只有文字的图片 

使用合法的标签避免浏览器解析HTML时作“error correction”等操做，还能够被HTML Tidy来给HTML减肥 

8，Chunk your content 

不要使用嵌套tables 

<table>
  <table>
    <table>
      ..
    <table>
  <table>
<table>

而使用非嵌套tables或者divs 

<table>...</table>
<table>...</table>
<table>...</table>

将基于大块嵌套的tables的layout分解成小tables，这样显示时不用加载整个页面(或大table)的内容 

9，指定图像和tables的大小 

若是浏览器能够当即决定图像或tables的大小，那么它就能够立刻显示页面而不要从新作一些布局安排的工做 

这不只加快了页面的显示，也预防了页面完成加载后布局的一些不当的改变 

image使用height和width 

table使用table-layout: fixed并使用col和colgroup标签指定columns的width 

10，根据用户浏览器明智的选择策略 

IE、Firefox、Safari等等等等 

11，页面结构的例子 

· HTML
    · HEAD 
        · LINK ...
        CSS files required for page appearance. Minimize the number of files for performance while keeping unrelated CSS in separate files for maintenance. 
        · SCRIPT. ...
        JavaScript. files for functions required during the loading of the page, but not any DHTML that can only run after page loads. 
        Minimize the number of files for performance while keeping unrelated JavaScript. in separate files for maintenance. 
    · BODY 
    · User visible page content in small chunks (tables / divs) that can be displayed without waiting for the full page to download. 
        · SCRIPT. ...
        Any scripts which will be used to perform. DHTML. DHTML script. typically can only run after the page has completely loaded and all necessary objects have been initialized. There is no need to load these scripts before the page content. That only slows down the initial appearance of the page load. 
        Minimize the number of files for performance while keeping unrelated JavaScript. in separate files for maintenance. 
        If any images are used for rollover effects, you should preload them here after the page content has downloaded.

4.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文件，从新渲染页面。 

英文版：http://developer.yahoo.com/performance/rules.html

中文翻译：http://www.cnblogs.com/smjack/archive/2009/02/24/1396895.html

原文连接：http://renyongjie668.blog.163.com/blog/static/1600531201097062789/