真正卡低端机的不是图片大小，而是配置错误导致浏览器误加载大图：media断点错配横屏手机、sizes缺失致选图过大、srcset混用w/x被旧浏览器跳过、WebP在低端机解码更慢。
低端机加载大图过慢，根本不是图片太大，而是
media 断点写错，低端机被迫加载桌面图
很多项目把 media="(max-width: 768px)" 当成“手机专用”，但实际测试发现：大量中低端安卓机（如 Redmi Note 系列、vivo Y 系列）在竖屏时视口宽度是 412px 或 414px，横屏却能到 736px ——而你的断点如果只设到 768px，横屏瞬间就匹配上了桌面 <source>，加载 1200w 甚至 1920w 的图。
实操建议：
- 用 Chrome DevTools 的 Device Toolbar 模拟真实低端机型（选 “Moto G4” 或 “Galaxy S5”），看 Network 面板里实际发了哪个
srcset请求 - 断点改用开区间：
max-width: 480px（小屏竖屏）、(min-width: 481px) and (max-width: 767px)（小屏横屏/平板竖屏）、min-width: 768px（平板横屏+桌面） - 避免用
min-width: 768px单独覆盖所有大屏——它会把横屏手机也拖进去
sizes 属性缺失或写死，浏览器猜错显示宽度
没写 sizes，浏览器默认按 100vw 算图宽。但低端机上，你 CSS 里写的 width: 100% 很可能被父容器 padding、flex gap 或 viewport 缩放干扰，真实占位只有 320px；而浏览器却按 412px 甚至 100vw=412px 去 srcset 里找最接近的图，结果选中了 480w 或 640w 的版本——对 2G 内存设备来说，解码 640w JPEG 就够卡顿了。
立即学习“前端免费学习笔记（深入）”；
实操建议：
- 在
<img>上显式写sizes="(max-width: 480px) 100vw, (max-width: 767px) 50vw, 33vw"，和你真实 CSS 布局一致 - 别写
sizes="100%"或sizes="300px"——浏览器不认这些值，直接 fallback 到100vw - 配合
width和height内联属性（如width="320" height="180"），防止 layout shift 加重卡顿
srcset 混用 w 和 x，低端浏览器直接跳过整条 source
有些代码写成：<source media="(max-width: 480px)" srcset="hero-mob@1x.jpg 1x, hero-mob-320w.jpg 320w">。这是未定义行为：Android 4.4 WebView、UC 浏览器、旧版 Samsung Internet 会直接忽略这个 <source>，退到下一条，最终加载桌面图。
实操建议：
- 小屏段只用
w描述符：srcset="hero-mob-320w.jpg 320w, hero-mob-480w.jpg 480w" - 如果要适配 DPR，统一用
x：srcset="hero-mob@1x.jpg 1x, hero-mob@2x.jpg 2x"（注意：2x 图体积必须严格控制在 100KB 以内，否则比 480w 还慢） - 检查 Network 面板里有没有标
blocked:mime-type或请求状态为(inactive)——那是浏览器因语法错误静默丢弃了该 source
没做格式降级，WebP 在低端机上反而更慢
以为 type="image/webp" 能减体积，但很多低端 Android 机（尤其定制 ROM 如 OPPO ColorOS 11 以下、vivo Funtouch OS）的系统 WebView 对 WebP 解码效率极低，加载一张 80KB WebP 可能比加载 120KB JPEG 还慢 300ms。
实操建议：
- 优先用 JPEG +
<source type="image/jpeg">作为主力，WebP 仅作可选补充 - 确保每个
<source>的type和服务器返回的Content-Type完全一致（大小写、拼写、无空格） - 在低端机 UA 里主动禁用 WebP：服务端根据
User-Agent中的Linux; U; Android 4.或UCBrowser/13.等特征，返回 JPEG 版本的<picture>HTML
真正卡住低端机的，往往不是图片本身，而是浏览器反复解析、预加载、回退、重排这一整套链路。每个多余的 srcset 项、每个漏掉的 sizes、每个大小写错误的 type，都在悄悄吃掉那仅有的 500MB 可用内存。
