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

优化冷启动体验

当你第一次加载浏览器时，它对你的喜爱站点和浏览模式一无所知。但是，我们中的很多人都会在浏览器冷启动后做同样的事：我们会浏览我们的电邮收件箱、喜爱的新闻站点、社交网站、内网入口等等。具体的站点可能因人而异，但是这些会话的相似之处使Chrome的Predictor可以加速你的冷启动过程。

Chrome会记住用户在浏览器启动后前10个最有可能访问的主机名——注意这并不是前10个全局目标站点，而特指全新开启浏览器之后的目标站点。浏览器加载时，Chrome可以为这些可能的目标站点触发DNS预获取行为。如果你对此感兴趣，可以打开一个新标签页浏览地址chrome://dns，看一看你自己的启动主机名列表。在页面顶端，你会找到你profile的前10个最可能启动站点。

图1.5 启动DNS

图1.5的截图是我的Chrome profile的例子。我通常是如何开始浏览的呢，如果我在写文章，比如现在这一篇，可能会频繁访问Google Docs。果不其然，我们在列表中看到很多Google的主机名。

使用Omnibox优化交互过程

Chrome的创新之一是引入了Omnibox，它与此前的地址栏不同，可以处理目标站点URL之外的很多东西。除了记住用户曾经访问过的页面的URL之外，它还提供完整的对历史记录的文本检索功能，与你所选择的搜索引擎的集成性也较好。

随着用户在其中键入内容，Omnibox会自动提供建议的行为，可能是基于你的浏览历史的URL或者是一次检索查询。在后台，每个建议行为都根据查询结果和历史表现进行评分。实际上，Chrome允许我们通过访问chrome://predictors来查看这些数据。

图1.6 Omnibox的URL预测

Chrome会维护用户输入前缀、建议行为以及每一记录的命中率的历史记录。在我的profile中，你可以看到当我在Omnibox中输入“g”时，有76%的可能性我是要访问Gmail。而当我加了一个“m”之后（变成“gm”），则置信水平上升到99.8%，实际上，在记录的412次访问中，我只有一次在输入“gm”之后没有访问Gmail。

这与网络栈有什么关系呢？可能备选站点中黄色和绿色的记录也是ResourceDispatcher的重要信号。如果我们有一个可能的备选站点（黄色），Chrome可能为该目标主机触发DNS预获取。如果我们有一个高度确信的备选站点（绿色），那么Chrome可能还会在主机名解析之后触发TCP预连接。最后，如果这两步都做完时用户还没做出最终决定，那么Chrome甚至可能在隐藏的标签页中预呈现整个页面。

另一方面，如果根据过去的浏览历史没有为所输入的前缀找到较好的匹配，那么Chrome预计可能会发生检索请求，会向你的搜索引擎发起DNS预获取和TCP预连接。

一个普通用户需要花费数百毫秒来填写查询内容，评价所给出的自动补全建议。在后台，Chrome能够预获取、预连接，并在某些情况下对页面进行预呈现，这样当用户准备好按下“输入”键时，很多网络延迟已经被消除了。

优化缓存性能

最好最快的请求是不发出请求。当我们说到性能时必然会涉及缓存的问题——你正在为你网页上的所有资源提供Expires、ETag、Last-Modified和Cache-Control这些响应标头，对吧？如果你没有这样做，请立刻去改。我们会等你。

Chrome的内部缓存有两种不同的实现方式：一种是由本地磁盘所支持，另一种是把所有内容存储在内存中。内存实现方式用于匿名浏览模式，当你关闭窗口后会把痕迹清除干净。两种方式都实现相同的内部接口（disk_cache:Backend和disk_cache:Entry），这极大地简化了架构并且——如果你非要坚持的话——允许你很方便地试验你自己的缓存实现。

内部来看，磁盘缓存实现了其自己的数据结构，它们都被存储在你的profile的一个单独的缓存文件夹中。这个文件夹中有索引文件，它们在浏览器启动时进行内存映射，还有数据文件，它们存储了实际数据以及HTTP标头和其他簿记信息【注4】。最后，在缓存回收机制上，磁盘缓存会维护一个最近最少使用（LRU）缓存，它会把访问频度和资源新旧度等排序量化指标考虑进去。

如果你对Chrome的缓存状态很感兴趣，可以打开新标签页访问chrome://net-internals/#httpCache。或者，如果你想看看真实的HTTP元数据以及缓存的响应，也可以访问chrome://cache，其中列示了缓存中当前可用的所有资源。在该页面中，检索一项资源之后可以点击URL查看缓存的标头和响应的具体字节内容。

使用预获取优化DNS

我们已经在一些地方提到过DNS预解析，所以在我们深入介绍它的实现方式之前，先回忆一下哪些情况下为什么会触发它：

运行在呈现进程中的Blink文档解析器，可以提供当前页面上所有链接的主机名清单，Chrome可以从中选择提前解析。

呈现进程会将鼠标悬停和“按下按键”事件作为用户意图进行浏览的前期信号，从而触发预解析。

Omnibox根据高度可能的建议，可能触发解析请求。

Predictor基于过去的浏览和资源请求数据，可能请求主机名解析。

页面所有者可能明确指示Chrome应该预解析哪些主机名。

所有情况下，DNS预解析都被作为提示来处理。Chrome并不保证预解析必然进行，而是综合运用各个信号与其自身的预测器来评估这条提示并动态决策。在“最坏情况”下，如果Chrome未能及时完成主机名预解析，用户就要等待显式DNS解析，接着是TCP连接时间，最后是实际资源获取。但是，如果出现了这种情况，预测器会进行记录并相应调整其未来决策——随着你的持续使用，它会变得更快更聪明。

我们此前没有提到的一项优化是Chrome能够学习每个站点的拓扑结构，并运用这项信息来加速未来的访问过程。具体而言，回忆一下，一个页面平均由88项资源组成，由15个以上不同的主机发送。每一次你进行浏览，Chrome会记录页面上的热门资源的主机名，在以后的访问中，它可能会对其中一些或全部选择触发DNS预解析甚至TCP预连接。

访问chrome://dns并检索你profile对应的热门站点主机名，可以查看Chrome所保存下来的子资源主机名。在上面的例子中，你可以看到Chrome记录了Google+的6个子资源主机名，还统计了DNS预解析触发或TCP预连接执行的次数，还有会由各项处理的请求的估计值。这些内部记录帮助Chrome预测器实现优化。

除了这些内部信号之外，站点的所有者也能在页面中嵌入附加的标记请求浏览器预解析一个主机名：