decoding="async"仅对大图（宽≥1000px或体积≥500KB）有效，可将解码移至后台线程缓解主线程阻塞；小图、未压缩图、首屏关键图滥用反而损害性能；默认应让浏览器自动决策，配合尺寸声明、现代格式与合理加载策略才能真正提升感知性能。

decoding

属性确实能缓解主线程阻塞，但它的效果高度依赖使用场景——加了不等于快了，乱用反而拖慢渲染。

什么时候该用 decoding="async"

只对大图（宽 ≥ 1000px 或体积 ≥ 500KB）有实际收益。这类图片解码耗 CPU，同步执行会卡住页面交互（比如滚动、点击响应）。decoding="async" 把解码挪到后台线程，主线程继续干活。

常见误用场景包括：

• 给小图标、头像、按钮背景图加 decoding="async"：解析开销反超收益，还可能引发短暂闪烁
• 在未压缩的 PNG/JPEG 上硬套 decoding="async"：网络下载仍是瓶颈，解码异步毫无意义
• 和 loading="lazy" 同时设在首屏关键图上：懒加载延迟了下载，解码异步就失去作用时机

decoding="sync" 不是“更稳妥”的默认选择

它强制浏览器等解码完成再把图片塞进布局流，适合极少数需要像素级同步的场景，比如：

• CSS 背景图配合 background-size: cover 且必须严丝合缝撑满容器
• Canvas 绘图前依赖 img.naturalWidth 精确尺寸做计算（但更推荐监听 load 事件）
• 动画帧序列中某张图必须和文字渲染节奏完全对齐（极罕见）

绝大多数普通 标签用 decoding="sync" 只会让页面“等得更久”，尤其在低端设备上容易感知到卡顿。

与 fetchpriority 并存时的真实表现

当一张图同时设了 fetchpriority="high" 和 decoding="async"，浏览器会优先下载，但解码仍排队——如果主图是 4K WebP，解码本身就要 80ms+，即使异步，也会挤占其他图片的解码带宽。

HTML Text Extract

从HTML页面（URL、文件或标准输入）中提取主体内容文本，去除导航、页脚、广告和模板文本。可直接传递给readability_check或其他文本工具。

下载

更现实的做法是分层控制：

• 首屏主图：只设 fetchpriority="high"，去掉 decoding（留给浏览器 auto 决策）
• 次屏商品图：设 decoding="async" + loading="lazy"，但必须配 width/height 防 CLS
• 大量列表图：改用 fetch() + createImageBitmap() 手动控并发，比纯 HTML 属性更可靠

容易被忽略的兼容性细节

decoding 在 Safari 15.4+、Chrome 78+、Firefox 69+ 支持，但 Edge 旧版（≤ 18）和部分安卓 WebView 完全忽略该属性。别指望它兜底。

真正影响感知性能的，从来不是单个属性开关，而是三件事的组合：图片尺寸是否匹配展示区域、格式是否选 WebP/AVIF、是否提前声明 width 和 height。漏掉其中任一环，decoding="async" 就只是个好看的摆设。

前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！