浏览器是如何渲染页面的？

浏览器页面渲染流程

浏览器从HTTP服务器获取html文档，到呈现页面给用户，会经过以下几个步骤：

1、解析文档构建DOM树

浏览器的解析内容可以分为三个部分：

HTML/XHTML/SVG：解析这三种文件后，会生成DOM树（DOM Tree）
CSS：解析样式表，生成CSS规则树（CSS Rule Tree）
JavaScript：解析脚本，通过DOM API和CSSOM API操作DOM Tree和CSS Rule Tree，与用户进行交互。

以上三类文件的执行顺序会根据其在文档中的位置及其标签属性的不同而有异同，具体在后文进行讨论。

2、构建渲染树

解析文档完成后，浏览器引擎会将 CSS Rule Tree 附着到DOM Tree 上，并根据DOM Tree 和 CSS Rule Tree构造 Rendering Tree（渲染树）。此处需要注意：

Render Tree和DOM Tree的区别在于，类似Head或display：node之类的东西不会放在渲染树中；
将CSS Rule Tree匹配到DOM Tree需要解析CSS的选择器，为了提高该过程的性能，DOM树应该尽量小，CSS Selector应该尽量使用id和class，避免过度层叠。

3、布局与绘制渲染树

解析position, overflow, z-index等等属性，计算每一个渲染树节点的位置和大小，此过程被称为reflow。最后调用操作系统的Native GUI API完成绘制（repain）。注意：

渲染树的节点，在Gecko中称为frame，而在webkit中称为renderer；
reflow和repaint是两个不同的概念，其区别会在后文进行探讨。

脚本和样式文件对页面渲染的影响

浏览器从服务器获取文档并从上到下进行解析，在脚本文件标签不包含defer和async属性的情况下，会按照如下规则执行文档内容：

解析html文档，遇到HTML标签时，构建DOM树
在构建DOM的过程中，如果遇到外联的样式声明或脚本声明，则暂停文档解析，创建新的网络连接，开始下载样式文件和脚本文件
样式文件下载完成后，构建CSS Rule DOM，脚本文件下载完成后，解释并立即执行。
构建DOM的同时，结合CSS规则树完成页面渲染。
如果DOM树先于CSS规则树构建完成，则在CSS规则树构建完成后，页面会发生一次重绘，将新构建的CSS规则应用于渲染树。

脚本文件对文档解析的影响

在这个过程中，脚本文件的下载和执行是与文档解析同步进行的，脚本文件的下载和执行都会阻塞文档的解析，如果控制得不好，在用户体验上就会造成一定程度的影响。

举个例子，编写一个简单的html页面如下：

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>Document</title>
    <script type="text/javascript" src="defer.js"></script>
</head>
<body>
    body render!
</body>
</html>

head中加载的脚本文件内容为：

alert('i am the script');

在浏览器中运行时，会先弹出提示框，此时，body元素并没有进行渲染。

这里写图片描述

关闭弹出框以后，才完成对body的渲染：

这里写图片描述

脚本文件的defer和async属性

为了防止脚本加载使浏览器页面阻塞，妨碍用户体验。应该合理使用<script>标签的defer属性和async属性。这两个属性用于调整脚本的下载和执行顺序，使其不阻塞页面加载。

defer：开启新的线程下载脚本文件，并使脚本在文档解析完成后执行。

defer只适用于外联脚本，如果script标签没有指定src属性，只是内联脚本，不要使用defer
如果有多个声明了defer的脚本，则会按顺序下载和执行
defer脚本会在DOMContentLoaded和load事件之前执行

为了验证defer属性的相关规则，编写了如下测试代码：

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>Document</title>
    <script type="text/javascript" src="defer1.js" defer></script>
    <script type="text/javascript" src="defer2.js" defer></script>
    <script type="text/javascript" defer>
        console.log('使用了defer属性的内联js')
    </script>
</head>
<body>
    <script type="text/javascript">
        document.addEventListener("DOMContentLoaded", function() {
           console.log('DOMContentLoaded');
       }, false);

       window.addEventListener('load', function() {
           console.log('onload');
       }, false);
    </script>
</body>
</html>

defer1.js：

console.log('defer1');

defer2.js:

console.log('defer2')

控制台输出结果如下图，可以看出，对内联js脚本使用defer属性并不起作用。

这里写图片描述

async：异步下载脚本文件，下载完毕立即解释执行代码。 HTML5的新增属性。

只适用于外联脚本，这一点和defer一致
如果有多个声明async的脚本，其下载和执行都是异步的，不能确保彼此的先后顺序
async会在load事件之前执行，但并不能确保与DOMContentLoaded的执行先后顺序

为了验证async属性的特性，编写页面如下：

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>Document</title>
    <script type="text/javascript" src="async1.js" async></script>
    <script type="text/javascript" src="async2.js" async></script>
    <script type="text/javascript" async>
        console.log('使用了async属性的内联js')
    </script>
</head>
<body>
    <script type="text/javascript">
        document.addEventListener("DOMContentLoaded", function() {
           console.log('DOMContentLoaded');
       }, false);

       window.addEventListener('load', function() {
           console.log('onload');
       }, false);
    </script>
