prefetch
1. 场景以及使用方式
其利用浏览器空闲时间来下载或预取用户在不久的将来可能访问的文档，获取到后存储在缓存中
使用方式：
<link rel="prefetch" href="/images/big.jpeg">
Link: </images/big.jpeg>; rel=prefetch
<meta http-equiv="Link" content="</images/big.jpeg>; rel=prefetch">
2. 特性
空闲时间通过nsIWebProgressListener确定。
不受同源限制。
X-moz: prefetch 具有这个请求头
preload
1. 场景以及使用方式
可以指明哪些资源是在页面加载完成后即刻需要的。对于这种即刻需要的资源，你可能希望在页面加载的生命周期的早期阶段就开始获取，在浏览器的主渲染机制介入前就进行预加载。这一机制使得资源可以更早的得到加载并可用，且更不易阻塞页面的初步渲染，进而提升性能。
使用方式， 可使用as指定预加载的内容类型，是的浏览器可以特定设置安全策略、优先级、请求头等
<link rel="preload" href="style.css" as="style">
<link rel="preload" href="main.js" as="script">
可使用资源
例如那些在CSS文件中指向的资源，比如字体或是图片；再比如更大的图片和视频文件。
2. 特性
加载跨域资源，只需要对应域名支持跨域，并且增加；如果加载的是字体文件，即使是非跨域的情况，也需要加上这个属性。
crossorigin="anonymous"
脚本化预加载的资源
var preloadLink = document.createElement("link");
preloadLink.href = "myscript.js";
preloadLink.rel = "preload";
preloadLink.as = "script";
document.head.appendChild(preloadLink);
需要执行的时候再添加如下语句
var preloadedScript = document.createElement("script");
preloadedScript.src = "myscript.js";
document.body.appendChild(preloadedScript);
使用“as”属性预加载的资源将具有与它们请求的资源类型相同的资源优先级。 例如，preload as =“style”将获得最高优先级，而as =“script”将获得低优先级或中优先级。 这些资源也遵循相同的CSP策略（例如脚本受 script-src 约束）。
不带 “as” 属性的 preload 的优先级将会等同于异步请求。
当页面 preload 已经在 Service Worker 缓存及 HTTP 缓存中的资源时，不再重新发起请求
对比
还存在一些其他预加载机制，但没有哪个会比<link rel="preload">在大多数情况下更符合你的需要和预期：
<link rel="prefetch">已经被许多浏览器支持了相当长的时间，但它是意图预获取一些资源，以备下一个导航/页面使用（比如，当你去到下一个页面时）。这很好，但对当前的页面并没有什么助益。此外，浏览器会给使用prefetch的资源一个相对较低的优先级——与使用preload的资源相比。毕竟，当前的页面比下一个页面相对更加重要。查看Link prefetching FAQ可以了解更多细节。<link rel="subresource">被Chrome支持了有一段时间，并且已经有些搔到预加载当前导航/页面（所含有的资源）的痒处了。但它有一个问题——没有办法处理所获取内容的优先级（as也并不存在），所以最终，这些资源会以一个相当低的优先级被加载，这使得它能提供的帮助相当有限。- 除以上这些以外，还有大量的基于脚本的资源加载器。但这些加载器对于浏览器的加载优先级队列完全束手无策，这也使得他们不得不屈服于同样的性能问题。
