decoding="async"解决大图解码阻塞主线程问题，将宽≥1000px或体积≥200kb图片的解码移至后台线程，避免滚动、点击卡顿；但需配合loading="lazy"、显式宽高及webp/avif格式才有效。

decoding="async"到底解决什么问题

它只管解码时机，不管下载——图片数据下载完后，浏览器在主线程同步解码会卡住滚动、点击等交互；decoding="async"把这步挪到后台线程，主线程继续响应用户操作。但前提是：这张图真得“大”，否则开销反超收益。

常见误判：decoding="async"不是给所有图加就变快。小图标、头像、按钮背景图加了反而可能因调度延迟短暂闪白，尤其快速滚动表格时更明显。

• 有效场景：宽 ≥ 1000px 或体积 ≥ 200KB 的图（如报表截图、设计稿预览、商品详情大图）
• 无效甚至有害：尺寸 ≤ 200×200 的 PNG/JPEG、未压缩图、首屏 banner 图
• 注意：现代浏览器（Chrome ≥ 87、Firefox ≥ 78、Safari ≥ 16.4）对未声明 decoding 的 <img> 默认走异步路径，不写 ≠ 同步

表格里加decoding="async"必须配齐的三件事

表格单元格（<td>）本身不设尺寸，<code>decoding="async"单独写上去等于没设——解码完成后触发重排，Paint flashing 比卡顿还刺眼。

• loading="lazy"：防止长表格一渲染就批量触发下载+解码，尤其滚动时
• 显式 width 和 height（或 aspect-ratio）：锁定单元格尺寸，避免解码完成导致列宽跳变、CLS 偏移
• 现代格式（.webp 或 .avif）：JPEG 在大图上解码压力更大，异步收益严重依赖格式压缩率

漏掉任一环，decoding="async" 就只是 DOM 里一个安静的装饰属性。

Wechat Article Html

将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。

下载

为什么写了decoding="async"还是卡

卡的根源往往不在解码本身，而在布局干扰和资源竞争。表格场景下最容易被忽略的是：

• srcset 没配 sizes：浏览器选错高清图，单张表单元格图体积翻倍，解码压力不降反升
• 父容器用了 overflow: hidden + loading="lazy"：某些 <tr> 被裁剪，图片永远不进视口，根本不会加载 <li>同一屏表格行塞了 5 张以上大图：即使异步解码，后台线程仍排队处理，GPU 纹理上传阶段可能挤占资源</li> <li> <code><picture></picture> 里写 decoding="async"：该属性只认最终渲染的 <img> 标签，<source></source> 上设了也无效

动态生成表格时decoding赋值的坑

JavaScript 拼字符串插入表格，或框架（React/Vue）渲染时，decoding 极易漏设或设晚。

• 旧版 Chrome（≤ 86）会静默丢弃后设的 decoding：必须在 img.src = url 之前赋值
• 用 createObjectURL() 时同理：要在 img.src 赋值前设好 decoding
• 组件库（如 Ant Design Table）通常已封装懒加载逻辑：手动加 decoding="async" 可能被覆盖，得检查最终 DOM 是否真有该属性
• 框架中用 v-for / map() 渲染，别在模板里硬写 decoding="async"，优先用 computed 或 useEffect 控制赋值时机

真正难处理的是「表格首行固定 + 大图 + 滚动监听」这种组合——此时 decoding="async" 只解决一半问题，得配合 img.decode() 手动控制解码完成时机，否则快速滚动时图片仍延迟渲染。

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