我们每天都会浏览很多的Web页面，使用很多基于Web的应用。这些站点看起来既不一样，用途也都各有不同，有在线视频，Social Media，新闻，邮件客户端，在线存储，甚至图形编辑，地理信息系统等等。虽然有着各种各样的不同，但是相同的是，他们背后的工作原理都是一样的：

• 用户输入网址
• 浏览器加载HTML/CSS/JS，图片资源等
• 浏览器将结果绘制成图形
• 用户通过鼠标，键盘等与页面交互

这些种类繁多的页面，在用户体验方面也有很大差异：有的响应很快，用户很容易就可以完成自己想要做的事情；有的则慢慢吞吞，让焦躁的用户在受挫之后拂袖而去。毫无疑问，性能是影响用户体验的一个非常重要的因素，而影响性能的因素非常非常多，从用户输入网址，到用户最终看到结果，需要有很多的参与方共同努力。这些参与方中任何一个环节的性能都会影响到用户体验。

• 宽带网速
• DNS服务器的响应速度
• 服务器的处理能力
• 数据库性能
• 路由转发
• 浏览器处理能力

早在2006年，雅虎就发布了提升站点性能的指南，Google也发布了类似的指南。而且有很多工具可以和浏览器一起工作，对你的Web页面的加载速度进行评估：分析页面中资源的数量，传输是否采用了压缩，JS、CSS是否进行了精简，有没有合理的使用缓存等等。

如果你需要将这个过程与CI集成在一起，来对应用的性能进行监控，我去年写过一篇相关的博客。

本文打算从另一个角度来尝试加速页面的渲染：浏览器是如何工作的，要将一个页面渲染成用户可以看到的图形，浏览器都需要做什么，哪些过程比较耗时，以及如何避免这些过程（或者至少以更高效的方式）。

页面是如何被渲染的

说到性能优化，规则一就是：

If you can’t measure it, you can’t improve it. - Peter Drucker

根据浏览器的工作原理，我们可以分别对各个阶段进行度量。

图片来源：http://dietjs.com/tutorials/host#backend

像素渲染流水线

1. 下载HTML文档
2. 解析HTML文档，生成DOM
3. 下载文档中引用的CSS、JS
4. 解析CSS样式表，生成CSSOM
5. 将JS代码交给JS引擎执行
6. 合并DOM和CSSOM，生成Render Tree
7. 根据Render Tree进行布局layout（为每个元素计算尺寸和位置信息）
8. 绘制（Paint）每个层中的元素（绘制每个瓦片，瓦片这个词与GIS中的瓦片含义相同）
9. 执行图层合并（Composite Layers）

使用Chrome的DevTools - Timing，可以很容易的获取一个页面的渲染情况，比如在Event Log页签上，我们可以看到每个阶段的耗时细节（清晰起见，我没有显示Loading和Scripting的耗时）：

上图中的Activity中，Recalculate Style就是上面的构建CSSOM的过程，其余Activity都分别于上述的过程匹配。

应该注意的是，浏览器可能会将Render Tree分成好几个层来分别绘制，最后再合并起来形成最终的结果，这个过程一般发生在GPU中。

Devtools中有一个选项：Rendering - Layers Borders，打开这个选项之后，你可以看到每个层，每个瓦片的边界。浏览器可能会启动多个线程来绘制不同的层/瓦片。

Chrome还提供一个Paint Profiler的高级功能，在Event Log中选择一个Paint，然后点击右侧的Paint Profiler就可以看到其中绘制的全过程：

你可以拖动滑块来看到随着时间的前进，页面上元素被逐步绘制出来了。我录制了一个我的知乎活动页面的视频，不过需要翻墙。

常规策略

为了尽快的让用户看到页面内容，我们需要快速的完成DOM+CSSOM - Layout - Paint - Composite Layers的整个过程。一切会阻塞DOM生成，阻塞CSSOM生成的动作都应该尽可能消除，或者延迟。

在这个前提下，常见的做法有两种：

分割CSS

对于不同的浏览终端，同一终端的不同模式，我们可能会提供不同的规则集：

@media print {
	html {
		font-family: 'Open Sans';
		font-size: 12px;
	}
}

@media orientation:landscape {
	//
}

如果将这些内容写到统一个文件中，浏览器需要下载并解析这些内容（虽然不会实际应用这些规则）。更好的做法是，将这些内容通过对link元素的media属性来指定：

