预加载需严格遵循结构位置和资源类型匹配原则：必须置于<head>中<meta charset>和<title>之后、对应资源标签之前，as值须准确（如font/css/script/image），漏写或错写将导致无效、重复请求或优先级错误。
预加载不是加了就快，关键在于结构位置和资源类型是否匹配。把 <link rel="preload"> 放错地方、选错 as 值，轻则无效，重则抢带宽、拖慢首屏。
preload 必须放在 <head> 里且紧靠 charset 后
浏览器只在解析 <head> 阶段读取 preload 指令，如果它出现在 <body> 或靠后位置，等解析到时关键资源可能已开始下载，指令被忽略。
-
<meta charset="utf-8">必须是<head>中第一个标签（或紧随<title>后），否则编码识别延迟会触发重解析，连带让 preload 失效 - preload 标签应放在
<meta charset>和<title>之后、其他<link rel="stylesheet">之前——越早声明，浏览器越早发起请求 - 不要用 JS 动态插入 preload：
document.head.appendChild(...)完全无效，它不参与初始 HTML 解析流
as 属性写错会导致重复请求或优先级错乱
浏览器靠 as 值决定如何调度请求、复用连接、设置缓存策略。漏写或写错，preload 就等于白加。
- 字体必须写
as="font"且带crossorigin属性，否则因跨域限制被丢弃：<link rel="preload" href="font.woff2" as="font" type="font/woff2" crossorigin> - CSS 文件必须用
as="style"，写成as="fetch"或不写，会导致浏览器按低优先级处理，甚至与后续<link rel="stylesheet">重复下载 - JS 文件用
as="script"，但注意：它不会自动执行，只是提前下载；真正执行仍由<script>标签控制 - 图片用
as="image"，配合media可条件触发，比如<link rel="preload" href="hero.jpg" as="image" media="(min-width: 768px)">
preload 和普通 link stylesheet 的顺序不能颠倒
如果先写 <link rel="stylesheet" href="main.css">，再写 <link rel="preload" href="main.css" as="style">，浏览器会把它当两个独立请求处理，造成重复下载。
立即学习“前端免费学习笔记（深入）”；
- preload 必须出现在对应资源的正式
<link>或<script>标签之前 - 常见错误：在构建工具中自动生成 preload，却没确保它插入在最终 HTML 的正确位置；建议手写或用模板引擎严格控制顺序
- Chrome DevTools Network 面板里，preload 请求显示为
Priority: high，而普通样式表是Priority: medium——这是验证是否生效的最快方式
非首屏资源别硬塞 preload
preload 是“现在就要”，不是“以后可能用”。对轮播图第二张图、折叠区域内的 JS、用户点击才展开的模块资源加 preload，只会挤占关键资源的网络带宽和 HTTP/2 流。
- 只对 FCP（首次内容绘制）前必须就位的资源使用：首屏大图、关键字体、阻塞渲染的 CSS、初始化首屏组件的 JS
- prefetch 才适合“下一页可能用”的资源，比如详情页的评论模块
comments.js，它走的是空闲优先级，不影响当前页 - 移动端尤其要谨慎：4G 网络下，一个误用的 preload 可能多占 200ms 有效带宽，直接拉高 LCP
最容易被忽略的是 crossorigin 对字体的影响，以及 as 值缺失导致的重复请求——这两点在 DevTools 里看不到明显报错，但资源加载行为已经出错。优化不是堆指令，而是让每个 preload 都有明确的“为什么现在就要”。
