首屏关键图片（如banner、logo）必须用提前加载，而非loading="lazy"；后者适用于折叠区以下非核心图片，二者目标相反，混用会抵消性能收益。
什么时候该用 link rel="preload" 而不是 loading="lazy"
预加载（preload）和懒加载（loading="lazy"）解决的是完全相反的问题：preload 是“提前拿”，loading="lazy" 是“晚点再拿”。首屏关键图片（比如 banner 图、登录页头像、商品主图）必须在 DOM 解析早期就发起请求，否则会拖慢 LCP（最大内容绘制）。这时候 loading="lazy" 反而会害了性能——它会让浏览器主动延迟加载，哪怕图片就在视口里。
判断标准很简单：
- 图片出现在首屏且影响 LCP → 用
preload - 图片在折叠区以下或非核心路径 → 用
loading="lazy" - 不确定是否关键？先测 Lighthouse，看“Largest Contentful Paint element”具体是哪个
img，再决定
preload 的 as 属性必须写对，否则可能被忽略或降级
浏览器只在明确知道资源类型时，才能正确分配优先级、解码器和缓存策略。如果漏掉 as="image"，Chrome 会把它当作普通脚本请求处理，不进图像解码流水线，甚至可能阻塞其他高优请求。
常见错误写法：
<link rel="preload" href="hero.jpg">
正确写法（必须带 as）：
<link rel="preload" href="hero.jpg" as="image">
其他常用值：
- 字体：
as="font"（还需加crossorigin） - CSS：
as="style" - 关键 JS：
as="script" - Web Worker：
as="worker"
注意：as="image" 不支持响应式 srcset，所以不要试图用它预加载 picture 元素里的多尺寸图——它只认单个 URL。
预加载图片的时机和位置很关键，放错地方等于白写
link rel="preload" 必须放在 中，越靠前越好（最好在 <title></title> 后立即写），因为它的作用就是让浏览器在解析 HTML 的第一毫秒就发现这个请求。
常见踩坑点：
- 写在
里 → 浏览器解析到那里才开始预加载，失去意义 - 写在异步 JS 动态插入的
link中 → 完全无效，preload不支持运行时注入 - 预加载了但 HTML 里没真正使用（比如
href和实际img.src不一致）→ 浏览器不会复用，变成冗余请求 - 同一张图既
preload又prefetch→ 可能触发重复下载，尤其在弱网下
预加载不是万能的，滥用反而拖慢页面
浏览器对 preload 请求有严格的并发数限制（通常 6 个左右），且它会抢占带宽和连接。如果你一口气预加载 10 张图，其中 7 张根本不在首屏，结果就是关键资源排队、TCP 连接耗尽、TTFB 延长。
实操建议：
- 只预加载真正影响 LCP 的 1–3 个资源（通常是 1 张主图 + 1 个关键字体）
- 避免预加载 WebP/AVIF 格式却在
img中回退到 JPEG —— 浏览器不会自动格式转换，预加载的图会被丢弃 - 服务端开启 HTTP/2 或 HTTP/3 时，
preload效果更稳定；HTTP/1.1 下容易因队头阻塞失效 - 用 Chrome DevTools 的 Network 面板过滤
preload，确认它确实在 early timing（initiator 是 Parser）且 status 200
最常被忽略的一点：预加载不能替代图片压缩和格式升级。一张没转 WebP 的 2MB JPG，就算 preload 了，用户照样要等 3 秒解码。优化永远要从资源本身下手，preload 只是调度器，不是加速器。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