<link href="print.css" rel="stylesheet" media="print">
<link href="landscape.css" rel="stylesheet" media="orientation:landscape">

这样，print.css和landscape.css的内容不会阻塞Render Tree的建立，用户可以更快的看到页面，从而获得更好的体验。

高效的CSS规则

CSS规则的优先级

很多使用SASS/LESS的开发人员，太过分的喜爱嵌套规则的特性，这可能会导致复杂的、无必要深层次的规则，比如：

#container {
	p {
		.title {
			span {
				color: #f3f3f3;
			}
		}
	}
}

在生成的CSS中，可以看到：

#container p .title span {
  color: #f3f3f3;
}

而这个层次可能并非必要。CSS规则越复杂，在构建Render Tree时，浏览器花费的时间越长。CSS规则有自己的优先级，不同的写法对效率也会有影响，特别是当规则很多的时候。这里有一篇关于CSS规则优先级的文章可供参考。

使用GPU加速

很多动画都会定时执行，每次执行都可能会导致浏览器的重新布局，比如：

@keyframes my {
	20% {
		top: 10px;
	}
	
	50% {
		top: 120px;
	}
	
	80% {
		top: 10px;
	}
}

这些内容可以放到GPU加速执行（GPU是专门设计来进行图形处理的，在图形处理上，比CPU要高效很多）。可以通过使用transform来启动这一特性：

@keyframes my {
	20% {
		transform: translateY(10px);
	}

	50% {
		transform: translateY(120px);
	}
		
	80% {
		transform: translateY(10px);
	}
}

异步JavaScript

我们知道，JavaScript的执行会阻塞DOM的构建过程，这是因为JavaScript中可能会有DOM操作：

var element = document.createElement('div');
element.style.width = '200px';
element.style.color = 'blue';

body.appendChild(element);

因此浏览器会等等待JS引擎的执行，执行结束之后，再恢复DOM的构建。但是并不是所有的JavaScript都会设计DOM操作，比如审计信息，WebWorker等，对于这些脚本，我们可以显式地指定该脚本是不阻塞DOM渲染的。

<script src="worker.js" async></script>

带有async标记的脚本，浏览器仍然会下载它，并在合适的时机执行，但是不会影响DOM树的构建过程。

首次渲染之后

在首次渲染之后，页面上的元素还可能被不断的重新布局，重新绘制。如果处理不当，这些动作可能会产生性能问题，产生不好的用户体验。

• 访问元素的某些属性
• 通过JavaScript修改元素的CSS属性
• 在onScroll中做耗时任务
• 图片的预处理（事先裁剪图片，而不是依赖浏览器在布局时的缩放）
• 在其他Event Handler中做耗时任务
• 过多的动画
• 过多的数据处理（可以考虑放入WebWorker内执行）

强制同步布局/回流

元素的一些属性和方法，当在被访问或者被调用的时候，会触发浏览器的布局动作（以及后续的Paint动作），而布局基本上都会波及页面上的所有元素。当页面元素比较多的时候，布局和绘制都会花费比较大。

通过Timeline，有时候你会看到这样的警告：

比如访问一个元素的offsetWidth（布局宽度）属性时，浏览器需要重新计算（重新布局），然后才能返回最新的值。如果这个动作发生在一个很大的循环中，那么浏览器就不得不进行多次的重新布局，这可能会产生严重的性能问题：

for(var i = 0; i < list.length; i++) {
	list[i].style.width = parent.offsetWidth + 'px';
}

正确的做法是，先将这个值读出来，然后缓存在一个变量上（触发一次重新布局），以便后续使用：

var parentWidth = parent.offsetWidth;
for(var i = 0; i < list.length; i++) {
	list[i].style.width = parentWidth + 'px';
}

这里有一个完整的列表触发布局。

CSS样式修改

布局相关属性修改

修改布局相关属性，会触发Layout - Paint - Composite Layers，比如对位置，尺寸信息的修改：

var element = document.querySelector('#id');
element.style.width = '100px';
element.style.height = '100px';

element.style.top = '20px';
element.style.left = '20px';

绘制相关属性修改

修改绘制相关属性，不会触发Layout，但是会触发后续的Paint - Composite Layers，比如对背景色，前景色的修改：

var element = document.querySelector('#id');
element.style.backgroundColor = 'red';

其他属性

除了上边的两种之外，有一些特别的属性可以在不同的层中单独绘制，然后再合并图层。对这种属性的访问（如果正确使用了CSS）不会触发Layout - Paint，而是直接进行Compsite Layers:

