摘要：例如，将获得最高优先级，而将获得低优先级或中优先级。不带属性的的优先级将会等同于异步请求。对使用属性，不然将不会从中获益。因此，在标记中声明以被扫描器扫描。
这是 Web 性能优化的第 6 篇，上一篇在下面看点击查看：
Web 性能优化：使用 Webpack 分离数据的正确方法
Web 性能优化：图片优化让网站大小减少 62%
Web 性能优化：缓存 React 事件来提高性能
Web 性能优化：21种优化CSS和加快网站速度的方法
Web 性能优化：理解及使用 JavaScript 缓存
今天，我们将深入研究Chrome 的网络栈，以明确 web 加载原语(如<link rel= preload > & ) 背后的工作原理，以便你能够更有效地使用它们。
想阅读更多优质文章请猛戳GitHub博客,一年百来篇优质文章等着你！
如其他文章所述，preload 是一个声明式 fetch，可以强制浏览器在不阻塞 document 的 onload 事件的情况下请求资源。
Prefetch 告诉浏览器这个资源将来可能需要，但是什么时间加载这个资源是由浏览器来决定的。
在预加载(perload)之前，网络请求从这里开始，预加载之后，它在解析时从左向右移动
使用预加载(perload)的一些案例在详细介绍 预加载(perload) 之前，先来看看一些使用 预加载(perload) 的案例。
Housing.com 在对他们的渐进式 Web 应用程序的脚本转用 proload 看到大约缩短了10%的可交互时间。
Shopify 使用 preload 加载 Web字体后，Chrome 桌面版)的文本绘制时间(1.2秒)提高了50%，这完全解决了他们的文字闪动问题。
左边：使用 preload，右边：不使用 preload
使用 加载字体
Treebo，印度最大的旅馆网站之一，在 3G 网络下对其桌面版试验，在对其顶部图片和主要的 Webpack 打包文件使用 preload 之后，在首屏绘制和可交互延迟分别减少了 1s。
同样的，在对自己的渐进式 Web 应用程序主要打包文件使用 preload 之后，Flipkart 在路由解析之前 节省了大量的主线程空闲时间（在 3G 网络下的低性能手机下）。
上面：没有使用 proload 加载，下面：使用 preload 加载
Chrome 数据保护程序团队发现，对于那些可以在脚本和 CSS 样式表上使用 preload 的页面，发现页面首次绘制时间获得平均 12% 的速度提升。
对于 prefetch(预读取)，它被广泛使用，在 Google 我们仍用它来预读取一些可以加快 搜索结果页面 的渲染的关键资源。
Preload 在大型网站中都有很好运用，你可以在本文后面找到更多这些安全。 在此之前，让我们深入了解网络堆栈如何实际处理 预加载(prefetch)与预读取(prefetch)。
何时使用 和 ？提示：preload 加载资源一般是当前页面需要的，prefetch 一般是其它页面有可能用到的资源。
preload 是告诉浏览器预先请求当前页面需要的资源（关键的脚本，字体，主要图片等）。
prefetch 应用场景稍微又些不同 —— 用户将来可能跳转到其它页面需要使用到的资源。如果 A 页面发起一个 B 页面的 prefetch 请求，这个资源获取过程和导航请求可能是同步进行的，而如果我们用 preload 的话，页面 A 离开时它会立即停止。
在 preload 和 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 你的关键模块是很好的，因为它将获取与执行分开，而仅仅使用
而对于 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” 属性。
如何判断 的支持情况？以下的代码段可以判断 支持情况：
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 支持基于异步加载的标记，使用 的样式表可以使用 onload 事件立即应用于当前文档：
preload 还被哪些网站广泛的应用？
根据 HTTPArchive，大多数使用 的网站使用它来预加载Web字体，包括 Teen Vogue 和前面提到的 Shopify：
而 LifeHacker 和 JCPenny 等其他热门网站使用它来异步加载CSS（通过Filament Group loadCSS）：
然后，有越来越多的渐进式 Web 应用程序(如 Twitter.com mobile、Flipkart 和Housing)使用它来预加载当前导航所需的脚本(使用PRPL等模式)
其基本思想是以高粒度维护工件（而不是整体捆绑），所以任何应用都可以按需加载依赖或者预加载资源并放在缓存中。
当前浏览器对 preload 和 Prefetch 的支持程序如何根据 CanIUse，约 50% 的支持度， 约 71%。
相关阅读Preload — what is it good for? — Yoav Weiss
A study by the Chrome Data Saver team
Planning for performance — Sam Saccone
Webpack plugin for auto-wiring up
What is preload, prefetch and preconnect? — KeyCDN
Web Fonts preloaded by Zach Leat
HTTP Caching: cache-control by Ilya Grigorik
代码部署后可能存在的BUG没法实时知道，事后为了解决这些BUG，花了大量的时间进行log 调试，这边顺便给大家推荐一个好用的BUG监控工具 Fundebug。
你的点赞是我持续分享好东西的动力，欢迎点赞！
交流干货系列文章汇总如下，觉得不错点个Star，欢迎 加群 互相学习。
https://github.com/qq44924588...
我是小智，公众号「大迁世界」作者，对前端技术保持学习爱好者。我会经常分享自己所学所看的干货，在进阶的路上，共勉！
关注公众号，后台回复福利，即可看到福利，你懂的。
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/103430.html
摘要：当然并不是所有的页面需要用到的外部域名都需要做这样的域名解析，浏览器默认会解析超链接属性的里面的域名，并且你的网站域名还不能是，如果是，则需要设置请求头或加入一段强制开启域名解析的标签。 废话：异步加载和预加载一直都是前端优化必备技能之一，今天我们就来深度解析一下常用的几个关键点。 异步加载 废话不多说，任何长篇大论的教程都抵不过一张清晰明了的高清大图来得好： showImg(http...
摘要：当然并不是所有的页面需要用到的外部域名都需要做这样的域名解析，浏览器默认会解析超链接属性的里面的域名，并且你的网站域名还不能是，如果是，则需要设置请求头或加入一段强制开启域名解析的标签。 废话：异步加载和预加载一直都是前端优化必备技能之一，今天我们就来深度解析一下常用的几个关键点。 异步加载 废话不多说，任何长篇大论的教程都抵不过一张清晰明了的高清大图来得好： showImg(http...
摘要：和可以用来指定资源是最高优先级的。如果用户进入指定的链接，隐藏的这个页面就会进入马上进入用户的视线。微软最近也宣布会让在上用类似的技术。 预加载 现在的网络情况虽然很乐观，但是 defer和async 当浏览器碰到 script 脚本的时候： 没有 defer 或 async，浏览器会立即加载并执行指定的脚本，立即指的是在渲染该 script 标签之下的文档元素之前，也就是说不等待后...
摘要：之前分享过几篇关于技术栈的原创文章解析前端架构学习复杂场景数据设计干货总结打造单页应用一个项目理解最前沿技术栈真谛一个工程实例今天进一步剖析一个实际案例移动网页版。目前面临的问题在于提高产品的各方面性能体验。 之前分享过几篇关于React技术栈的原创文章： 解析Twitter前端架构 学习复杂场景数据设计 React Conf 2017 干货总结1: React + ES next ...
摘要：当浏览器发现时，就会下载，解析，然后更新，这时会引起一次重绘。这个过程中，有两个非常严重的问题。如果你对异步加载的方案感兴趣，欢迎留言与我讨论扩展阅读浏览器的工作原理关于你应该知道些什么，和它们在之中的优先级 我来填坑了，CSS篇终于写出来了，如果你没看过前面的JS篇，可以在这里观看。 众所周知，CSS的加载会阻塞浏览器渲染或是引起浏览器重绘，目前业界普遍推荐把CSS放到中，防止在CS...
阅读 4157·2023-04-26 02:40
阅读 2657·2023-04-26 02:31
阅读 2749·2021-11-15 18:08
阅读 571·2021-11-12 10:36
阅读 1425·2021-09-30 09:57
阅读 5193·2021-09-22 15:31
阅读 2628·2019-08-30 14:17
阅读 1271·2019-08-30 12:58
