原文:https://www.smashingmagazine.com/2016/02/preload-what-is-it-good-for/

作者:

译者按:网络优化一直是译者长期研究的方向,除了近期热门的 HTTP/2 之外,还是要关注浏览器在加载策略上的一些改进,从不同层面提升用户的访问体验。prefetch 这些 HTML5 的新特性,虽然很新鲜,但并未在生产环境中得到广泛使用,其中的原因是什么?preload 有什么改进?本文将娓娓道来~

========================译文分割线===========================

Preload规范)是一项新的 Web 标准,旨在提升性能,让 Web 开发者对加载的控制更加粒度化。它让开发者有自定义加载逻辑的能力,免受基于脚本的 loader 所带来的性能损耗。

几周前,我在 Chrome Canary 提交了对 preload 的支持,解决了一些 bug,预计将在四月中旬合入 Chrome 稳定版。但 preload 到底是什么?它有什么用处?对你有什么好处呢?

好吧,<link rel="preload"> 它是一种声明式的获取(fetch)指令。

用人话来讲,它是一种告诉浏览器开始获取一项确定资源的方式,因为我们是作者(或者服务器管理员,或者聪明的服务器开发),我们是知道浏览器将很快需要那一项资源的。

不是已经有这种能力了吗?

嗯,也不算是真有。<link rel="prefetch"> 已经被支持一段时间了,也有不错的兼容性。在此基础上,Chrome 也对<link rel="subresource"> 支持好一段时间了,所以 preload 有什么新特性?它跟前面这几个指令有什么区别?它们都告知浏览器去获取资源,是吧?

确实是的,但是它们有一些重要的区别,这些区别使得 preload 成为一项全新的指令,做出之前指令所不能做到的事情。

<link rel="prefetch"> 是一种告诉浏览器获取一项可能被下一页访问所需要的资源方式。这意味着资源将以较低优先级地获取(因为浏览器知道当前页面所需要的资源,要比我们猜测在下一页访问所需资源更重要)。这意味着 prefetch 的主要用途是加速下一页访问速度,而不是当前页面的速度。

<link rel="subresource"> 原本是计划处理当前页面的,但是在一些特别的场景失败了。由于 Web 开发者无法定义资源的优先级,所以浏览器(实际只有 Chrome 和基于 Chromium 的浏览器)使用同等较低的优先级加载资源,也就是说大多数情况,即使没有 subresource,请求也是同一时机发出的。

Preload 如何做得更好?

Preload 像 subresource 一样,注定是为当前页面服务的,但具备一项小而重要的区别。它有一个 as 属性,这可以让浏览器做到很多 subresource 和 prefetch 做不到的事情:

  • 浏览器可以设置正确的资源优先级,使得资源可以被正确地加载,重要的资源不再会被延迟,不再被不重要的资源阻塞。
  • 浏览器会保证请求对应正确的内容安全策略(Content-Security-Policy )指令,不会发起非法请求。
  • 浏览器会基于资源类型发送正确的 Accept 首部。(比如获取图片时指定对“image/webp” 的支持)
  • 浏览器知道资源的类型,所以可以稍后决定资源是否在后续请求中保持可重用。

Preload 的另外一个不同是,它有 onload 事件(至少在 Chrome 中,对另外两种 rel 取值并没作用)。

Preload 不阻塞 window 的 onload 事件,除非该资源是被一个阻塞该事件的资源请求的。

将这些特性结合在一起,我们可以做到一些新的事情。

加载较晚发现的资源

preload 最基本的使用方式是提前加载较晚发现的资源。虽然大部分基于标签的资源会被浏览器内部的预加载器(preloader)提早发现,但并非所有资源都是基于标签的。有些资源是隐藏在 CSS 和 JavaScript 中的,浏览器不知道页面即将需要这些资源,而等到发现它们时已经为时已晚。所以在有些情况,这些资源延缓了首屏渲染,或是延缓了页面关键部分的加载。

