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

2023-08-02 10:41:03 157

preload提供了一种声明式的命令，让浏览器提前加载指定资源(加载后并不执行)，在需要执行的时候再执行。提供的好处主要是

将加载和执行分离开，可不阻塞渲染和document的onload事件

提前加载指定资源，不再出现依赖的font字体隔了一段时间才刷出

如何使用preload

使用link标签创建

使用HTTP响应头的Link字段创建

Link:;rel=preload;as=style

如我们常用到的antd会依赖一个CDN上的font.js字体文件，我们可以设置为提前加载，以及有一些模块虽然是按需异步加载，但在某些场景下知道其必定会加载的，则可以设置preload进行预加载，如：

如何判断浏览器是否支持preload

目前我们支持的浏览器主要为高版本Chrome，所以可放心使用preload技术。其他环境在caniuse.com上查到的支持情况如下：

在不支持preload的浏览器环境中，会忽略对应的link标签，而若需要做特征检测的话，则：

constisPreloadSupported=()=>{
constlink=document.createElement('link');
constrelList=link.relList;
if(!relList||!relList.supports){
returnfalse;
}
returnrelList.supports('preload');
};

如何区分preload和prefetch

preload是告诉浏览器页面必定需要的资源，浏览器一定会加载这些资源；

prefetch是告诉浏览器页面可能需要的资源，浏览器不一定会加载这些资源。

preload是确认会加载指定资源，如在我们的场景中，x-report.js初始化后一定会加载PcCommon.js和TabsPc.js,则可以预先preload这些资源；

prefetch是预测会加载指定资源，如在我们的场景中，我们在页面加载后会初始化首屏组件，当用户滚动页面时，会拉取第二屏的组件，若能预测用户行为，则可以prefetch下一屏的组件。

preload将提升资源加载的优先级

使用preload前，在遇到资源依赖时进行加载：

使用preload后，不管资源是否使用都将提前加载：

可以看到，preload的资源加载顺序将被提前：

避免滥用preload

使用preload后，Chrome会有一个警告：

如上文所言，若不确定资源是必定会加载的，则不要错误使用preload，以免本末倒置，给页面带来更沉重的负担。

当然，可以在PC中使用preload来刷新资源的缓存，但在移动端则需要特别慎重，因为可能会浪费用户的带宽。

避免混用preload和prefetch

preload和prefetch混用的话，并不会复用资源，而是会重复加载。

使用preload和prefetch的逻辑可能不是写到一起，但一旦发生对用一资源preload或prefetch的话，会带来双倍的网络请求，这点通过Chrome控制台的网络面板就能甄别：

避免错用preload加载跨域资源

若css中有应用于已渲染到DOM树的元素的选择器，且设置了@font-face规则时，会触发字体文件的加载。而字体文件加载中时，DOM中的这些元素，是处于不可见的状态。对已知必加载的font文件进行预加载，除了有性能提升外，更有体验优化的效果。

在我们的场景中，已知antd.css会依赖font文件，所以我们可以对这个字体文件进行preload:

然而我发现这个文件加载了两次：

原因是对跨域的文件进行preload的时候，我们必须加上crossorigin属性：

再看一下网络请求，就变成一条了。

W3规范是这么解释的：

PreloadlinksforCORSenabledresources,suchasfontsorimageswithacrossoriginattribute,mustalsoincludeacrossoriginattribute,inorderfortheresourcetobeproperlyused.

那为何会有两条请求，且优先级不一致，又没有命中缓存呢？这就得引出下一个话题来解释了。

不同资源加载的优先级规则

我们先来看一张图：

这张表详见：ChromeResourcePrioritiesandScheduling

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

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,且与样式引入的请求同源，从而做到命中缓存：

这么请求就只剩一个：

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

总结

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

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

更多关于preload预加载页面的文章大家可以看看下面的相关链接

声明：本文内容来源于网络，版权归原作者所有，内容由互联网用户自发贡献自行上传，本网站不拥有所有权，未作人工编辑处理，也不承担相关法律责任。如果您发现有涉嫌版权的内容，欢迎发送邮件至：czq8825#qq.com（发邮件时，请将#更换为@）进行举报，并提供相关证据，一经查实，本站将立刻删除涉嫌侵权内容。