首屏图片延迟加载易卡顿，因html线性解析导致图片请求滞后，lcp下降；preload可抢跑下载，但须严格满足as="image"、静态href、置于head最前且url与img完全一致。
为什么图片在首屏出现才加载就容易卡
浏览器解析 HTML 是线性的，<img src="banner.jpg"> 这行代码没被 parser 读到，浏览器根本不知道要请求这张图。等它解析到 里那个 <img> 标签时，可能已经过了 300–600ms —— 这段时间里 banner 一直空白，LCP 直接拉胯。
更糟的是，如果 banner 图片还依赖 CSS（比如用 background-image 声明），那还得等 CSS 文件下载、解析完才能发现它，延迟翻倍。这时候 rel="preload" 就是唯一能“抢跑”的手段：它让浏览器在 解析阶段就发起请求，不等 DOM 构建，也不等样式计算。
preload 图片必须写对这三件事
rel="preload" 对图片不是“加了就行”，漏掉任一条件，它就静默退化成普通 fetch，Network 面板里 Initiator 显示为 (Other)，Priority 是 Low，和没写一样。
-
as="image"必须写，且只能是"image"（"img"或"picture"全部无效） -
href必须是静态路径，不能含 JS 变量、模板字符串或表达式，例如href="/assets/${name}.jpg"会直接失败 - 必须放在
最前面，紧贴<meta charset>后或<title></title>前；动态插入（如document.createElement('link')）完全无效
preload 后图片怎么真正显示出来
rel="preload" 只负责下载并进缓存，它不创建 DOM、不触发渲染、不调用 onload。所以你不能指望它“自动展示”——它只是确保资源在需要时已就位。
常见错误是：既写了 <link rel="preload" href="logo.webp" as="image">，又写了 <img src="logo.webp">，结果因路径大小写/斜杠差异（比如一个是 /logo.webp，另一个是 logo.webp）导致二次请求。
正确做法很简单：
- 确保
<link>和<img src>的 URL 完全一致（包括协议、域名、路径、查询参数） - 首屏关键图显式加
loading="eager"，避免被懒加载框架拦截 - 不需要额外 JS 控制；浏览器会在
<img>解析到时直接从缓存取，毫秒级解码渲染
哪些图值得 preload，哪些纯属浪费带宽
不是所有图片都该 preload。它抢占 TCP 连接和带宽，瞎加反而拖慢首屏。
- ✅ 应该 preload：
<img>在首屏视口内、且 HTML 中位置靠后（比如在<main></main>底部）；CSS 中@font-face引用的字体；background-image关键 banner - ❌ 不该 preload：懒加载区域的图、
srcset中非首屏尺寸、图标（<link rel="icon">浏览器自动处理）、第三方 CDN 图（除非你控制响应头并配好 CORS） - ⚠️ 警惕跨域图：若
href是跨域地址，服务端必须返回Access-Control-Allow-Origin，否则即使下载成功也不会解码显示
最常被忽略的一点：preload 的资源必须被页面真实使用。Lighthouse 会标记“未使用的预加载资源”，而浏览器也可能在空闲时丢弃它——别把它当成缓存兜底方案。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
