link rel="preload"是提升首屏关键图片加载速度最直接可靠的方式，仅适用于banner、登录页主视觉等lcp相关图片，需写在中、href为静态url、as="image"必填，滥用会抢占带宽拖慢首屏。
link rel="preload" 是提升首屏图片加载速度最直接、最可靠的方式，但它只在你明确知道哪张图会影响 LCP（最大内容绘制） 时才该用——不是所有图都适合 preload，滥用反而拖慢页面。
什么时候必须用 link rel="preload"？
适用于 banner、登录页主视觉、产品首图这类「用户一打开就该立刻看到」的图片。它不渲染、不占布局，只提前发起请求进缓存，且能被浏览器 preload scanner 在 HTML 解析早期捕获。
-
href必须是最终 URL（不能含模板变量，如"/assets/${name}.webp"） - 必须写在
里，越靠前越好；放在或 JS 动态插入无效 -
as="image"缺一不可——缺了会被当成普通 fetch，失去图片解码和缓存策略 - 可加
fetchpriority="high"（Chrome 101+ 支持），旧版忽略无副作用
为什么不能把所有图都 preload？
preload 会抢占主文档、CSS、关键 JS 的带宽和连接数。实测中，预加载超过 2 张大图，首屏渲染时间反而上升 15%~30%，尤其在 3G/4G 弱网下更明显。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 浏览器对
preload请求没有优先级降级机制，它永远“插队” - CDN 带宽有限，大量 preload 可能挤掉真实用户请求
- Lighthouse 会警告 “Preload key requests” 数量超标，影响性能评分
new Image() 适合什么场景？
当你需要根据运行时条件决定是否预加载时，比如 hover 后预载下一页缩略图、按 window.devicePixelRatio 加载 @2x 版本、或结合 IntersectionObserver 提前加载即将进入视口的图。
- 必须先绑定
onload/onerror，再赋值src，否则缓存命中时事件直接同步触发，回调被跳过 - 检查
img.complete === true，为 true 说明已缓存，需立刻执行成功逻辑 - 避免密集
new Image()，建议限制并发数（如每次最多 4 个），用 Promise 控制队列
常见失效原因：写了但没生效
很多项目加了 preload 却没提速，问题往往藏在路径、格式或冲突属性里：
- 相对路径写错：HTML 在
/user/profile.html，却写href="./images/hero.jpg"→ 应改为href="/images/hero.jpg" - 格式 fallback 没兜底：
preload用.webp，但没配<picture></picture>或<img>兜底，老浏览器直接白屏 - 和
loading="lazy"冲突：给同一张图既preload又loading="lazy"，逻辑矛盾，Chrome 可能忽略 preload - 服务端没开 HTTP/2：多个 preload 请求在 HTTP/1.1 下会排队，失去并行优势
真正难的不是写那行 link 标签，而是判断哪张图值得抢跑、在哪种网络条件下该降级、以及如何验证它确实进了缓存而不是被浏览器悄悄丢弃。这些没法靠配置自动完成，得看 Network 面板里的 Initiator 和 Timing，再结合真实设备上的 LCP 测量。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
