深入解析Preload资源预加载原理与实战优化技巧
公孙世霖我的写法，亲测靠谱
在做性能优化时，preload 是我最常拿来“救急”的手段之一。特别是首页加载卡顿、关键资源延迟渲染的问题，加个 preload 往往立竿见影。但说实话，一开始我也踩过不少坑——不是没效果，就是反而拖慢了页面。折腾了几个项目后，现在我基本固定了一套写法，稳定、可控、不翻车。
我一般只对真正关键的资源用 preload，比如首屏要用的字体、核心 JS bundle、或者一张 hero 图。而且一定要配合 as 属性，不然浏览器不知道怎么处理，可能白预加载了。下面是我现在项目里最常用的写法：
<link rel="preload" href="/fonts/inter.woff2" as="font" type="font/woff2" crossorigin>
<link rel="preload" href="/js/main.chunk.js" as="script">
<link rel="preload" href="/hero-banner.jpg" as="image">注意几个细节：字体必须加 crossorigin，哪怕是你自己域名下的。因为字体默认是跨域请求（即使同源），不加这个属性，preload 会失败，浏览器会重新发起一次普通请求，等于白干。这点我踩过两次坑，第一次还以为是 CDN 配置问题，查了半天才发现是少了 crossorigin。
另外，type 属性虽然不是必须，但我建议加上，尤其是字体和视频这类资源。浏览器能更快判断是否支持，避免下载了不兼容的格式。比如 woff2 不支持的老浏览器，看到 type="font/woff2" 就直接跳过，省流量也省时间。
这几种错误写法，别再踩坑了
我在 review 代码时，经常看到下面这些“看似合理”实则有害的写法，分享出来帮你避雷。
错误 1：把所有 JS/CSS 都 preload
有人觉得“反正能提前加载，多加点没坏处”，于是把十几个 chunk 全部塞进 preload。结果呢？浏览器优先级队列被占满，真正关键的资源反而排后面了。preload 资源会占用高优先级通道，太多反而造成阻塞。我见过一个页面 preload 了 8 个 JS 文件，导致主 HTML 解析都变慢了——因为网络带宽被 preload 占据，HTML 本身反而下得慢。
错误 2：preload 了却没用上
浏览器对未使用的 preload 资源会报 warning，比如 “The resource was preloaded but not used within a few seconds”。这不仅浪费带宽，还可能触发 Lighthouse 的性能扣分。我之前有个组件按需加载，误把它的 JS 也 preload 了，结果用户根本没触发那个功能，资源白下了。后来我加了个检查：只有确定会在 3 秒内用到的资源，才考虑 preload。
错误 3：用 JavaScript 动态创建 preload link
有些人喜欢这样写：
const link = document.createElement('link');
link.rel = 'preload';
link.as = 'script';
link.href = '/late-load.js';
document.head.appendChild(link);表面上看没问题，但实际效果大打折扣。因为这时候 HTML 已经解析完了，preload 的时机太晚，失去了“提前抢占网络”的意义。preload 最大的价值是在 HTML 解析阶段就告诉浏览器：“接下来你会用到这个，先准备着”。动态插入等于放弃了这个优势。除非你有非常特殊的场景（比如基于用户行为预测），否则别这么干。
错误 4：preload 图片但没指定尺寸
对于图片，如果只是 preload 但没在 <img> 上指定 width 和 height，可能会引发布局偏移（CLS）。虽然 preload 本身不直接导致 CLS，但它让图片加载更快，如果尺寸未知，图片突然撑开页面，反而更糟。所以我的做法是：preload 图片的同时，确保 img 标签有明确的宽高（或通过 CSS 固定容器尺寸）。
实际项目中的坑
除了上面那些通用问题，我在真实项目里还遇到过几个“隐藏陷阱”。
第一个是关于缓存的。preload 的资源会走缓存，但如果你的缓存策略没配好，比如 max-age=0 或 no-cache，那每次都会重新请求，preload 就失去意义了。我建议对 preload 的资源设置较长的缓存时间，比如一年，并配合文件 hash 命名（如 main.a1b2c3.js），这样既能长期缓存，又能在内容变更时更新 URL。
第二个是和 HTTP/2 Push 混用的问题。以前我们用 HTTP/2 Server Push 来“推送”资源，现在基本没人用了，因为容易过度推送。但如果你的服务器还在用 Push，同时又加了 preload，可能会导致资源被加载两次。我之前在一个老项目里就遇到过，Lighthouse 报告显示某个 JS 被加载了两次，最后发现是 Nginx 配了 Push，前端又写了 preload。解决方案很简单：二选一，我选了 preload，因为更可控。
第三个是 Safari 的兼容性。虽然现代浏览器都支持 preload，但 Safari 对 as="image" 的支持有点迟。在 iOS 11 之前的版本，preload 图片可能无效。不过现在 iOS 15+ 已成主流，这个问题基本可以忽略。但如果你的用户群包含大量老旧设备，建议做个 feature detect：
if ('preload' in document.createElement('link')) {
// 支持 preload
}不过说实话，我一般懒得做这个检测，因为不支持的浏览器会直接忽略 rel="preload"，不会报错，顶多就是没优化效果，不影响功能。
什么时候不该用 preload？
不是所有资源都值得 preload。我给自己定了几条规则：
- 非首屏资源？别 preload。
- 体积小于 2KB 的资源？没必要，DNS/TCP 开销可能比资源本身还大。
- 不确定用户是否会用到？比如后台管理页的某个功能模块？别 preload。
- 已经通过
<script>或<link rel="stylesheet">正常引入的资源？除非它被 defer 或 async 了，否则不需要额外 preload。
举个例子，我之前有个项目把一个 50KB 的 analytics.js preload 了，结果发现它本来就在 <head> 里用 async 加载，preload 反而让它更早抢带宽，影响了主内容。后来直接删了 preload，性能反而更好。
另外，preload 不是万能的。如果服务器响应慢（TTFB 高），preload 也救不了你。我见过团队花半天调 preload，结果瓶颈在后端 API 响应要 2 秒。先解决 TTFB，再考虑资源加载优化，顺序别搞反了。
结尾碎碎念
以上是我这几年用 preload 总结下来的经验，大部分来自血泪教训。preload 用得好，能提升 FCP、LCP；用不好，反而拖累性能。关键就两点：**精准 + 节制**。只对真正关键、且即将使用的资源使用，别贪多。
目前我的方案虽然不是理论最优，但在多个项目中验证过，稳定有效。如果你有更好的实践，比如结合 Webpack 的 prefetch/preload 插件做自动化，或者用 Intersection Observer 动态 preload 视口外的图片，欢迎在评论区交流。这个技巧的拓展用法还有很多，后续会继续分享这类实战博客。
