preload图片必须写在html最前面且as="image"不可省略，否则请求被忽略或降为low优先级；href需静态路径且与img src完全一致；需配合fetchpriority="high"和loading="eager"确保及时渲染；跨域图片须加crossorigin；验证须看network面板initiator、priority及start time。
preload图片必须写在最前面，且as="image"不能省
浏览器只在 HTML parser 初期识别 rel="preload"，写在 里、JS 动态插入、或跟在 <link rel="stylesheet"> 后面，请求都会被忽略——不是延迟，是彻底不发。关键图片（比如首屏 banner）加载因此晚 200ms+ 是常态。
更隐蔽的问题是漏写 as="image"：没有它，浏览器当普通 fetch 处理，Priority 显示为 Low，Network 面板里 Initiator 是 (Other) 而非 preload，等于白写。它还影响缓存分区，后续 <img src> 无法复用。
-
as只能是"image"，不是"img"、"picture"或空值 -
href必须是静态路径，不能含模板变量（如/assets/${name}.webp）或相对路径歧义（HTML 在/page/下却写./img.jpg） - 不支持
srcset或sizes，只适合尺寸/格式确定的单图；对响应式<img srcset>无效
preload图片后，<img> 标签仍需配 fetchpriority="high" 和 loading="eager"
rel="preload" 只负责提前下载进缓存，不触发解码、不占布局、也不影响 <img> 的渲染调度。如果图片标签没显式声明优先级，浏览器可能仍按默认 Medium 处理，尤其在多图并存时，LCP 候选元素反而被降权。
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
-
fetchpriority="high"仅在 Chromium 112+ 生效（Chrome/Edge 112+、Opera 98+），Safari/Firefox 忽略；它是提示而非强制，但能减少启发式判断偏差 -
loading="eager"必须设，否则 lazy 启发式策略可能提前发起一次加载，再 fallback 补一次，导致重复请求 - 不要给所有图片都加
fetchpriority="high"：浏览器会把它们塞进同一 High 队列，稀释真正关键图的调度权重 - 若已
preload同一 URL，fetchpriority就失效——preload本身已锁定Highest优先级
crossorigin 不是字体专属，图片跨域时也得加
多数人以为 crossorigin 只对字体强制，其实只要图片托管在跨域 CDN，且服务端响应头没带 Access-Control-Allow-Origin: *，就必须显式声明 crossorigin，否则预加载请求会被静默丢弃，Network 面板显示 net::ERR_FAILED 或状态为 (blocked)。
- 同源图片通常不需要
crossorigin，但若你不确定 CDN 策略，加个空值crossorigin=""更稳妥 -
href路径必须和最终<img src>完全一致（含大小写、斜杠、查询参数），否则缓存不命中，两次请求 - 别对
<img src>本身加preload：不如直接用fetchpriority="high"简单有效，preload在这里是冗余操作
验证 preload 是否真起作用，只看 Network 面板这三点
光检查 HTML 有没有那行代码毫无意义。打开 Chrome DevTools → Network 面板，刷新页面后盯住三个信号：
- 筛选
Initiator列为preload（不是parser或script） - 检查
Priority列是否为Highest（as="image"应该是High，但实际常升到Highest；若显示Low，基本是as写错或 404） - 对比未加
preload时的Start Time：理想可提前 200–600ms 开始下载，弱网下收益更明显
最容易被忽略的是：preload 不阻塞渲染，但它抢带宽——如果加错对象（比如预加载非首屏轮播图），当前页 CSS/JS 加载反而被挤占，LCP 反而变差。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
