图片和iframe未设宽高会导致布局偏移（cls），因浏览器先占0×0位置，资源加载后重绘；lazy加载图片必须显式声明宽高，否则禁用懒加载；首屏图需width/height+fetchpriority="high"，非首屏需三者齐全；iframe同理；decoding="async"仅对≥800px位图有效。
为什么 layout shift 会发生在图片和 iframe 上
浏览器解析 HTML 时，如果 <img> 或 <iframe></iframe> 没有显式尺寸，它会先占一个 0×0 的位置，等资源加载完成、尺寸确定后才重绘——这个“突然撑开”的过程就是累积布局偏移（CLS）的主因。
关键点在于：不是所有图片都需要 width 和 height，但所有 loading="lazy" 的图片必须有；否则 Chrome 会直接禁用懒加载，并在控制台报 Failed to execute 'getBoundingClientRect' on 'Element': The element is not displayed。
- 首屏图片建议用
width/height+fetchpriority="high" - 非首屏图片必须同时设置
loading="lazy"、width、height，三者缺一不可 -
<iframe></iframe>同样适用：加width、height，再配loading="lazy"
decoding="async" 能缓解主线程卡顿，但只对大图有效
解码一张 2000×1500 的 JPG 可能占用 80ms 主线程时间，用户滚动或点击会明显感知卡顿。此时 decoding="async" 把解码任务移交到后台线程，不阻塞渲染和交互。
但它对小图标（如 16×16 favicon）、SVG 或已压缩的 WebP 几乎无感；强行加反而增加解析开销。Chrome 开发者工具的 Performance 面板里，若看到 Decode Image 占主线程高比例，才值得加。
- 仅对尺寸 ≥ 800px 宽/高的位图启用
decoding="async" - SVG、
<picture></picture>中的<source></source>不支持该属性 - 服务端已启用了 AVIF 或现代编码格式时，优先级低于
decoding
preload + fetchpriority 组合才能真正抢到带宽
单独用 <link rel="preload" as="image"> 只是告诉浏览器“稍后要用”，但若页面同时有 10 张图、3 个字体、2 个 JS，浏览器仍可能把首图排在第 5 位下载。这时 fetchpriority="high" 才是调度权的关键。
注意：fetchpriority 对内联样式、<script></script> 无效，只作用于 <img>、<iframe></iframe>、<link rel="stylesheet">（需配合 as）等可预加载资源。
- 首图写法示例：
<img src="hero.jpg" style="max-width:90%" style="max-width:90%" fetchpriority="high"> - 预加载字体时，
<link rel="preload" href="font.woff2" as="font" type="font/woff2" crossorigin>必须带crossorigin，否则无效 -
fetchpriority="low"适合广告位、统计像素、埋点脚本的<img>标签
poster 属性不只是“占位图”，它影响视频首次绘制时机
没设 poster 的 <video></video> 标签，在加载元数据阶段会显示空白或黑屏，导致首次内容绘制（FCP）延迟、CLS 增加。而一张 10KB 的 poster 图片能立刻填充容器，让 FCP 提前 300–600ms。
更关键的是：如果视频设置了 preload="metadata"（推荐值），poster 是唯一能在 JS 获取 video.duration 前就呈现的内容，否则用户面对黑屏+无响应控件，极易跳出。
-
poster图片应与视频宽高比严格一致，避免拉伸或留白 - 不要用 base64 编码的
poster，它会阻塞 HTML 解析 - SSR 渲染时，确保服务端已生成并内联
posterURL，避免客户端二次请求
width/height、loading="lazy"、fetchpriority 三个属性必须共存且语义自洽——少一个，CLS 就可能反弹。前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
