<link rel="preload">是HTML中唯一标准、可控、不阻塞渲染的预加载方式，但仅负责提前下载，必须配合as属性、静态写入<head>顶部、onload激活等步骤才能生效，否则无效或重复请求。
它不执行、不渲染、不阻塞，只抢在浏览器解析到对应标签前把资源“拉进缓存”——但填错 as、放错位置、预载错资源，反而拖慢首屏。
为什么 link rel="preload" 必须写死在 <head> 里
浏览器在解析 HTML 的第一个字节时就扫描 <head>，遇到 rel="preload" 立刻发起高优先级请求，Initiator 显示为 parser。动态插入（比如 React 的 useEffect 或 jQuery 的 append()）时，DOM 已构建完毕，它退化成普通 fetch()，甚至被节流。
- 验证方法：Chrome DevTools → Network → 找目标资源 → 看
Initiator列是不是parser - 错误写法：
document.head.appendChild(<link rel="preload" href="a.js">)→ 白写 - 正确位置：HTML 模板的
<head>最顶部，比<title>还早更稳妥
as 属性填错会直接失效或重复请求
as 不是语义标签，它决定请求头、CORS 行为、缓存策略和优先级队列。填错等于告诉浏览器“用错方式取这个东西”，结果不是丢弃就是重下。
-
as="font"必须配crossorigin，否则 Chrome/Safari 静默丢弃预加载结果（哪怕同源） -
as="style"和as="script"漏掉，浏览器按as="fetch"处理 → 请求头错、CSP 不匹配、缓存可能不命中 -
as="image"写成as="fetch"→ 图片不会触发解码准备，fetchpriority="high"也无效 - 路径带查询参数必须完全一致，
logo.png?v=1和logo.png?v=2视为两个资源
预加载 CSS 后怎么让它真正起作用
rel="preload" 只下载不解析，CSS 不会自动生效。必须手动触发应用，否则白加载。
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
立即学习“前端免费学习笔记（深入）”；
- 最简方案：
<link rel="preload" href="main.css" as="style" onload="this.rel='stylesheet'"> - 注意：
onload在下载完成时触发，不保证 CSS 已解析完毕；若需 DOM 就绪后再加载，应改用 JS 动态插入<link rel="stylesheet"> - 绝对不要同时写：
<link rel="preload" ...>+ 另一行<link rel="stylesheet" ...>→ Safari/Edge 极易重复请求 - 异步脚本场景下，可在脚本里等需要时再创建
<link rel="stylesheet">，避免阻塞
什么资源值得 preload？别被“预加载”三个字骗了
真正关键的是“当前页面首屏强依赖 + 浏览器默认发现太晚”。不是所有资源都适合，滥用会抢占带宽、增加解析开销、拉低 LCP。
- 适合：
hero.jpg（CSSbackground-image加载，parser 不识别）、font.woff2（防 FOIT）、内联脚本马上要import()的app.js - 不适合：
analytics.js、非首屏轮播图、第三方 widget、用户滚动后才出现的懒加载图 - 判断依据：打开 Network 面板，对比关闭 preload 前后该资源的
Start Time—— 差值不明显（比如 - 字体和图片可加
fetchpriority="high"（Chrome 101+），旧版忽略，无副作用
最难的从来不是写出那行 <link rel="preload">，而是准确判断“这个资源在用户看到首屏前，到底有没有时间差、值不值得抢”。它依赖对加载流水线、CDN 延迟、真实用户设备网络的交叉理解，不是套模板能解决的。
