decoding="async"仅对已加载完成的大图（宽≥1000px或体积≥200KB）有效，它将像素解码移至后台线程以避免阻塞主线程滚动、点击等交互，而对未下载完、小图或首屏关键图滥用反而引发发虚、延迟或CLS。
网页卡顿往往不是因为代码写得慢，而是图片在后台偷偷吃掉内存、解码线程和 GPU 纹理缓存——尤其当 background-attachment: fixed 遇上未压缩的 4K 图，或 <img> 没设 decoding="async" 时，切出浏览器就假死。
为什么 srcset + sizes 不加 decoding="async" 会卡 UI
浏览器对大图（比如 1920×1080 JPEG）默认同步解码，主线程必须等整张图解完才继续渲染。哪怕你用 srcset 选了 768w 的图，只要没加 decoding="async"，它仍会在主线程堵着。
-
decoding="async"强制浏览器把解码扔进后台线程，UI 不卡，滚动/切换标签页不冻结 - 只对
<img>有效，<picture>内部的<img>也要单独加 - Chrome 78+、Firefox 69+、Safari 15.4+ 支持；老版本可忽略，不影响功能，只是没优化
- 别和
loading="lazy"混用时省略它——懒加载只推迟请求，不解码压力
background-image 卡顿的真正解法不是换 CSS，是换标签
用 background: url(wallpaper.jpg) fixed 加再好的 CDN 也救不了：固定背景图必须常驻 GPU 显存，多张高清图叠加直接超限。iOS 和部分安卓还会静默降帧甚至崩溃。
- 删掉所有
background-image，改用<picture>插入 DOM 顶部，配合position: fixed和z-index: -1 -
<source>必须带type="image/webp"，否则 Safari 可能跳过整条规则 - 兜底
<img>的src必须是真实可用的 fallback 图，不能是占位符 - 容器（如
<body>）要设min-height: 100vh，否则图不显示
loading="lazy" 什么时候反而加重卡顿
不是所有图都适合加 loading="lazy"。加错位置会让首屏关键图延迟加载，LCP（最大内容绘制）时间飙升，用户第一眼看到白屏。
立即学习“前端免费学习笔记（深入）”；
- 首屏 Hero 图、Logo、登录框头像——必须删掉
loading="lazy"，甚至加<link rel="preload" as="image"> - 列表页第 3 屏之后的图才适合加，且要配合
width/height属性防 layout shift - 如果用了自定义懒加载（
IntersectionObserver），别再叠loading="lazy"——行为冲突，可能触发两次加载 - Chrome DevTools → Network → 刷几次看 “Initiator” 列，确认 lazy 图是否真没在首屏发请求
大图加载卡死的硬性前提：服务端必须预生成多尺寸文件
前端写再多 srcset 和 sizes，如果服务端只有一张 170MB TIFF 或 5MB 原图，浏览器照样得下全量、解全量、卡死。
- 必须用
convert或sharp批量生成：768w、1200w、1920w 三档 JPEG/WebP，质量 65–75%，加-interlace Plane输出渐进式 -
sizes值必须和真实 CSS 媒体查询一致，例如你用@media (min-width: 768px)把图宽设为50vw，那sizes就得写sizes="(min-width: 768px) 50vw, 100vw" - 别信“自动响应式 CDN”，没配
f_auto、w_、q_参数，它不会帮你缩图 - DevTools → Network → 看实际加载的 URL，验证是否真按设备宽度选了小图
最容易被忽略的是：所有优化都依赖服务端预处理这一步。没生成多尺寸图，srcset 是空转，decoding="async" 是徒劳，loading="lazy" 只是把卡顿从首屏挪到第二屏。
