rel="preload"仅加速关键资源下载时机，不加快HTML解析；必须置于<head>最前、配准as属性且路径严格一致，否则降级为Low优先级fetch，错用反而拖慢首屏。
加 rel="preload" 不会让首屏“解析”变快——它只影响资源下载时机，不加速 HTML 解析本身。真正能缩短首屏时间的，是让关键资源（字体、主 JS、首屏图）在 HTML 解析阶段就发起请求，避免等 parser 慢吞吞扫到 <script> 或 CSS 里的 @font-face 才开始拉。
preload 必须写在 <head> 最前面，紧贴 <meta charset> 后
浏览器一碰到 <link rel="preload"> 就立刻发请求，不等 DOM 构建。放错位置等于白写：
- ✅ 正确：在
<meta charset="utf-8">之后、<title>之前 - ❌ 错误：插在一堆
<link rel="stylesheet">后面，或用 JS 动态document.createElement('link')插入 - ⚠️ 风险：晚 200ms+ 开始下载，3G 网络下首屏 JS 可能错过最佳带宽窗口
as 属性漏写或写错，rel="preload" 就降级成普通 fetch
as 不是可选装饰，它直接决定优先级、CORS 行为和缓存分区。Chrome DevTools Network 面板里 Priority 显示 Low，基本就是 as 问题：
-
as="font"→ 必须同步加crossorigin，否则 Chrome/Safari 加载完也丢弃（哪怕同源） -
as="style"→ 必须配onload="this.onload=null;this.rel='stylesheet'"，否则只下载不生效 -
as="script"→ 必须写死，不能写as="module"或留空；若后续<script src="main.js">带integrity，preload 也得带上相同值，否则缓存不复用 -
as="image"→ 不支持srcset，只适合确定尺寸/格式的单图；对普通<img src>无效，不如直接设fetchpriority="high"
只对“浏览器发现太晚但首屏立刻要用”的资源用 preload
浏览器能自动发现 <img>、<script src>、<link rel="stylesheet"> 里的资源。以下几类常被“藏”着，等解析完 CSS 或 JS 才暴露，导致 FOIT、FOUC 或首屏图延迟：
立即学习“前端免费学习笔记（深入）”；
- ✅ 该用：
@font-face引用的字体（尤其.woff2）、内联<style>里的background-image、紧跟<script type="module">后的主 chunk、首屏<picture>中关键<source> - ❌ 别碰：
analytics.js、非首屏轮播图、第三方 widget 脚本、懒加载模块——它们不参与首屏渲染，纯属带宽干扰 - ⚠️ 特别注意：不要对
<img src>加 preload，不如直接设loading="eager"+fetchpriority="high"
SPA 主 Bundle 必须用 preload，不能用 <script src>
大型单页应用（React/Vue）的首屏主 Bundle（如 main.js）必须走 rel="preload"，否则下载起始时间晚 400–800ms：
-
<script src="main.js">要等 HTML 解析到该标签才发起请求，且阻塞解析 -
<link rel="preload" href="main.js" as="script">在<head>解析阶段就并行下载，抢占网络空闲窗口 - 如果主入口是 ES 模块（
type="module"），且内部有静态import，应改用rel="modulepreload"（它会递归预取依赖，as属性会被忽略） - Webpack/Vite 构建产物带 hash（如
app.a1b2c3.js）会导致 preload 失效，建议对首屏关键 Bundle 禁用 hash 或固定文件名
最容易被忽略的是路径一致性：preload 的 href 必须和后续 JS 中 import() 或 <script type="module"> 写的路径完全一致（包括查询参数），差一个 ?v=1.2 就缓存不命中。
