html预加载需以资源优化为前提，否则会抢占带宽、浪费资源；必须配合体积压缩、http/2+与缓存策略，且url须完全一致。
HTML 预加载（<link rel="preload">）本身不“需要”资源优化才能运行，但它只有在资源本身已合理优化的前提下，才能真正发挥加速效果；否则可能白忙一场，甚至拖慢首屏。
为什么 preload 会放大未优化资源的问题
预加载强制浏览器提前发起请求，但不会改变资源体积或解析开销。如果预加载一个 2MB 未压缩的 font.woff2 或未裁剪的 hero-banner.jpg，它会抢在其他关键资源前占满带宽，导致 main.js 或 style.css 延迟下载。
- 预加载不跳过解码/渲染流程——大图仍要解码，大字体仍要解析布局表
- 浏览器对同一域名并发请求数有限（通常 6 个），
preload占用一个槽位，就少一个给fetch()或<img> -
preload不带条件逻辑，即使用户滚动不到某模块，其预加载的 JS/CSS 也已下载并解析完毕（浪费内存和 CPU）
preload 只应作用于明确的关键路径资源
不是所有“想快一点”的资源都适合预加载。必须满足：当前 HTML 文档立即需要、且浏览器默认发现时机太晚（比如 CSS 中的 @font-face 字体、异步 JS 中的动态 import() 模块）。
- ✅ 推荐：
<link rel="preload" href="heading-font.woff2" as="font" type="font/woff2" crossorigin>（字体在 CSS 中引用，但浏览器直到解析 CSS 才知道要加载） - ✅ 推荐：
<link rel="preload" href="hero-video.mp4" as="video" type="video/mp4">（首屏视频需秒开） - ❌ 避免：
<link rel="preload" href="analytics.js">（非关键、可 defer） - ❌ 避免：
<link rel="preload" href="large-carousel.js">（用户可能永不触发轮播）
必须配合的三项基础优化，否则 preload 效果归零
单独加 preload 标签，就像给一辆没换轮胎、没调胎压、油箱还半空的车猛踩油门——发动机响了，车不动。
-
资源体积压缩：字体用
woff2+fonttools子集化；图片用sharp或squoosh调参导出，WebP/AVIF 优先；JS/CSS 开启 Terser/Webpack 的minify -
服务端支持：确保 HTTP/2 或 HTTP/3 启用（避免队头阻塞），服务器返回
Content-Encoding: gzip或br，且Vary: Accept-Encoding正确设置 -
缓存策略对齐：预加载资源的
Cache-Control至少为public, max-age=31536000（1 年），避免重复下载；字体尤其注意加immutable
最常被忽略的一点：预加载的资源 URL 必须与后续实际使用的 URL 完全一致（包括查询参数、大小写、斜杠结尾）。浏览器不会把 logo.png?v=1 和 logo.png?v=2 当作同一个缓存项，哪怕只差一个字符，preload 就失效了。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
