为什么谷歌浏览器比其它浏览器好用？

Google Chrome的历史和指导性原则

Google Chrome最初是2008年下半年作为Windows平台上的一个beta版本发布的。Google还将自己编写的Chrome在BSD许可下进行了开源——称为Chromium。在很多人看来，这一串事件的发生颇为意外：浏览器战争要再次重启了吗？Google真的能做的更好吗？

“它非常优秀让我不得不改变主意……”。埃里克•施密特在谈到他一开始反对开发Google Chrome时这样说道。

答案是，他们能。时至今日，Chrome已经成为使用最广泛的网络浏览器（根据StatCounter的数据，市场份额超过35%），并且兼容Windows、Linux、OS X、Chrome OS多种操作系统，还包括Android和iOS等移动平台。显然，Chrome的特性和功能很对用户的胃口，其很多创新之举还被其他流行的浏览器所吸收和学习。

有一本解释Google Chrome的思想和创新的原版38页漫画书，它很好地概括了Chrome受欢迎背后的思路和设计过程。但这只是开始。最初推动着Chrome开发的那些核心原则仍然是它持续优化的指导性原则：

快速

做出最快的浏览器

安全

为用户提供最安全的环境

稳定

提供有弹性且稳定的网络应用平台

简单

技术精妙蕴含在简单的用户体验中

正如开发团队所看到的那样，我们今天所使用的很多网站都不再仅仅是网页，而是应用程序。这些越来越有野心的应用需要速度、安全和稳定。这些方面，每个都值得单独成文来介绍，不过，因为我们的主题是性能，我们将重点介绍性能。

性能的多个方面

现代浏览器是一个平台，就像你的操作系统一样，Google Chrome也遵循这样的设计理念。在Google Chrome之前，所有主流浏览器都是单进程的应用程序。所有打开的页面共享同一地址空间，争夺同一资源。任何页面或浏览器本身出现bug，整体体验都可能被破坏。

与此相反，Chrome运行于多进程模型，这种模型可以保持进程和内存的隔离性，每个标签页都能拥有一个严密的安全沙盒。随着多核架构的流行，隔绝进程并使各个打开的标签页免受其他出错页面的影响，单是这一点就能证明Chrome在浏览器的竞争中具有显著的性能优势。实际上，我们会发现绝大多数其他浏览器都纷纷效仿Chrome，或者开始转向类似的架构。

分派进程之后，一个Web程序的执行主要包括三项任务：获取资源，页面布局与呈现，以及执行JavaScript。呈现和脚本执行步骤遵循单线程、交错执行的模型——无法对所得到的DOM（文档对象模型）进行并发式的修改。原因之一是JavaScript本身就是单线程的语言。所以，无论是对于应用程序的开发者还是浏览器的开发者来说，优化呈现和脚本执行运行时的协作方式，是极其重要的。

在呈现这一步，Chrome使用的是Blink，这是一种快速、开源、遵守良好标准的布局引擎。在JavaScript这一步，Chrome自带了一个高度优化的V8 JavaScript运行时，它也作为单独开源项目发布，并已经被其他很多流行的项目所吸纳，例如Node.js的运行时。但是如果浏览器的网络连接是阻塞的（等待资源到来），那么优化V8 JavaScript执行或者Blink解析和呈现管道都不会有太大作用。

浏览器优化各项网络资源的次序、优先级和延迟的能力对整体用户体验是最关键的影响因素。你可能没有注意到，毫不夸张地说，Chrome的网络栈每天都会变得更加聪明，尝试着隐藏或减少各项资源的延迟开销：它会学习可能出现的DNS查询，会记住网络的拓扑结构，会预连接可能的目标站点，等等。从外部看来，它展示出的是一种简单的资源获取机制，但是从内部看来则是对如何优化网络性能并带给用户最佳体验的一次详细而精彩的案例学习。

让我们进入正题吧。

什么是现代Web应用？

在我们接触如何优化网络交互的具体细节之前，先来了解我们所面对的这个问题的发展趋势和背景。换句话说就是，“现代网页或者应用是什么样的？”

HTTP Archive项目记录了网络的构造过程，可以帮助我们回答这个问题。这个项目并不是为了爬取网页内容，而是周期性地爬取访问量最大的站点，记录和加总各个站点所用资源数量、内容类型、标头和其他元数据的分析数据。2013年1月的数据，可能会令你吃惊。访问量最大前30万个网络站点来看，一个页面平均：

为1280KB大小

由88个资源组成

连接15个以上不同的主机

好好琢磨一下。大小平均超过1MB，包含88个如图片、JavaScript、CSS这样的资源，从15个不同的自有和第三方主机传送出来。而且，这些数字在过去几年还在持续增长，丝毫没有减缓的迹象。这说明，我们所开发的网络应用正变得越来越大，越来越有野心。

根据HTTP Archive的数据，做个简单的算术，我们可知每个资源平均大小为15KB（1280KB/88项资源），这意味着浏览器中大多数的网络传输是短小但突发的。这就造成了一些问题，因为基础传输（TCP）是针对大型、流式下载进行优化的。让我们深入地看一看这些网络请求。

线上资源请求的生命周期

W3C的浏览时序规范（Navigation Timing specification）提供了一个浏览器API，让我们可以看到浏览器中每项请求的生命周期背后的时序和性能数据。让我们看看这些组成部分，每一块都是影响最佳用户体验的关键点：

图1.1 浏览时序图