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

preload 该用在哪些资源上？

link rel="preload" 不是给所有资源加就完事的。它只适合那些当前页面渲染强依赖、且浏览器默认发现较晚的资源，比如：

• 关键字体（font，特别是 display: swap 场景下防 FOIT）
• 首屏 Hero 图的 image（尤其是通过 CSS background-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

常见错误：

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

生成HTML格式PPT

从零开始创建惊艳、动画丰富且自包含的 HTML 演示文稿，或通过转换 PowerPoint 文件生成。当用户希望制作幻灯片、构建演示文稿、打造路演资料（pitch deck）、将 PPT/PPTX 转换为网页格式，或增强现有 HTML 演示文稿时，应使用此能力。该能力帮助用户通过视觉预览而非抽象选项来发掘自身审美偏好。

下载

• 忘加 crossorigin 导致字体加载失败（控制台报 CORS error）
• as="fetch" 乱用（不存在这个值，应按真实资源类型填）
• 把 preload 放在 body 里（部分浏览器忽略，必须在 head 中尽早声明）

preload 和 prefetch / preconnect 怎么选？

三者用途完全不同，混用会浪费资源：

• 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"）会被忽略，只认标准值