当我们谈到前端的性能时，总是会提到比如合并、压缩、缓存或者在服务器上开启gzip之类的，目的都是为了让页面加载的更快。
资源预拉取（prefetch）则是另一种性能优化的技术。通过预拉取可以告诉浏览器用户在未来可能用到哪些资源。
Pre-fetching会提示浏览器那些未来一定或可能使用到的资源，有时在当前页面见效，有些则在未来可能打开的页面生效。 作为开发者，我们比浏览器更懂自己的应用。我们可以利用这些技术提前告知浏览器web中用到的核心资源。
以前这种实践也被称为『prebrowsing』。但这并不是一种单一的技术，实际上可以拆分成很多小点：dns-prefetch, subresource, prefetch, preconnect, 和 prerender.
DNS prefetching通过指定具体的URL来告知客户端未来会用到相关的资源，这样浏览器可以尽早的解析DNS。比如我们需要一个在example.com的图片或者视频文件。在<head>就可以这么写：
| 1 |
<linkrel="dns-prefetch"href="//example.com"> |
当请求这个域名下的文件时就不需要等待DNS查询了。项目中有用到第三方的代码时这么做尤其有益（其他的使用场景，比如当静态资源和HTML不在一个域上，而在CDN上；又比如在重定向前可以加上DNS prefetch）。
Harry Roberts在他的前端性能优化文章中建议：
简单的一行就能让支持的浏览器提前解析DNS。也就是说在浏览器请求资源时，DNS查询就已经准备好了。
这可能看起来是个非常微不足道的性能提升，而且还不是必须的–Chrome总是会做类似的处理，用户只要在地址栏敲入一部分域名，如果命中了历史常用的网站，Chrome就会提前解析DNS、预拉取页面。（效果确实有限，但是聊胜于无）
和DNS prefetch类似，preconnect不光会解析DNS，还会建立TCP握手连接和TLS协议（如果需要）。用法如下：
| 1 |
<linkrel="preconnect"href="http://css-tricks.com"> |
Ilya Grigorik写了一篇文章详细说明了这种技术：
现代浏览器竭尽所能的尝试预测网站可能需要哪些链接。通过提前连接，浏览器可以提前建立必要的通信，消除了实际请求中DNS、TCP和TLS的耗时。不过，即使是只能的现代浏览器，也没办法为每个网站可靠的预测所有连接。
幸运的是开发者可以告诉浏览器哪些通信需要在实际请求发起前就提前建立连接。
举个栗子： 
上半张图显示了浏览器先拉html、再拉CSS并建立好CSSOM后，发现需要两个外链的字体（在fonts.gstatic.com上）,然后浏览器开始发起两个请求，具体来说，需要对这个域进行DNS解析、TCP和TLS握手（一个建立后可以复用给另一个连接）。
| 1 2 |
<linkhref='https://fonts.gstatic.com'rel='preconnect'crossorigin> <linkhref='https://fonts.googleapis.com/css?family=Roboto+Slab:700|Open+Sans'rel='stylesheet'> |
下半张图增加了上面的代码来从fonts.gstatic.com preconnect资源。可以看到，浏览器在请求CSS的同时并行的建立字体资源需要的连接，等到真正开始需要字体时立刻就开始返回数据。
更多详细的内容可以参考Ilya Grigorik的文章。
目前只支持Firefox 39+和Chrome 46+，具体参见caniuse
当能确定网页在未来一定会使用到某个资源时，开发者可以让浏览器提前请求并且缓存好以供后续使用。prefetch支持预拉取图片、脚本或者任何可以被浏览器缓存的资源。
| 1 |
<linkrel="prefetch"href="image.png"> |
不同于DNS prefetch，上面的写法可是会去请求、下载资源并且缓存起来。当然也是有一些发生条件的。比如，客户端可能会在弱网络下不去请求较大的字体文件，Firefox则只会在浏览器空闲的时候prefetch资源（译者注：这里是MDN上对浏览器空闲的定义和一些FAQ，建议阅读）。
正如Bram Stein在他的文章中指出，prefetch很适用于优化webfonts的性能。以前，字体文件必须等DOM和CSSOM创建好后才能下载，可如果prefetch了字体，这个瓶颈就能轻松解决了。
注意：prefetch并没有同域的限制
subresource可以用来指定资源是最高优先级的。比如，在Chrome和Opera中我们可以加上下面的代码：
| 1 |
<linkrel="subresource"href="styles.css"> |
Chromium的文档这么解释：
和 "Link rel=prefetch"的语义不同，"Link rel=subresource"是一种新的连接关系。rel=prefetch指定了下载后续页面用到资源的低优先级，而rel=subresource则是指定当前页面资源的提前加载。
所以，如果资源是在当前页面需要，或者马上就会用到，则推荐用subresource，否则还是用prefetch。
prerender是一个重量级的选项，它可以让浏览器提前加载指定页面的所有资源。
| 1 |
<linkrel="prerender" href="/thenextpage.html"/> |
Steve Souders的文章详细解释了这个技术：
prerender就像是在后台打开了一个隐藏的tab，会下载所有的资源、创建DOM、渲染页面、执行JS等等。如果用户进入指定的链接，隐藏的这个页面就会进入马上进入用户的视线。Google Search多年前就利用了这个特性实现了Instant Pages功能。微软最近也宣布会让Bing在IE11上用类似prerender的技术。
但是要注意，一定要在十分确定用户回点某个链接时才用这个特性，否则客户端就会无端的下载很多资源和渲染这个页面。
正如任何提前的动作一样，预判总是有一定风险出错。如果提前的动作是昂贵的（比如高CPU、耗电、占用带宽），就要谨慎使用了。虽然不容易预判用户会点进哪个页面，但还是存在一些典型的场景：
如果用户搜索到了一个明显正确的结果时，那么这个页面就很有可能被点入
如果用户在登录页面，那么登录成功后的页面就很可能接下来会被加载了
如果用户在阅读一个多页面的文章或者有页码的内容时，下一页就很可能会马上被点击了
利用Page Visibility API可以用来防止页面在还没真正展示给用户时就触发了JS的执行。
以上是已有的技术，我们再谈谈未来。 preload草案建议允许始终预加载某些资源，不像prefetch有可能被浏览器忽略，浏览器必须请求preload标记的资源。
| 1 |
<linkrel="preload"href="image.png"> |
然而，这项草案还没有任何浏览器支持，不过值得关注。
预判用户的操作虽然不易，而且还需要大量的设计和测试工作，但是性能的提升是值得我们孜孜不倦的去追求的。如果我们愿意试验这些预加载技术，我们肯定能显著地提升用户体验。
（译者补一句，文章说的大部分预加载技术移动端都不支持，PC支持有限，但我们显然应该知道这些技术的存在，并且持续的关注）