而现在你有途径告诉浏览器,“ 嘿,浏览器!这个是你一会所需要的资源,现在就开始加载吧。”

做法可能如下

as 属性告诉浏览器什么类型的资源将被下载。as 可能的取值有:

  • “script”
  • “style”
  • “image”
  • “media”
  • “document”

(参考 fetch 规范的完整列表)

如果省略 as 属性,或者给定一个非法值,将等同发起一个 XHR 请求,因为浏览器不知道将要获取的是什么,并且加载的优先级也会很低。

较早加载字体

一种流行的“ 较晚发现关键资源” 的代表是 Web 字体。一方面,它对页面渲染字体很关键(除非你在使用最新的 font-display)。另一方面,它们被埋在 CSS 很深的地方,即使浏览器的预加载器解析了 CSS,也不能保证在它们选择器应用到 DOM 节点之前,就是被需要的。理论上讲,浏览器应该可以发觉这种情况,但实际上都没有,而就算可以,也会造成无谓的下载,因为后续的 CSS 规则可能会覆盖现有的字体样式规则。

简而言之,这很复杂。

但是,你可以对一定需要的字体使用 preload 指令,摆脱上述的复杂问题。像这样:

有一点需要指明,获取字体时必须加上 crossorigin 属性,就如使用 CORS 的匿名模式获取一样。是的,即使你的字体与页面同域,抱歉……

同时,type 属性确保了浏览器只预加载其支持的类型文件。现在,只有 Chrome 支持 preload,同时支持 WOFF2。未来会有越来越多浏览器支持 preload,但我们不敢确保它们都会支持 WOFF2。同理,不同浏览器对不同类型的资源支持也可能是不一样的。

动态加载,不做运行

另一个突然变得现实的有趣场景是,你想下载一个资源因为你觉得它是被需要的,但不想立即运行它。举个例子,想象这个场景,你想在页面生命周期的一个特定时间点执行代码,而不用通过脚本来控制(不用添加一个 runNow() 的方法)。

如今,要做到上面的事情非常受限。如果只是在需要运行的地方注入脚本,浏览器会在执行前下载这段脚本,耗费一点时间。也可以先使用 XHR 下载脚本,但浏览器会拒绝使用它,因为资源不是以同样 type 下载的。

所以该怎么办呢?

在没有 preload 之前,也没什么办法了。(在一些场景可以使用 eval() 脚本的内容,但那不太切合实际并且伴有副作用。)但可以配合 preload 来实现!

可以在页面加载的早期运行它,也就是在希望脚本运行的早些时间(但你要确信这个脚本不会对其他需要加载的关键资源有所干扰)。然后但你想运行它们的时候,只要简单注入一段脚本就好了。

基于标签的异步加载器

另一个酷炫的技巧,是使用 onload 处理函数来创建一些基于标签的异步加载器。Scott Jehl 做了这方面的第一个实验,作为他的 loadCSS 库。简单说,你可以这么使用:

在标签里获取异步的样式表!Scott 还有一个该特性的 demo 页面。

该特性同样可以应用在脚本上。

话说我们不是已经有<script async> 了吗?嗯,<script async> 确实不错,但它会阻塞 window 的 onload 事件。在一些情况,这可能是你希望的,而有些情况并不是。

比如说你想下载一个上报分析脚本,希望尽快去加载它(以避免分析脚本漏掉一些访客上报),但不想它对用户体验有任何影响,也就是不希望它对 onload 造成延迟。(你可以说 onload 不是影响用户的唯一因素,但缩短转菊花的时间总是一件好事)。

有了 preload,实现起来就很容易了:

(onload 属性中包含太长 JS 可能不是个好主意,可以在 inline 的代码中来定义。)

 

========================译文分割线===========================

由于本文篇幅较长,便于大家吸收消化,更多网络细节以及 HTTP/2 相关内容,将于下一篇博客与各位见面~

原创文章转载请注明:

转载自AlloyTeam:http://www.alloyteam.com/2016/05/preload-what-is-it-good-for-part1/

发表评论