decoding="sync"仅适用于需立即读取naturalwidth/height参与布局或动画首帧严丝合缝的两类场景，否则会强制主线程同步解码大图，导致滚动、点击等交互阻塞数百毫秒。
decoding="sync" 会让大图强制卡住主线程解码
大图（比如 2000×1200 的 WebP，体积 >800KB）一旦设 decoding="sync"，浏览器必须在主线程完成整个像素解码后才继续渲染后续内容。这意味着：页面滚动、按钮点击、CSS 动画都可能被阻塞几百毫秒——尤其在中低端 Android 设备上，单张大图 sync 解码常耗时 300–600ms。
它不加快加载，也不压缩图片，只是把解码这一步“锁死”在渲染流程里。你看到的“首屏大图秒出”，其实是靠牺牲其他交互换来的。
- 适用场景极窄：仅当你需要立即读取
img.naturalWidth做 layout 计算（例如动态生成 canvas 贴图），或轮播图第一帧必须严丝合缝对齐动画起始帧 - 别和
loading="lazy"同时用——懒加载本意是延迟请求，sync 却要求立刻解码，逻辑冲突 - Chrome 87+、Firefox 78+、Safari 16.4+ 行为一致，但 Safari 15.4 之前直接忽略该属性，等于没写
decoding="async" 对大图的实际效果取决于并发和尺寸
decoding="async" 不改变下载时间，只把解码从主线程挪到后台线程。对大图来说，这能明显缓解滚动卡顿，但收益有前提：
- 单张大图加
async效果有限；真正起作用的是批量使用——比如瀑布流里 20 张 >500KB 的图全部设decoding="async"，主线程不再排队等解码 - 如果图片未压缩（如原图 PNG）、尺寸远超容器（
width="300"却加载 4000px 宽图），async无法掩盖 CPU 解码压力，仍会卡 - 与
loading="lazy"组合时，解码异步化被延迟加载“稀释”了——图还没进视口，谈不上解码时机，优先优化srcset和尺寸裁剪更实在
大图渲染卡顿的真正瓶颈往往不是 decoding
很多人盯着 decoding 调优，却忽略了更关键的三件事：
- 网络层：大图没走 CDN、没开 Brotli 压缩、响应头没配
Cache-Control: immutable - 资源层：没用
srcset提供适配设备像素比的多档尺寸，导致移动端下 4K 图硬缩放 - 执行层：没用
createImageBitmap()+fetch()手动控制解码并发数，而是依赖原生<img>的默认行为
decoding 属性只是解码阶段的开关，它管不了下载、管不了尺寸、管不了内存释放节奏。真要压大图卡顿，得先确认是不是在拿 3MB 的 JPG 当 banner 用。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
