当提到前端性能优化时，我们首先会联想到文件的合并，压缩，文件缓存和开启服务端的gzip压缩等，这使得页面加载更快，用户可以尽快使用我们的Web应用来达到他们的目标。 资源预加载是另一个性能优化技术，我们可以使用该技术来预先告知浏览器某些资源可能在将来会被使用。 以前这种实践被称为prebrowsing。但这并不是一种单一的技术，实际上可以拆分成很多小点：dns-prefetch, subresource, prefetch, preconnect和prerender

例如，我们将来可能从example.com获取图片或者音频资源，那么可以在文档顶部的标签加入以下内容：

用法如下：

现在浏览器都试着预测网站将来需要哪些 连接，然后预先建立socket连接，从而消除昂贵的DNS查找，TCP握手和TLS往返开销。然而，浏览器还不够聪明，并不能准确准确预测每个网站的所有预链接目标。好在，在firefox 39 和chrome 46 中我们可以使用Preconect告诉浏览器我们需要进行哪些预链接。

如果我们确定某个资源将来一定会使用到，我们可以让浏览器先请求该资源并放入浏览器缓存中。与DNS预解析不同，预获取真正请求并下载了资源，并储存在缓存中。 例如，一个图片和脚本或任何可以被浏览器缓存的资源：

然而，预获取还依赖于一些条件，某些预获取可能会被浏览器忽略，例如从一个非常缓慢的网络中获取一个庞大的字体文件。并且，Firefox只会在浏览器闲置时进行资源预获取。 预获取对webfonts性能提升非常明显。目前，字体文件必须等到DOM和CSS构建完成之后才开始下载，使用预获取就可以轻松绕过该瓶颈。 注意：要测试资源的预获取有点困难，但在Chrome和Firefox的网络面板中都有资源预获取的记录，还需要记住，预获取的资源没有同源策略的限制。

rel=prefetch 为将来的页面提供了一种低优先级的资源预加载方式 rel=subresource 为当前页面提供了一种高优先级的资源预加载

所在，如果资源是当前页面必须的，或者资源需要尽快可用，那么最好使用subresource而不是prefetch

预渲染类似于在一个隐藏的 tab 页中打开了某个链接 – 将下载所有资源、创建 DOM 结构、完成页面布局、应用 CSS 样式和执行 JavaScript 脚本等。当用户真正访问该链接时，隐藏的页面就切换为可见，使页面看起来就是瞬间加载完成一样。

用法如下：

这是一个核武器，因为prerender 可以预先加载文档的所有资源。Google 搜索在其即时搜索页面中已经应用该技术多年了，微软也宣称将在 IE11 中支持该特性。

需要注意的是不要滥用该特性，当你知道用户一定会点击某个链接时才可以进行预渲染，否则浏览器将无条件地下载所有预渲染需要的资源。

Preload 是一个新规范，该规范还没有被所有浏览器兼容。 Preload 建议允许始终预加载某些资源，不像Prefetch有可能被浏览器忽略，浏览器必须请求Preload标记的资源。

用法如下：