关键图片必须同时满足三条件：用户打开后1秒内必然展示、尺寸路径固定、不依赖js渲染；仅预加载≤3张首屏核心图，webp需配fallback，new image()须先绑事件再赋值src并检查complete。
关键图片必须在 HTML 解析早期就声明预加载，不能靠 JS 运行时判断再发起——否则首屏已渲染完毕，预加载失去意义。
哪些图算“关键图片”？看是否满足三个硬条件
不是所有首屏 <img> 都值得预加载，真正该进 <link rel="preload"> 的只有同时满足以下三点的资源：
- 用户打开页面后 1 秒内必然展示（比如 banner、logo、登录框主图）
- 尺寸固定、路径确定（不能含
${name}.webp这类模板变量） - 不依赖 JS 渲染逻辑（即 SSR 或静态 HTML 中已明确存在）
常见误判：轮播图第二张图、Tab 切换后才显示的图、由 React/Vue 动态插入的 <img> —— 这些应交给 new Image() 在对应状态触发，而非塞进 。
preload 路径写错会导致 404，但浏览器不报错
<link rel="preload"> 的 href 是纯字符串解析，出错静默失败。典型问题：
- HTML 在
/user/profile.html，却写href="./images/hero.jpg"→ 实际请求/user/images/hero.jpg，而真实路径是/images/hero.jpg - 用 WebP 格式但没 fallback：
href="/assets/hero.webp"在 Safari 13 以下直接 404，且无降级机制 - 路径含空格或中文未编码：
href="/assets/头像.jpg"→ URL 解析失败
验证方式：打开 Network 面板，过滤 Preload 类型请求，看 status 是否为 200；若为空白或 404，说明路径失效。
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
并发预加载太多会抢带宽，反而拖慢首屏
浏览器对 preload 请求有隐式优先级调度，但同一域名下并发连接数仍受限制（通常 6~8）。如果一口气写 10 个 <link rel="preload">：
- Chrome 可能将部分请求降级为
Priority: low，实际加载顺序不可控 - 和关键 CSS/JS 请求争抢 TCP 连接，导致渲染阻塞延长
- Lighthouse 会警告 “Avoid enormous network payloads”，评分下降
实操建议：首屏只预加载 ≤3 张图（banner + logo + 主行动按钮图标），其余交由 new Image() 按需触发；WebP 图片必须配 <picture></picture> fallback，不能只靠 preload 单一路径。
缓存命中时 new Image() 的 onload 不触发，容易漏处理
用 new Image() 做运行时预加载，最常踩的坑是事件绑定顺序和缓存状态判断：
- 错误写法：
img.src = url; img.onload = () => {}→ 若图片已在缓存中，onload同步触发，但此时回调还没绑定，直接丢失 - 正确顺序：先绑
onload/onerror，再赋值src，然后立刻检查img.complete === true - 漏掉
complete判断，会导致缓存命中时逻辑卡死，用户操作后图片迟迟不出现
真正要预加载的图，往往已经存在于用户缓存里（比如重复访问），所以 img.complete 分支不是边缘 case，而是高频路径。
预加载的本质是“时间换空间”：把下载时机提前，但代价是可能浪费带宽或触发无效请求。真正难的不是怎么写代码，而是判断哪张图值得提前加载、在哪一刻加载、以及加载失败时如何兜底——这些决策点藏在业务路径里，不在语法里。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
