preload 应用于首屏强依赖且浏览器默认发现晚的资源,如关键字体、Hero图、内联脚本即将加载的核心JS、动态插入的关键CSS;须配as属性和正确路径,禁用于非关键资源。

preload 该用在哪些资源上?
link rel="preload" 不是给所有资源加就完事的。它只适合那些当前页面渲染强依赖、且浏览器默认发现较晚的资源,比如:
- 关键字体(
font,特别是display: swap场景下防 FOIT) - 首屏 Hero 图的
image(尤其是通过 CSSbackground-image加载时,浏览器 parser 不会主动预发现) - 内联 script 中马上要
fetch或import()的核心 JS 模块(如vendor.js、app.js) - 关键 CSS(但更推荐直接
link rel="stylesheet",除非是异步加载逻辑中动态插入的)
别对 analytics.js、非首屏图片、第三方 widget 脚本用 preload——它们不参与首屏渲染,反而抢占带宽,可能拖慢真正关键资源。
写法不对会导致 preload 失效甚至变负优化
preload 必须配齐 as 属性,否则浏览器无法正确设置请求优先级和 CORS 策略:
- 字体必须写
as="font"+crossorigin(即使同源,WOFF2 解析也强制触发 CORS) - 图片用
as="image",JS 用as="script",CSS 用as="style" -
href值必须与最终实际加载路径完全一致(含查询参数),否则不会命中缓存,等于白 pre
常见错误:
- 忘加
crossorigin导致字体加载失败(控制台报CORS error) -
as="fetch"乱用(不存在这个值,应按真实资源类型填) - 把
preload放在body里(部分浏览器忽略,必须在head中尽早声明)
preload 和 prefetch / preconnect 怎么选?
三者用途完全不同,混用会浪费资源:
实现 Markdown↔ HTML 互转,支持导出 PDF,用于用户请求的文档格式转换。
-
preload:「我马上就要用这个资源,现在就去取」→ 当前导航生命周期内必用 -
prefetch:「用户可能点进下一页才需要,空闲时悄悄下」→ 低优先级,可被丢弃 -
preconnect:「我要连这个域名,先建好 TCP/TLS,省得后面卡握手」→ 只写href域名,不指定资源路径
典型组合:
- 对 CDN 上的字体
preconnect+ 同时preload具体字体文件 - 对 API 域名只
preconnect,不要preload某个接口 URL(HTTP 请求不可预加载)
怎么验证 preload 是否生效?
打开 Chrome DevTools → Network 标签页 → 刷新页面 → 找对应资源:
- 如果看到
Initiator列显示preload,说明已触发 - 查看
Priority列是否为Highest(字体/脚本)或High(图片) - 对比关闭
preload后的资源开始下载时间(Start Time),差值明显才说明有收益
容易被忽略的点:
- 移动端 4G 网络下,
preload效果比桌面更显著,但若预加载了大图又没做尺寸适配,反而造成流量浪费 - Webpack/Vite 构建工具生成的
index.html中,preload往往由插件自动注入,但插件可能误把 polyfill 或 debug 脚本也加进去,需人工核对as和路径 - Safari 对
preload的支持较保守,某些as值(如as="text")会被忽略,只认标准值
前端入门到VUE实战笔记:立即使用
在学习笔记中,你将探索 前端 的入门与实战技巧!










