Link 标签的预加载机制

2023-02-21 242

版权

本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。

简介： Link 标签的预加载机制

Mdn参考文章：developer.mozilla.org/en-US/docs/…

前言

前端页面加载资源的方式有很多种，预处理类 link 标签就是允许我们控制浏览器，提前针对一些资源去做这些操作，以提高性能，本篇就和大家一起梳理一下 link 标签都有哪些配置项

先简单介绍下 link 标签作用

我们可以在页面 <head> 元素内部使用 <link> 标签书写一些声明式的资源获取请求

预加载 preload

有些资源是在页面加载完成后即刻需要的，对于这种即刻需要的资源，你可能希望在页面加载的生命周期的早期阶段就开始获取，在浏览器的主渲染机制介入前就进行预加载

这一机制使得资源可以更早的得到加载并可用，且更不易阻塞页面的初步渲染，进而提升性能

基本用例

<head>
    <meta charset="utf-8">
    <title>JS and CSS preload example</title>
    <link rel="preload" href="style.css" as="style">
    <link rel="preload" href="main.js" as="script">
    <link rel="stylesheet" href="style.css">
</head>
<body>
    <script src="main.js"></script>
</body>
复制代码

preload 使用 as 指定预加载的内容的类型，将使得浏览器能够

更精确地优化资源加载优先级
匹配未来的加载需求，在适当的情况下，重复利用同一资源
为资源应用正确的内容安全策略
为资源设置正确的 Accept 请求头

as 可选参数

audio: 音频文件
document: 一个将要被嵌入到或内部的 HTML 文档
embed: 一个将要被嵌入到元素内部的资源
fetch: 那些将要通过 fetch 和 XHR 请求来获取的资源，比如一个 ArrayBuffer 或 JSON 文件
font: 字体文件
image: 图片文件
object: 一个将会被嵌入到元素内的文件
script: JavaScript 文件
style: 样式表
track: WebVTT 文件
worker: 一个 JavaScript 的 web worker 或 shared worker
video: 视频文件

跨域获取 crossorigin

如果你已经有了一个可以正确工作的 CORS 设置，那么你也可以同样成功的预加载那些跨域资源，只需要你在 <link> 元素中设置好 crossorigin 属性即可注意：如果你需要获取的是字体文件，那么即使是非跨域的情况下，也需要应用这一属性

<head>
    <meta charset="utf-8">
    <title>Web font example</title>
    <link rel="preload" href="fonts/cicle_fina-webfont.eot" as="font" type="application/vnd.ms-fontobject" crossorigin="anonymous">
    <link rel="preload" href="fonts/cicle_fina-webfont.woff2" as="font" type="font/woff2" crossorigin="anonymous">
    <link rel="preload" href="fonts/cicle_fina-webfont.woff" as="font" type="font/woff" crossorigin="anonymous">
    <link rel="preload" href="fonts/cicle_fina-webfont.ttf" as="font" type="font/ttf" crossorigin="anonymous">
    <link rel="preload" href="fonts/cicle_fina-webfont.svg" as="font" type="image/svg+xml" crossorigin="anonymous">
    <link href="style.css" rel="stylesheet" type="text/css">
</head>
<body>
  ...
</body>
复制代码

包含媒体 media

<link> 元素有一个很棒的特性是它们能够接受一个 media 属性。它们可以接受媒体类型或有效的媒体查询作为属性值，这将令你能够使用响应式的预加载！

<head>
    <meta charset="utf-8">
    <title>Responsive preload example</title>
    <link rel="preload" href="bg-image-narrow.png" as="image" media="(max-width: 600px)">
    <link rel="preload" href="bg-image-wide.png" as="image" media="(min-width: 601px)">
    <link rel="stylesheet" href="main.css">
</head>
<body>
    <header>
        <h1>My site</h1>
    </header>
    <script>
        var mediaQueryList = window.matchMedia("(max-width: 600px)");
        var header = document.querySelector('header');
        if(mediaQueryList.matches) {
            header.style.backgroundImage = 'url(bg-image-narrow.png)';
        } else {
            header.style.backgroundImage = 'url(bg-image-wide.png)';
        }
    </script>
</body>
复制代码

上面是一个简单的例子，我们可以通过媒体查询，来根据屏幕的大小预加载不同的图片

这一特性将使另一种情况成为可能——字体在随着页面渲染完成的时候即可使用，减少了FOUC (无样式字体闪烁)等问题

值得注意的是，这一特性并不仅限于图片，或其他有着同样类型的文件，还有更多想象空间。比如，你可以在用户仅有较窄的屏幕，CPU 和带宽资源较为有限的情况下预加载并展示一个简单的 SVG 图表，而在用户资源较为充裕的时候再去加载一系列复杂的 JavaScript 文件以显示一个有交互功能的 3D 模型

脚本化与预加载

另一项很棒的关于预加载的事情是，如果需要，你可以完全以脚本化的方式来执行这些预加载操作。例如，我们在这里创建一个 HTMLLinkElement 实例，然后将他们附加到 DOM 上：

var preloadLink = document.createElement("link");
preloadLink.href = "myscript.js";
preloadLink.rel = "preload";
preloadLink.as = "script";
document.head.appendChild(preloadLink);
复制代码

这意味着浏览器将预加载这个 JavaScript 文件，但并不实际执行它

当你需要预加载一个脚本，但需要推迟到需要的时候才令其执行时，这种方式会特别有用

如果要对其加以执行，在需要的时候，你可以执行：

var preloadedScript = document.createElement("script");
preloadedScript.src = "myscript.js";
document.body.appendChild(preloadedScript);
复制代码

其他资源预加载机制

还存在一些其他预加载机制，但没有哪个会比 <link rel="preload">在大多数情况下更符合你的需要和预期：

<link rel="prefetch"> 已经被许多浏览器支持了相当长的时间，但它是意图预获取一些资源，以备下一个导航 / 页面使用（比如，当你去到下一个页面时）。这很好，但对当前的页面并没有什么助益。此外，浏览器会给使用 prefetch 的资源一个相对较低的优先级——与使用 preload 的资源相比。毕竟，当前的页面比下一个页面相对更加重要
<link rel="subresource"> 被 Chrome 支持了有一段时间，并且已经有些搔到预加载当前导航 / 页面（所含有的资源）的痒处了。但它有一个问题——没有办法处理所获取内容的优先级（as也并不存在），所以最终，这些资源会以一个相当低的优先级被加载，这使得它能提供的帮助相当有限
除以上这些意外，还有大量的基于脚本的资源加载器。但这些加载器对于浏览器的加载优先级队列完全束手无策，这也使得他们不得不屈服于同样的性能问题。