预加载的核心是利用浏览器资源提示机制提升性能。通过优先加载当前页面关键资源（如字体、首屏图片），低优先级预取未来页面资源，结合as属性正确声明资源类型以确保优先级、缓存和安全策略生效，避免重复下载。此外，浏览器还通过预加载扫描器、img/srcset、video@preload等原生机制及JavaScript动态加载实现隐式优化。正确区分preload（当前需用）与prefetch（未来可能用）的使用场景，可最大化用户体验提升。
在HTML中实现预加载，核心在于巧妙地利用浏览器提供的资源提示（Resource Hints）机制，特别是
和
，以及一些原生标签的优化特性。这就像是提前给浏览器打个招呼，告诉它“嘿，这些资源你可能很快就要用到，不如先准备着？”目的很简单，就是为了让用户在访问页面时，关键内容能够更快地呈现在眼前，减少等待时间。
解决方案
要实现HTML预加载，我们主要依赖以下几种方式：
1. 使用
：当前页面的关键资源
这是目前最常用、也最推荐的预加载方式，尤其适用于当前页面“立刻需要”但又不想阻塞渲染的资源。比如，你的CSS文件、JavaScript脚本、Web字体，或者首屏展示的关键图片（hero image）。
立即学习“前端免费学习笔记（深入）”；
它的工作原理是告诉浏览器，这个资源优先级很高，请尽快下载，但不要立即执行或渲染，等到真正需要时再使用。这能有效分离资源的下载和执行，避免阻塞渲染。
示例：
预加载CSS文件：
这里，
preload
会先下载
styles.css
，但不会应用它。当
出现时，浏览器就能直接使用已下载的资源，而无需等待网络请求。
预加载JavaScript文件：
配合
defer
或
async
，可以确保脚本在HTML解析完成后执行，同时利用
preload
提前获取文件内容。
预加载字体文件：
字体文件通常是渲染阻塞资源，提前加载能显著提升文本显示速度。
crossorigin
属性对于跨域字体是必需的。
预加载图片：
@@##@@
对于首屏可见的大图，预加载可以避免图片突然“跳入”视野的糟糕体验。
as
属性至关重要：它告诉浏览器资源的类型（如
script
,
style
,
image
,
font
等），浏览器会根据这个类型来正确地设置优先级、应用内容安全策略（CSP）以及进行缓存。如果缺少或错误，预加载的效果会大打折扣，甚至可能导致二次下载。
2. 使用
：未来可能需要的资源
与
preload
不同，
prefetch
用于预加载用户“将来可能”会访问的资源。比如，用户可能点击的下一个页面的CSS、JS或图片。它的优先级非常低，浏览器通常会在当前页面加载完成后，并且网络处于空闲状态时才开始下载。
示例：
预取下一个页面的资源：
这在电商网站的商品列表页，预取某个商品详情页的资源就很有用。
3. 使用
：预加载JavaScript模块
这是专门为ES模块设计的预加载方式，它不仅会下载模块文件，还会处理其依赖项，确保模块及其所有依赖都提前准备就绪。
示例：
4. 浏览器原生预加载行为
除了上述显式的
标签，浏览器本身也有一些“聪明”的预加载机制：
@@##@@
标签： 浏览器会扫描HTML中的
@@##@@
标签，自动开始下载图片。
srcset
和
sizes
属性也能帮助浏览器选择最合适的图片进行加载。
标签的
preload
属性： 可以设置为
auto
、
metadata
或
none
，控制视频内容的预加载量。CSS中的
background-image
： 浏览器在解析CSS时，会发现并加载这些背景图片。
defer
和
async
属性： 用于
标签，它们不直接预加载，但能让脚本在不阻塞HTML解析的情况下下载，间接优化了资源的可用性。
5. JavaScript 动态加载
虽然不是纯HTML，但通过JavaScript动态创建元素或使用
fetch
API，也能实现灵活的预加载：
动态创建
image
对象：
const img = new Image();img.src = 'path/to/image.jpg'; // 浏览器会开始下载图片
使用
fetch()
API：
fetch('path/to/data.json') .then(response => response.json()) .then(data => console.log(data));
这可以用来预取API数据。
预加载与预取有什么本质区别？我该如何选择？
在我看来，预加载（
preload
）和预取（
prefetch
）是两个经常被混淆，但其核心意图和应用场景却截然不同的概念。理解它们的差异，对于做出正确的性能优化决策至关重要。
预加载 (
)：当前页面的“救火队员”
本质意图：
preload
是为当前页面服务的。它旨在告诉浏览器，某个资源是当前页面渲染和功能所需的关键部分，但我们希望它能在不阻塞页面初始渲染的前提下，尽早地被下载下来。这就像是消防员在火灾发生前，就把水带、水枪都准备好，一旦需要，立刻就能投入使用。优先级： 浏览器会赋予
preload
的资源较高的优先级，通常与同步加载的资源（比如
或
）优先级相当。它会积极地与当前页面的其他关键资源竞争网络带宽。使用场景：Web字体： 字体文件常常是渲染阻塞的，
preload
能让文本更快地以正确样式显示。关键CSS/JS： 当你希望某个样式表或脚本在特定条件下才应用/执行，但又希望它能提前就位时。首屏图片： 那些在页面加载后立刻就能看到的大图，比如英雄图片（hero image），
preload
能避免图片突然“跳入”视野的糟糕体验。动态加载的模块： 比如某个组件的JS文件，虽然不是初始加载就执行，但用户操作后很快会用到。后果： 如果滥用
preload
，或者预加载了非关键资源，反而可能导致真正的关键资源优先级被挤占，甚至浪费用户带宽。它是有成本的。
预取 (
)：未来页面的“侦察兵”
本质意图：
prefetch
是为未来页面服务的。它告诉浏览器，用户“可能”会在接下来访问某个资源或页面，请在浏览器空闲时悄悄地下载它。这更像是一个侦察兵，提前去探路，为后续的大部队行动做好准备。优先级：
prefetch
的资源优先级非常低。浏览器通常会在当前页面所有关键资源都加载完毕，且网络和CPU都处于空闲状态时，才会开始下载
prefetch
的资源。它不会影响当前页面的性能。使用场景：下一页资源： 比如博客文章列表页，你可以预取下一篇文章的HTML、CSS和JS。搜索结果页： 预取搜索结果中排名靠前的几个链接的资源。购物车/结账页面： 在用户浏览商品详情时，预取购物车或结账页面的关键资源。后果：
prefetch
的风险在于，如果用户最终没有访问预取的资源，那么这些下载就完全是带宽浪费。但由于其低优先级特性，对当前页面性能的影响微乎其微。
如何选择？
我的选择逻辑通常是这样的：
问自己：这个资源是当前页面“必须”的吗？
如果是，且它会影响首屏渲染或用户体验，但又不想阻塞渲染，那么毫不犹豫地选择
preload
。比如，我发现我的Web字体加载慢导致FOUT（Flash of Unstyled Text），那我就用
preload
。又比如，我的首屏有一张巨大的背景图，我肯定会用
preload
。
再问自己：这个资源是用户“可能”在未来访问的吗？
如果是，并且你对用户的行为模式有一定预测，那么可以考虑
prefetch
。比如，我有一个单页应用，用户从A页面点击到B页面的概率很高，我就会在A页面预取B页面的关键JS和数据。但要注意，不要过度预取，否则会变成带宽杀手。
简单来说，
preload
是“现在就要，但请别挡路”，
prefetch
是“将来可能要，你闲着没事就先拿来”。理解这个核心差异，你就能做出更明智的优化决策，让用户体验更上一层楼。
预加载时，
as
as
属性为什么如此重要？如果我忽略它会怎样？
在我看来，
as
属性在
中，简直就是预加载的“灵魂”。它不仅仅是一个简单的类型声明，更像是给浏览器下达的一道精确指令，告诉它如何正确地处理即将到来的资源。如果我忽略它，那就像是告诉一个快递员“我有件包裹，你随便处理吧”，结果往往不尽如人意。
as
属性的重要性体现在以下几个关键方面：
优先级判断与调度：浏览器内部有一套复杂的资源加载优先级算法。它需要知道一个资源是样式表、脚本、图片还是字体，才能为其分配合适的优先级。例如，字体文件（
as="font"
）通常比图片（
as="image"
）拥有更高的优先级，因为字体直接影响文本的可读性。如果没有
as
属性，浏览器就无法准确判断这个资源的类型，可能会将其视为低优先级资源，从而延缓其加载，这与我们预加载的初衷背道而驰。
内容安全策略 (CSP) 的应用：CSP是现代Web安全的重要组成部分，它通过限制页面可以加载的资源类型和来源，来防止跨站脚本攻击（XSS）等。CSP规则通常会针对不同类型的资源（如
script-src
、
style-src
、
font-src
等）设置不同的限制。如果
as
属性缺失或错误，浏览器就无法正确地将预加载的资源与相应的CSP规则匹配，可能导致资源被错误地拦截，或者绕过安全策略，造成安全隐患。
发送正确的
Accept
请求头：浏览器在发送HTTP请求时，会根据资源的类型设置合适的
Accept
请求头。例如，当
as="font"
时，请求头可能会包含
Accept: application/font-woff2
等，这有助于服务器返回正确的内容类型。如果
as
属性缺失，浏览器可能发送一个通用的
Accept
头，导致服务器返回非最优或错误的内容。
资源缓存与重复下载：浏览器会根据资源的类型将其存储在不同的缓存区。例如，字体文件会进入字体缓存，图片会进入图片缓存。如果
as
属性不明确，浏览器可能无法正确地将预加载的资源放入对应的缓存。更糟糕的是，某些情况下，浏览器可能会重复下载资源。例如，一个没有
as="font"
的字体文件可能会被下载一次，当页面真正需要它时（比如通过CSS
@font-face
），浏览器可能因为不确定第一次下载的是什么，而再次发起下载请求，造成带宽浪费。
错误处理与调试：当预加载的资源出现问题时（如404错误），浏览器会根据其类型提供更具体的错误信息。
as
属性的存在有助于开发者更快地定位问题。
如果我忽略
as
属性会怎样？
忽略
as
属性，你可能会遇到以下问题，这些问题都会直接影响你优化页面的努力：
性能下降而非提升： 这是最直接的后果。浏览器无法优化加载顺序，关键资源可能不会被优先下载，导致页面加载速度变慢，用户体验受损。资源被重复下载： 如前所述，浏览器可能无法识别已下载的资源，从而再次发起请求，造成不必要的带宽和时间消耗。内容安全策略问题： 你的预加载资源可能被CSP错误地阻止，导致页面功能缺失或样式错乱。调试困难： 当出现加载问题时，由于信息不明确，定位和解决问题会变得更加复杂。潜在的兼容性问题： 虽然现代浏览器对没有
as
属性的
preload
会有一些默认处理，但这并不保证在所有浏览器版本或所有场景下都能如预期工作。
常见的
as
属性值：
script
: JavaScript文件
style
: CSS样式表
image
: 图片文件
font
: 字体文件
document
: HTML文档（用于iframe）
audio
: 音频文件
video
: 视频文件
track
: WebVTT文件
worker
: Web Worker或Shared Worker脚本
fetch
: 通过
fetch
API获取的资源（如JSON数据）
所以，我的建议是，永远不要省略
as
属性。把它看作是预加载指令中不可或缺的一部分，精确地告诉浏览器你的意图，才能真正发挥预加载的威力。
除了
标签，还有哪些不那么显眼的预加载优化手段？
嗯，说起来，预加载的学问可不仅仅局限于
标签。很多时候，我们还能通过一些不那么显眼，甚至有些“幕后”的手段，来进一步优化资源的加载体验。这就像是除了明面上的宣传，我们还有很多悄悄进行的“公关”工作，最终目标都是让用户更快、更顺畅地获取信息。
浏览器启发式预加载（Parser Preloading）：这是最基础，也是最常被我们忽略的“预加载”。当浏览器解析HTML文档时，它并不会等到整个DOM树构建完成才开始下载资源。相反，它会有一个“预加载扫描器”（preload scanner，有时也称作投机性解析器）。这个扫描器会并行地遍历HTML，发现像
@@##@@
、
、
这样的标签，然后立即开始下载这些资源，而不会等待主解析器。我的理解： 这就像是浏览器自己有个小助手，一边读剧本
以上就是HTML中如何实现预加载的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1574392.html
微信扫一扫 
支付宝扫一扫 
