使用preload预加载页面资源时注意事项(2)

这张图表示的是，在 Chrome 46 以后的版本中，不同的资源在浏览器渲染的不同阶段进行加载的优先级。 在这里，我们只需要关注 DevTools Priority 体现的优先级，一共分成五个级别：

Highest 最高

Hight 高

Medium 中等

Low 低

Lowest 最低

html 主要资源，其优先级是最高的

css 样式资源，其优先级也是最高的

CSS(match) 指的是对已有的 DOM 具备规则的有效的样式文件。

script 脚本资源，优先级不一

前三个 js 文件是写死在 html 中的静态资源依赖，后三个 js 文件是根据首屏按需异步加载的组件资源依赖，这正验证了这个规则。

font 字体资源，优先级不一

样式文件中有一个 @font-face 依赖一个 font 文件，样式文件中依赖的字体文件加载的优先级是 Highest； 在使用 preload 预加载这个 font 文件时，若不指定 crossorigin 属性(即使同源)，则会采用匿名模式的 CORS 去加载，优先级是 High，看下图对比： 第一条 High 优先级也就是 preload 的请求：

第二条 Highest 也就是样式引入的请求：

可以看到，在 preload 的请求中，缺少了一个 origin 的请求头字段，表示这个请求是匿名的请求。 让这两个请求能共用缓存的话，目前的解法是给 preload 加上 crossorigin 属性，这样请求头会带上 origin, 且与样式引入的请求同源，从而做到命中缓存：

<link as="font" crossorigin href="https://at.alicdn.com/t/font_zck90zmlh7hf47vi.woff" >

这么请求就只剩一个：

在网络瀑布流图中，也显示成功预加载且后续命中缓存不再二次加载：

总结

preload 是个好东西，能告诉浏览器提前加载当前页面必须的资源，将加载与解析执行分离开，做得好可以对首次渲染带来不小的提升，但要避免滥用，区分其与 prefetch 的关系，且需要知道 preload 不同资源时的网络优先级差异。

preload 加载页面必需的资源如 CDN 上的字体文件，与 prefetch 预测加载下一屏数据，兴许是个不错的组合。