decoding=async提示浏览器采用异步图像解码方式，并不等于延迟发起网络下载。loading影响加载时机，fetchpriority提供请求优先级提示，解码又是拿到图像数据后的处理环节，三者不能当作同一个加速开关。
先把网络和渲染分成不同阶段
浏览器发现图片地址后，要根据加载策略安排请求，再对数据解码并参与绘制。网络面板显示文件已下载，不表示画面已经完成解码和显示；反之，设置异步解码也不会自动让所有图片等滚动到附近才开始请求。应先明确本次要改善哪一阶段。
理解decoding只是调度提示
sync、async和auto表达不同解码偏好，浏览器仍结合自身实现处理。异步解码有助于避免等待图片处理阻碍其他内容的呈现，但不保证图片立即显示，也不承诺固定性能提升。不能把网页上的属性存在当作当前访问确实采用某种内部调度的直接证据。
需要可控换图时核对decode方法
脚本需要在图片准备好后切换展示，可以根据场景使用HTMLImageElement.decode()等接口等待解码结果，并处理失败。它与HTML中的decoding提示不是同一个API，也不能跳过图片的获取过程。应避免快速连续切换时过期请求覆盖用户后来选择的图片。
根据问题选择对应测试
若目标是减少下方图片提前下载，检查loading及实际网络请求；若目标是换图闪白或渲染停顿，应观察解码和呈现过程。用代表性大图、手机与受控网络比较，同时确保首屏重要画面不被错误延迟。测试记录要区分已下载、已解码和已显示。
关键区别
loading：影响图片加载时机；不是解码方式。
decoding：提供解码调度提示；不会自动延迟下载。
decode方法：等待图像解码结果；脚本仍需处理失败。
怎样确认处理到位
所选机制与真实问题相符，加载和换图过程没有非预期闪白或错误覆盖，网络请求、解码准备和最终显示被分别核对。
容易误判的边界
decoding控制解码提示，loading控制加载时机；二者都不能代替合适的图片体积、首屏加载策略和实际性能测量。
