HTML如何预加载资源_HTML link rel=preload用法【指南】

HTML如何预加载资源_HTML link rel=preload用法【指南】需要先看清适用场景和关键步骤，避免只记结论却忽略实际限制。

preload适用于当前页面首屏强依赖资源，如关键CSS、Web Font、内联前JS等；prefetch用于下页可能用到的资源；普通link会阻塞渲染。as属性必须准确匹配资源类型（如font需as="font"+crossorigin），否则失效。

用 link rel="preload" 能提前触发关键资源下载，但不执行、不阻塞渲染——前提是路径正确、as 类型匹配、且资源确实在后续 HTML/CSS/JS 中被实际用到，否则就是白忙活。

什么时候该用 preload，而不是 prefetch 或普通 link？

核心区别在「时机」和「用途」：preload 是告诉浏览器“这个资源我马上就要，现在就下”，适用于当前页面首屏强依赖的字体、关键 CSS、内联前的 JS、Web Worker 脚本等；prefetch 是“可能下个页面要用”，由浏览器按空闲程度决定是否加载；普通 link（如 rel="stylesheet"）则会阻塞渲染直到加载并解析完成。

常见误用场景：

1. 把非首屏图片或懒加载模块的 JS 用 preload —— 浪费带宽，还可能挤占真正关键资源的请求带宽
2. 对已通过 import() 动态导入的代码做 preload —— 浏览器无法静态分析依赖，preload 不会被触发
3. 用 prefetch 替代 preload 加载首屏 Web Font —— 字体加载延迟直接导致 FOIT/FOUT 加剧

as 属性必须填对，否则浏览器会忽略或降级处理

as 不是可选提示，而是强制声明资源类型。浏览器靠它决定请求优先级、CSP 策略、是否复用连接、是否允许跨域凭据等。填错等于没写。

典型对应关系：

1. CSS 文件 → as="style"（不是 "stylesheet"）
2. 字体（WOFF2/WOFF）→ as="font"，且必须加 crossorigin 属性（字体加载默认匿名模式）
3. JS 脚本 → as="script"；如果是模块脚本，用 as="script" type="module"
4. 关键 JSON 数据（如初始化配置）→ as="fetch"，并配 crossorigin（fetch 请求默认带凭据）

错误示例：<link rel="preload" href="/main.js" as="javascript"> —— as="javascript" 无效，浏览器无视该标签。

路径、HTTP 状态码和缓存头直接影响预加载是否生效

preload 是独立 HTTP 请求，和后续真实使用时的请求完全解耦。哪怕 HTML 里写了 preload，只要资源返回 404、500、重定向或缓存头禁止缓存（如 Cache-Control: no-store），浏览器就不会把预加载结果用于后续使用。

调试要点：

1. 检查 Network 面板：确认 preload 请求状态码为 200，且响应头含 content-length 和合理 cache-control
2. 避免相对路径歧义：用 /assets/font.woff2 而非 ./font.woff2，防止当前 URL 带查询参数时路径解析出错
3. 服务端不要对 preload 请求做特殊拦截（比如某些 CDN 会过滤无 User-Agent 的请求）

一个易忽略点：如果预加载的字体文件被 Service Worker 拦截但未正确 respondWith()，页面后续实际使用时会 fallback 到系统字体。

Chrome DevTools 里怎么验证 preload 是否起作用？

打开 DevTools → Network → 刷新页面 → 筛选 Preload 列（需右键表头勾选），看是否有对应资源；再点开该请求，确认 Initiator 显示为 HTMLParser（说明来自 link 标签），而非 Script 或其他。

更关键的是比对时间线：

1. 找到后续真实使用该资源的时机（比如 CSS 中 @font-face 触发字体加载、script 标签执行）
2. 确认其发起时间晚于 preload 完成时间，且复用同一 connection（Connection ID 相同）
3. 若看到两个独立请求（一个 Preload，一个 Fetch），说明浏览器没复用——大概率是 as 错了或 CORS 不匹配

真正难调的不是写法，是让浏览器“信你”，然后安静地复用那个预加载下来的字节流。