如何正确运用HTML的preload标签高效预加载网页关键资源？

本文共计1184个文字，预计阅读时间需要5分钟。

《preload 不是所有相关关键资源都加一轮，而是仅对浏览器发现太晚、又必须立即使用的资源生效；加错反而拖慢首屏。

哪些资源真该用 preload

浏览器在解析 HTML 时，只能自动发现 <img>、<script src>、<link rel="stylesheet"> 这些标签里的资源。但以下几类常被“藏”在 CSS 或 JS 里，直到解析完才被发现，导致 FOIT、FOUC 或首屏图片延迟：

• CSS 中 @font-face 引用的字体文件（尤其 WOFF2）
• 内联 <style> 里用到的、但没在 HTML 中显式声明的首屏图片 URL
• 紧随其后的 <script type="module"> 所依赖的主 chunk（如 app.js），而它本身没写 src 属性
• Hero 区域的 <picture> 中关键 <source> 对应的 WebP/JPEG 图片

这些才是 preload 的合理作用域。不是“所有 .js 都 preload”，更不是“把 webpack 打包出的 20 个 chunk 全写进去”。

as 属性填错等于白写

as 不是可选装饰，它直接决定浏览器如何发起请求：请求头（Accept）、CSP 校验、缓存分区、甚至是否允许跨域。填错就降级为普通 fetch，失去预加载意义。

立即学习“前端免费学习笔记（深入）”；

• as="font" → 必须带 crossorigin，否则 Chrome/Safari 直接忽略（即使同源）
• as="style" → 触发 Accept: text/css，且后续 <link rel="stylesheet"> 能复用该响应；别对 rel="stylesheet" 的 link 再套一层 preload，可能触发二次解析
• as="image" → 支持 fetchpriority="high"（Chrome 101+），但不支持 srcset 或 sizes，所以只适合确定尺寸和格式的单图
• as="script" → 只下载不执行；若后续仍用 <script src> 引入同一 URL，浏览器会复用；但若脚本含 type="module" 且有 integrity，preload 也得带上该属性，否则缓存不匹配

常见错误现象与验证方式

写了 preload 标签不等于生效。打开 Chrome DevTools → Network 面板，筛选目标资源名，重点看三列：

• Initiator：应显示 preload，不是 parser 或 script；如果是后者，说明浏览器没把它当预加载处理
• Priority：字体/JS 应为 Highest，CSS/图片为 High；若显示 Low 或 Medium，大概率是 as 没写或写错
• Size 和 Time：对比未加 preload 时同资源的起始时间，理想应提前 200–600ms；若看到 pending 或 canceled，可能是 HTTP/2 推送已发、或 preconnect 未就绪就发了请求

特别注意 Safari：它对 as="font" 的 crossorigin 更严格，漏写或写成 crossorigin="" 都可能失效；同时 Safari 会忽略 fetchpriority，但不影响 preload 本身。

动态插入 preload 要小心

服务端无法预知的资源（如按用户设备加载高清图、AB 实验脚本），需 JS 动态插入 <link rel="preload">。但有两个硬约束：

• 必须在 DOMContentLoaded 前插入，越早越好；动态插入太晚（比如在 load 事件后），Chrome 可能直接忽略
• 插入前先检查是否已存在相同 href 的 preload 标签，避免重复创建（尤其是单页应用路由切换时）
• 不要用 new Image().src = url 替代 —— 它无法监听失败，也不进 HTTP 缓存，更不会被后续 <img> 复用

真正容易被忽略的是：preload 只解决“下载时机”，不解决“使用时机”。比如预加载了字体，但 CSS 里没配 font-display: swap，照样 FOIT；预加载了图片，但没在 <img> 上设 width/height，懒加载时仍会 CLS。这些必须配套落地，preload 才算闭环。