共计 5661 个字符，预计需要花费 15 分钟才能阅读完成。
这是 Web 性能优化的第 6 篇，上一篇在下面看点击查看：
Web 性能优化：使用 Webpack 分离数据的正确方法
Web 性能优化：图片优化让网站大小减少 62%
Web 性能优化：缓存 React 事件来提高性能
Web 性能优化：21 种优化 CSS 和加快网站速度的方法
Web 性能优化：理解及使用 JavaScript 缓存
今天，我们将深入研究 Chrome 的网络栈，以明确 web 加载原语(如 <link rel= preload > & <link rel= prefetch >) 背后的工作原理，以便你能够更有效地使用它们。
如其他文章所述，preload 是一个声明式 fetch，可以强制浏览器在不阻塞 document 的 onload 事件的情况下请求资源。
Prefetch 告诉浏览器这个资源将来可能需要，但是什么时间加载这个资源是由浏览器来决定的。
在预加载 (perload) 之前，网络请求从这里开始，预加载之后，它在解析时从左向右移动
使用预加载 (perload) 的一些案例
在详细介绍 预加载(perload) 之前，先来看看一些使用 预加载(perload) 的案例。
Housing.com 在对他们的渐进式 Web 应用程序的脚本转用 proload 看到大约缩短了 10% 的可交互时间。
Shopify 使用 preload 加载 Web 字体后，Chrome 桌面版)的文本绘制时间 (1.2 秒) 提高了 50%，这完全解决了他们的文字闪动问题。
左边：使用 preload，右边：不使用 preload
使用 <link rel=”preload”> 加载字体
Treebo，印度最大的旅馆网站之一，在 3G 网络下对其桌面版试验，在对其顶部图片和主要的 Webpack 打包文件使用 preload 之后，在首屏绘制和可交互延迟分别减少了 1s。
同样的，在对自己的渐进式 Web 应用程序主要打包文件使用 preload 之后，Flipkart 在路由解析之前 节省了大量的主线程空闲时间（在 3G 网络下的低性能手机下）。
上面：没有使用 proload 加载，下面：使用 preload 加载
Chrome 数据保护程序团队发现，对于那些可以在脚本和 CSS 样式表上使用 preload 的页面，发现页面首次绘制时间获得平均 12% 的速度提升。
对于 prefetch(预读取)，它被广泛使用，在 Google 我们仍用它来预读取一些可以加快 搜索结果页面 的渲染的关键资源。
Preload 在大型网站中都有很好运用，你可以在本文后面找到更多这些安全。在此之前，让我们深入了解网络堆栈如何实际处理 预加载 (prefetch) 与预读取(prefetch)。
何时使用 <link rel=”preload”> 和 <link rel=”prefetch”>？
提示：preload 加载资源一般是当前页面需要的，prefetch 一般是其它页面有可能用到的资源。
preload 是告诉浏览器预先请求当前页面需要的资源（关键的脚本，字体，主要图片等）。
prefetch 应用场景稍微又些不同 —— 用户将来可能跳转到其它页面需要使用到的资源。如果 A 页面发起一个 B 页面的 prefetch 请求，这个资源获取过程和导航请求可能是同步进行的，而如果我们用 preload 的话，页面 A 离开时它会立即停止。
在 preload 和 prefetch 之间，我们对当前页面或即将跳转的页面在所需主要资源的问题有了一个解决方案。
<link rel=”preload”> 和 <link rel=”prefetch”> 的缓存行为
当资源被 preload 或者 prefetch 后，会从网络堆栈传输到 HTTP 缓存并进入渲染器的内存缓存。如果资源可以被缓存（例如，存在有效的 cache-control 和 max-age），它将存储在 HTTP 缓存中，可用于当前和未来的会话。如果资源不可缓存，则不会将其存储在 HTTP 缓存中。相反，它会被缓存到内存缓存中并保持不变直到它被使用。
Chrome 的网络栈中是如何处理 preload 和 prefetch 的优先级？
下面是在 Blink 内核的 Chrome 46 及更高版本中不同资源的加载优先级情况著作权归作者所有。
preload 用“as”或者用“type”属性来表示他们请求资源的优先级（比如说 preload 使用 as=”style” 属性将获得最高的优先级）。没有“as”属性的将被看作异步请求，“Early”意味着在所有未被预加载的图片请求之前被请求（“late”意味着之后）
我们来谈一下这张表。
脚本根据它们在文件中的位置是否异步、延迟或阻塞获得不同的优先级：
网络在第一个图片资源之前阻塞的脚本在网络优先级中是中级
网络在第一个图片资源之后阻塞的脚本在网络优先级中是低级
异步 / 延迟 / 插入的脚本（无论在什么位置）在网络优先级中是很低级
图像在可视窗口中比不在视口中的图像(具有更高的优先级，因此在某种程度上，Chrome 将会尽量懒加载这些不在视口中的图片。较低优先级的图片出现在视口中时，该图片的优先级就会得到提升（但是注意已经在布局完成后的图片优先级不会在更改）。
使用“as”属性预加载的资源将具有与它们请求的资源类型相同的资源优先级。例如，preload as =“style”将获得最高优先级，而 as =“script”将获得低优先级或中优先级。这些资源也遵循相同的 CSP 策略（例如脚本受 script-src 约束）。
不带“as”属性的 preload 的优先级将会等同于异步请求。
如果你想了解各种资源加载时的优先级属性，从开发者工具的 Timeline/Performance 区域的 Network 区域都能看到相关信息：
在 Network 面板下的“Priority”部分
当页面 preload 已经在 Service Worker 缓存及 HTTP 缓存中的资源时会发生什么？
这各情况来说是比较少的，但通常来说，会是比较好的情况 —— 如果资源没有超出 HTTP 缓存时间或者 Service Worker 没有主动重新发起请求，那么浏览器就不会再去请求这个资源了。
如果资源在 HTTP 缓存中(在 SW 缓存和网络之间)，那么 preload 会从相同的资源中获得缓存命中。
这种加载方式会浪费用户的带宽吗
使用 preload 或 prefetch，可能会浪费用户的带宽，特别是在资源没有缓存的情况下。
没有用到的 preload 资源在 Chrome 的 console 里会在 onload 事件 3s 后发生警告。
这个警告的原因是，你可能正在使用 preload 来尝试为其他资源预加载并缓存以提高性能，但是如果这些预加载的资源没有被使用，那么你就在毫无理由地做额外的工作。在移动设备上，这相当于浪费用户的流量，所以要注意预加载的内容。
什么情况会导致二次获取？
preload 和 prefetch 是很简单的工具，你很容易不小心二次获取。
不要用“prefetch”作为“preload”的后备方案，它们适用于不同的场景，常常会导致不符合预期的二次获取。使用 preload 来获取当前需要任务否则使用 prefetch 来获取将来的任务，不要一起用。
对 preload 使用“as”属性，不然将不会从中获益。
如果在指定要 preload 的内容（例如脚本）时未提供有效的“as”，则最终将获取两次。
preload 字体不带 crossorigin 也将会二次获取, 确保在使用 preload 获取字体时添加 crossorigin 属性，否则将二次下载。他这个请求使用匿名的跨域模式。即使字体与页面位于同个域 下，也建议使用。也适用于其他域名的获取(比如说默认的异步获取)。
最后，虽然它不会导致两次获取，但这通常是一个很好的建议：
不要所有的请求资源都加 preload, 用 preload 来告诉浏览器一些很被需要的资源，以便让它提早获取它们。
我应当在页面头部所有的资源都加上 preload？
这是工具的一个很好的例子，而不是规则。preload 的文件数量取决于加载其他资源时网络内容、用户的带宽和其他网络状况。
尽早 preload 页面中可能需要的文件，对于脚本，preload 你的密钥包是很好的，因为它将获取与执行分开，而仅仅使用 <script async> 不会这样做，因为它会阻止窗口的 onload 事件。你可以 preload 图像、样式、字体和媒体。最重要的是，作为一名页面作者，你可以更好地控制提前获取页面所需要的信息。
prefetch 是否具有你应该注意的任何魔法属性？是的，
在 Chrome 中，如果用户导航离开一个页面，而对其他页面的预取请求仍在进行中，这些请求将不会被终止。
此外，无论资源的可缓存性如何，prefetch 请求在未指定的网络堆栈缓存中至少保存 5 分钟。
我在 JS 中使用自定义的“preload”，它跟原本的 rel=”preload” 或者 preload 头部有什么不同？
preload 解耦从 JS 处理和执行中获取资源。因此，preload 在标记中声明以被 Chrome preload 扫描器扫描。这意味着在许多情况下，在 HTML 解析器甚至到达标签之前，将获取预加载（具有指示的优先级），这使它比自定义预加载实现更强大。
不是可以用 HTTP/2 的服务器推送来代替 preload 吗？
当你知道资源的精确加载顺序时使用推送，并让 service worker 拦截可能导致再次推送缓存资源的请求。使用 preload 可以使资源的开始下载时间更接近初始请求 – 这对所有的资源获取都有用。
我们假设浏览器正在加载一个页面，页面中有个 CSS 文件，CSS 文件又引用一个字体库，对于这样的场景，
若使用 HTTP/2 PUSH，当服务端获取到 HTML 文件后，知道以后客户端会需要字体文件，它就立即主动地推送这个文件给客户端，如下图：
而对于 preload，服务端就不会主动地推送字体文件，在浏览器获取到页面之后发现 preload 字体才会去获取，如下图：
虽然推送很有效，但它不像 preload 那样对所有的情况都适应。
推送不能用于第三方资源的内容，通过立即发送资源，它还有效地缩短浏览器自身的资源优先级情况。在你明确的知道在做什么时，这应该会提高你的应用性能，如果不是很清晰的话，你也许会损失掉部分的性能。
peload 请求头是什么？它与 preload 标签相比如何？它与 HTTP/2 服务器推送有什么关系？
与其他类型的链接一样，preload 链接即可以使用 HTML 标记 或 HTTP 标头。在任何一种情况下，preload 链接都会指示浏览器开始将资源加载到内存缓存中，这表明该页面有很高可能性使用该资源，并且不希望等待预加载扫描程序或解析程序发现它。
当金融时报在它们的网站使用 preload HTTP 头时，他们节约了大约 1s 的显示片头图片时间。
1：没有使用 preload 2：使用了 preload
你可以使用任何一种形式提供 preload 链接，但是你应该知道一个重要区别：如规范所允许的，许多服务器在遇到 HTTP 头的 preload 链接时会触发 HTTP/2 服务器推送。HTTP/2 推送的性能影响不同于普通的预加载，所以你要确保没有发起不必要的推送。
你可以使用 preload 标签来代替 preload 头以避免不必要的推送，或者在你的 HTTP 头上加一个“nopush”属性。
如何判断 <link rel=”preload”> 的支持情况？
以下的代码段可以判断 <link rel=”preload”> 支持情况：
const preloadSupported = () => {
const link = document.createElement(‘link’);
const relList = link.relList;
if (!relList || !relList.supports)
return false;
return relList.supports(‘preload’);
};
FilamentGroup 也有一个 preload 检测器，作为他们的异步 CSS 加载库 loadCSS 的一部分。
可以使用 preload 让 CSS 样式立即生效吗？
当然可以，preload 支持基于异步加载的标记，使用 <link rel=”preload”> 的样式表可以使用 onload 事件立即应用于当前文档：
<link rel=”preload” href=”style.css” onload=”this.rel=stylesheet”>
preload 还被哪些网站广泛的应用？
根据 HTTPArchive，大多数使用 <link rel =“preload”> 的网站使用它来预加载 Web 字体，包括 Teen Vogue 和前面提到的 Shopify：
而 LifeHacker 和 JCPenny 等其他热门网站使用它来异步加载 CSS（通过 Filament Group loadCSS）：
然后，有越来越多的渐进式 Web 应用程序 (如 Twitter.com mobile、Flipkart 和 Housing) 使用它来预加载当前导航所需的脚本(使用 PRPL 等模式)
其基本思想是以高粒度维护工件（而不是整体捆绑），所以任何应用都可以按需加载依赖或者预加载资源并放在缓存中。
当前浏览器对 preload 和 Prefetch 的支持程序如何
根据 CanIUse，<link rel =“preload”> 约 50% 的支持度，<link rel =“prefetch”> 约 71%。
相关阅读
Preload — what is it good for? — Yoav Weiss
A <link rel=”preload”> study by the Chrome Data Saver team
Planning for performance — Sam Saccone
Webpack plugin for auto-wiring up <link rel=”preload”>
What is preload, prefetch and preconnect? — KeyCDN
Web Fonts preloaded by Zach Leat
HTTP Caching: cache-control by Ilya Grigorik
你的点赞是我持续分享好东西的动力，欢迎点赞！
一个笨笨的码农，我的世界只能终身学习！
更多内容请关注公众号《大迁世界》！
