decoding="async"能缓解图片解码卡顿但仅限已加载完成的<img>标签，它将解码移出主线程避免掉帧；不支持时静默降级，且不解决网络加载慢问题。
decoding="async" 能不能缓解图片加载卡顿
能，但只对特定场景有效——它把图片解码从主线程移出，避免解码过程阻塞渲染帧。但前提是图片已加载完成，且浏览器支持该属性（Chrome 78+、Firefox 69+、Safari 15.4+）。不支持时会静默降级为同步解码。
常见错误现象：decoding="async" 加了却没效果，是因为图片还没进内存（比如懒加载中），或用了 background-image（该属性仅对 <img> 标签生效）。
- 必须配合
src或srcset使用，data-src不触发解码 - 不解决网络加载慢的问题，只解决“图已下载完，但解码占主线程”的问题
- 与
loading="lazy"可共存，但要注意：懒加载图片首次进入视口时，decoding="async"才真正起作用
为什么主线程解码图片会卡顿
图片解码（尤其是 WebP、AVIF 或高分辨率 JPEG）是 CPU 密集型操作。浏览器默认在主线程解码，一旦遇到多张大图集中解码，单次耗时可能超过 16ms，直接导致掉帧、滚动卡顿、input 延迟响应。
典型触发场景：
立即学习“前端免费学习笔记（深入）”；
- 瀑布流页面一次性插入 20+ 张 2MB WebP 图片
- Canvas 绘制前用
drawImage(img, ...)，而img尚未完成解码 - 使用
createImageBitmap()但没传{premultiplyAlpha: 'none'}等参数，触发隐式同步解码
比 decoding 更彻底的解码控制：createImageBitmap
createImageBitmap() 是目前唯一能显式控制解码时机和线程的 API。它返回一个 Promise，解码发生在 Worker 线程或独立解码线程（取决于浏览器实现），完全不碰主线程。
实操建议：
- 替代
new Image()+onload的老写法，尤其适合预加载、图像处理等场景 - 传入
{type: 'image/webp', premultiplyAlpha: 'none'}可跳过部分转换步骤，提速约 15–30% - 注意：不能直接用于
<img>的src，需配合canvas.drawImage()或 CSSbackground-image: url(...)（通过URL.createObjectURL()转换） - 兼容性需兜底：
if (typeof createImageBitmap === 'function')，否则回退到decoding="async"
容易被忽略的细节：解码完成 ≠ 渲染就绪
即使用了 decoding="async" 或 createImageBitmap()，如果后续立刻调用 getBoundingClientRect()、offsetHeight 或 canvas.drawImage()，仍可能触发强制同步布局或等待解码完成——因为这些操作依赖图像的实际尺寸或像素数据。
安全做法是监听 img.decode()（返回 Promise）再执行依赖尺寸/像素的操作：
img.src = 'chart.webp'; await img.decode(); // 确保解码完成 canvas.drawImage(img, 0, 0); // 此时才安全
这个点常被跳过，结果就是“用了 async 却还是卡”，问题不在解码本身，而在后续 DOM 读取时机没对齐。
