不加控制的<img>标签是前端带宽和性能最大隐形消耗源；需从加载时机、资源绑定、尺寸匹配三方面系统干预，而非仅换格式或压缩。
直接上结论：不加控制的 <img> 标签是前端带宽和性能的最大隐形消耗源之一；真正有效的图片管理，不是“换格式”或“压大小”就能解决的，而是从加载时机、资源绑定方式、尺寸匹配逻辑三方面系统干预。
为什么 src 一写就浪费？
浏览器看到 <img src="big.jpg"> 就立刻发起请求，不管这张图在页面底部、是否被 display: none 隐藏、甚至用户根本没滚动过去。移动端用户可能只看首屏，却已下载了 5 张 2MB 的轮播图。
- 首屏外图片默认加载 → 白费流量、拖慢 TTFB 和 LCP
-
src被硬编码 → 无法根据网络状况（如navigator.onLine或saveData）降级 - 没有 fallback 机制 → WebP/AVIF 图片在旧浏览器里直接 404，不退回到 JPEG
loading="lazy" 不是万能解药
原生懒加载确实省事，但它只判断“是否进入视口”，不关心设备 DPR、网络类型、内存压力。比如在低端安卓机上，loading="lazy" 可能触发大量重绘，反而卡顿。
- 仅支持现代 Chrome/Firefox/Edge，Safari 直到 v15.4 才完全稳定
- 对
position: absolute或 transform 移动中的图片，检测可能失灵 - 不支持自定义阈值（比如想提前 200px 加载，它只认 128px 默认偏移）
- 建议搭配 IntersectionObserver 手动控制：
new IntersectionObserver(cb, { rootMargin: '200px' })
用 srcset + sizes 避免“一张图打天下”
很多项目只给 src 写一个 1920px 宽的图，然后靠 CSS 缩放显示在手机上——这等于让用户下载 6 倍体积的图再丢掉 5/6 像素信息。
立即学习“前端免费学习笔记（深入）”；
-
srcset必须配w描述符（如"small.jpg 480w, medium.jpg 768w, large.jpg 1200w"），不能只写x -
sizes要真实反映布局宽度，比如sizes="(max-width: 480px) 100vw, (max-width: 768px) 50vw, 33vw" - 服务端若支持 Client Hints（
Accept-CH: DPR, Width, Viewport-Width），可进一步服务端适配，但需后端配合
data-src + JS 控制才是可控起点
把真实地址存在 data-src，src 指向 1×1 透明 GIF 或空字符串，由 JS 在合适时机赋值——这是所有高级策略（条件加载、错误重试、AB 测试图源）的前提。
- 避免在
DOMContentLoaded就批量替换，应等requestIdleCallback或使用IntersectionObserver - 替换前检查
img.naturalWidth === 0，防止重复触发 - 监听
img.onerror，失败时 fallback 到备用 URL 或降级格式（如 WebP → JPEG） - 示例关键片段：
<img data-src-fallback="photo.jpg" alt="...">
最常被忽略的一点：图片管理不是“加功能”，而是“砍请求”。哪怕用了 srcset，如果 HTML 里写了 20 个 <img>，浏览器照样会并发请求——得先用语义化结构（如 <figure>）配合 JS 动态插入，才能真正按需激活。