• transform
• opacity

transform展开的话又分为: translate, scale, rotate等，这些层应该放入单独的渲染层中，为了对这个元素创建一个独立的渲染层，你必须提升该元素。

可以通过这样的方式来提升该元素：

.element {
  will-change: transform;
}

CSS 属性 will-change 为web开发者提供了一种告知浏览器该元素会有哪些变化的方法，这样浏览器可以在元素属性真正发生变化之前提前做好对应的优化准备工作。

当然，额外的层次并不是没有代价的。太多的独立渲染层，虽然缩减了Paint的时间，但是增加了Composite Layers的时间，因此需要仔细权衡。在作调整之前，需要Timeline的运行结果来做支持。

还记得性能优化的规则一吗？

If you can’t measure it, you can’t improve it. - Peter Drucker

下面这个视频里可以看到，当鼠标挪动到特定元素时，由于CSS样式的变化，元素会被重新绘制：

CSS Triggers是一个完整的CSS属性列表，其中包含了会影响布局或者绘制的CSS属性，以及在不同的浏览器上的不同表现。

总结

了解浏览器的工作方式，对我们做前端页面渲染性能的分析和优化都非常有帮助。为了高效而智能的完成渲染，浏览器也在不断的进行优化，比如资源的预加载，更好的利用GPU（启用更多的线程来渲染）等等。

另一方面，我们在编写前端的HTML、JS、CSS时，也需要考虑浏览器的现状：如何减少DOM、CSSOM的构建时间，如何将耗时任务放在单独的线程中（通过WebWorker）。

参考资料

• Google出品的Web基础
• 一篇关于如何优化CSS的文章
• CSSOM的介绍

目前的Web前端的现状较之5-6年前，简直不能同日而语：从所使用的技术、工具、框架到开发一个产品所需要付出的工作量，从前端开发从业人员的数量到Web应用的数量，从企业对于Web前端的重要程度的认识到Web实际上为企业带来的回报，一切都有了翻天覆地的变化。

借助HTML5+CSS3的普及，加上一些开箱即用的CSS框架（如bootstrap，foundation等）支持，人们已经可以非常容易的从零开始搭建一个Web应用的前端。一个在UI方面非常业余的程序员也可以很快的做出一个像模像样的用户界面。而另一方面，基于操作系统原生API，要想设计并实现一个桌面应用，需要的付出则远远超过超过同水平的Web界面。

webkit浏览器内核

Webkit作为最受欢迎的浏览器内核，自然有非常多的port。比如GTK+对它的port – WebkitGTK，以及构建在WebkitGTK之上的Python的bind。使用WebkitGTK的Python版本，开发人员可以用HTML+CSS来开发应用，然后写一点Python脚本，最后将其运行在桌面上。

这里有个早期的例子来教你如何写一个所见即所得的编辑器。桌面应用开发中，对于用户界面的复杂性一直是一个难题，而这种方式可以减轻很多的用户界面开发的复杂性，将界面开发交给另外更加灵活，更加容易编写和调试方式：HTML+CSS。

这种模式下基本的开发流程是编写一个HTML页面（作为程序入口），然后在这个页面上引入额外的CSS（界面风格）和JavaScript（动作），然后将这些资源交给工业级浏览器内核Webkit来渲染 – 这个过程和在浏览器中访问该文件并无二致，但是有两个额外的好处：

1. 页面运行在一个“桌面应用程序”中
2. 没有地址栏，状态栏，菜单栏等，看起来更像是一个桌面应用
3. 用户界面开发的复杂性被“外包”给一个更简单的环境

这就是传说中的混合（hybrid）开发模式，比如现在移动开发中的cordova就是采用这种模式，使得本来被视为天堑的原生的用户界面开发变为坦途。

node-webkit

node-webkit是一个基于chromium和node.js的应用程序开发工具。它不但支持你使用传统的HTML5+CSS3+JS方式来开发你的应用程序，还支持无缝的与Node.js集成，也就是说，所有的Node支持的与操作系统交互的功能，如网络连接，文件系统，操作系统资源访问等，以及Node之上的第三方库都可以在node-webkit中进行使用。

更好的是，node-webkit是一个跨平台的工具，你可以使用它构建出运行在Mac OS，Linux以及Windows下的应用程序。应用程序通过Node.js来进行与系统相关的访问，而用HTML5+CSS3进行用户界面部分的设计。