</body>
</html>

async1.js:

console.log('async1.js')

async2.js:

console.log('async2.js')

输出结果为：

这里写图片描述

下面这张图清楚的阐述了<script>脚本在无任何特殊属性、具有defer属性、具有async属性三种情况下的下载执行与文档解析的关系。其中绿色带包文档解析线程；蓝色代表脚本下载线程；红色代表脚本执行线程。

这里写图片描述

综上所述，defer属性和async属性都能防止脚本下载阻塞页面渲染。如果脚本之间没有依赖关系，可以使用async属性，如果脚本之间有依赖关系，应使用defer属性。如果同时使用async和defer属性，后者不起作用，浏览器行为由async属性决定。如果不想使用这两个属性，也可将<script>标签防止在</body>之前，达到同样的效果。

CSS对页面渲染的影响

前端页面渲染时会根据DOM结构生成一个DOM树,然后加上CSS样式生成渲染树。如果CSS文件放在<head>标签中，则CSS Rule Tree会先于DOM树完成构建，之后浏览器就可以边构建DOM树边完成渲染；反之，CSS文件放在所有页面标签之后，比如<body/>之前，那么当DOM树构建完成了，渲染树才构建，浏览器不得不再重新渲染整个页面，这样造成了资源的浪费。而且页面还可能会出现闪跳的感觉，或者白屏或者布局混乱或者样式很丑，直到CSS加载完成，页面重绘才能恢复正常。
因此，一般来讲，css标签应放在标签之间。但如果css文件较大，会让首页白屏时间更长，所以并不是说把css都放顶部是一个完美的方法。权衡利弊，应该把必须的css（js）放顶部，把不那么重要的css（js）放底部。

回流和重绘

reflow（回流）

DOM结构中的各个元素都有自己的盒子模型，浏览器根据各样式计算元素的尺寸和位置，构建渲染树的过程称之为reflow。当渲染树节点的尺寸，布局，隐藏属性发生改变时，会触发reflow操作，重新构建Render Tree。每个页面在第一次加载的时候，会发生一次回流。
完成回流后，浏览器会重新绘制受影响的部分到屏幕中，因此，回流必定会导致重绘。

repain（重绘）

当各种盒子的位置、大小以及其他属性，例如颜色、字体大小等都确定下来后，浏览器便把这些元素都按照各自的特性进行绘制，于是页面的内容出现了，这个过程称之为repaint。

会触发reflow的操作

Reflow 的成本比 Repaint 的成本高得多。DOM Tree 里的每个结点都会有 reflow 方法，一个结点的 reflow 很有可能导致子结点，甚至父点以及同级结点的 reflow。在一些高性能的电脑上也许还没什么，但是如果 reflow 发生在手机上，那么这个过程是非常痛苦和耗电的。所以，下面这些动作会触发reflow操作，有很大可能会是成本比较高的。

增加、删除、修改 DOM 结点
移动 DOM 的位置
绘制动画
修改 CSS 样式
Resize 窗口的时候或是滚动
修改网页的默认字体
注：display:none 会触发 reflow，而 visibility:hidden 只会触发 repaint，因为没有发现位置变化

如何能将Reflow对性能的影响减到最小呢？

不要一条一条地修改 DOM 的样式。与其这样，还不如预先定义好 css 的 class，然后修改 DOM 的 className，如下：

// 不好的写法
 var left = 10,
 top = 10;
 el.style.left = left + "px";
 el.style.top = top + "px";
 // 推荐写法
 el.className += " theclassname";

把 DOM 离线后修改。如: 使用 documentFragment 对象在内存里操作 DOM；先把 DOM 设置为 display:none (有一次 repaint)，然后你想怎么改就怎么改。比如修改 100 次，然后再把他显示出来；克隆一个DOM 节点到内存里，然后想怎么改就怎么改，改完后，和在线的进行交换。
千万不要使用 table 布局。因为可能很小的一个小改动会造成整个 table 的重新布局。

onload事件和DOMContentLoaded事件

DOMContentLoaded事件是当初始HTML文档完全被加载和解析（即所有的DOM完全解析）时触发的，无需要等待样式表，图片，子框架完成加载。而onload事件要等页面所有元素，包括图片以及脚本等全部加载完成才触发，因此它比DOMContentLoaded要更晚执行。
在页面的图片很多，网络不好的情况下，从用户访问到onload触发可能需要很长的时间，此时如果在onload中加入许多初始化的动作, 必然会影响用户的体验。这事使用DOMContentLoaded事件代替onload事件是更合适的。

浏览器是如何渲染页面的？

浏览器是如何渲染页面的？

浏览器页面渲染流程

1、解析文档构建DOM树

2、构建渲染树

3、布局与绘制渲染树

脚本和样式文件对页面渲染的影响

脚本文件对文档解析的影响

脚本文件的defer和async属性

CSS对页面渲染的影响

回流和重绘

reflow（回流）

repain（重绘）

会触发reflow的操作

onload事件和DOMContentLoaded事件

如何优化图片的加载

如何提高首屏加载速度