node-webkit未必是未来桌面应用的唯一方式，但是却是一个非常好的选择，特别对于已经熟知Web前端开发技术栈的众多开发者来说，无需学习一门新的语言，一切都被很大程度的简化了。

第一个node-webkit应用程序

开发node-webkit应用程序非常简单。在这里下载系统对应的版本。并确保对应的二进制文件(nwnw.exe)在系统的PATH之中。

创建一个新的目录，然后在该目录中创建一个package.json文件和一个index.html文件：

$ mkdir -p hello-node-webkit
$ cd hello-node-webkit
$ touch package.json index.html

package.json文件的内容如下：

{
    "name": "hello-node-webkit",
    "version": "0.1.0",
    "main": "index.html"
}

index.html文件的内容如下：

<html>
<head>
	<title>Hello node-webkit</title>
</head>
<body>
	<div>
		<h1>Hello node-webkit</h1>
	</div>
</body>
</html>

然后将这两个文件打在一个zip格式压缩包中：

$ zip -r hello-node-webkit.zip *

然后将这个文件重命名为hello-node-webkit.nw，最后使用node-webkit来启动这个应用程序。

$  ~/Tools/node-webkit.app/Contents/MacOS/node-webkit hello-node-webkit.nw

添加外部JS/CSS

接下来我们为这个页面添加一些外部的引用：CSS/JavaScript文件。首先创建两个目录style和script，然后分别创建文件如下：

├── index.html
├── package.json
├── script
│   ├── app.js
│   └── jquery.min.js
└── style
    └── style.css

其中，style.css定义了h1的简单样式：

h1 {
	font-size: 20px;
	color: #999999;
}

而app.js则注册了一个简单的事件处理器：

$(function() {
	$("h1").on("click", function() {
		alert("Heading 1 is clicked");
	});
});

此时的index.html修改如下：

<html>
<head>
	<title>Hello node-webkit</title>
	<link rel="stylesheet" type="text/css" href="style/style.css">
</head>
<body>
	<div>
		<h1>Hello node-webkit</h1>
	</div>
	<script type="text/javascript" src="script/jquery.min.js"></script>
	<script type="text/javascript" src="script/app.js"></script>
</body>
</html>

还是按照上一小节的命令完成打包，改名，启动之后。点击h1元素时，会弹出对话框如下：

在这个例子中，我们使用了外部的css文件来添加样式，还引入了jQuery作为访问DOM元素的工具，最后还使用了一段调用jQuery的JavaScript代码。

构建脚本

你可能已经注意到了，使用node-webkit开发非常方便。但是这一系列的动作（修改HTML+CSS，压缩打包，改名，启动）等有一部分重复工作，我们可以将其自动化。

好在已经有了一个很好用的grunt的插件：grunt-node-webkit-builder，这个插件可以帮助我们自动执行压缩打包这些动作。

$ npm install grunt-node-webkit-builder

然后定义一个Gruntfile.js，这个文件中指定源文件（所有的HTML，JavaScript代码，CSS文件）所在目录，目标文件所在目录，需要构建的应用程序指定的操作系统平台等：

module.exports = function(grunt) {
    grunt.initConfig({
        pkg: grunt.file.readJSON('package.json'),
        nodewebkit: {
            options: {
                platforms: ['osx'],
                buildDir: 'builds',
            },
            src: ['app/**/*']
        },

    });

    grunt.loadNpmTasks('grunt-node-webkit-builder');
    grunt.registerTask('default', ['nodewebkit']);
};

这样，我们修改之后，就可以很简单的执行：

$ grunt

来进行打包了。比如在Mac下，构建出来的应用位于builds/<app-name>/osx目录下，要启动该应用只需要在命令行输入

$ open builds/hello-node-webkit/osx/hello-node-webkit.app

或者在Finder中双击打开即可。

可以看到上例中的应用程序还有浓重的浏览器痕迹，比如地址栏，刷新按钮，甚至还有一个DevTools的按钮。我们可以通过修改package.json来指定：

{
    "name": "hello-node-webkit",
    "version": "0.1.0",
    "main": "index.html",
    "window": {
        "toolbar": false,
        "width": 800,
        "height": 600
    }
}

这样的界面就更像是一个桌面应用了：

到目前为止，这个小的应用程序并没有什么有趣的特性，用户界面也毫无美感，但是有了这些基本知识和工具之后，我们就可以开始更进一步的开发。除了使用既有的CSS框架来完成用户界面的美化，我们还会使用node.js访问系统资源来构建真实的应用程序。