关键在于让浏览器在正确时间、用正确尺寸、加载正确分辨率的图片,三者缺一不可;仅靠max-width:100%无法解决性能问题,必须配合srcset+sizes、响应式背景图、语义化图片选择及懒加载等综合策略。
关键不是“让图片变小”,而是让浏览器在正确时间、用正确尺寸、加载正确分辨率的图——三者缺一不可。
它只解决缩放变形问题,不解决性能问题。一张 4MB 的大图即使被 CSS 缩到 200px 宽,仍会完整下载、解码、渲染,拖慢首屏。
img 标签没配 srcset,但开发者以为“CSS 自适应了就 OK”width: 100% 比 max-width: 100% 更危险:它强制拉伸小图,导致模糊+重绘height: auto,否则宽高比断裂,object-fit 也救不回来单独写 srcset,浏览器只能靠猜测选图;sizes 才是告诉它“这张图在你屏幕上实际占多宽”。漏掉 sizes,等于白写 srcset。
<img src="fallback.jpg" srcset="s.jpg 480w, m.jpg 768w"> → 浏览器默认按 100vw 猜,大概率选错<img src="fallback.jpg" srcset="s.jpg 480w, m.jpg 768w, l.jpg 1200w" sizes="(max-width: 480px) 100vw, (max-width: 768px) 50vw, 33vw">
sizes 值必须真实反映布局:如果图片在 768px 断点下占容器 1/3 宽,就不能写 50vw
Width, DPR),可省去 sizes 计算,但需后端配合background-image 不支持 srcset,所以单写一条 URL 就等于全设备加载同一张图——高清屏模糊,小屏浪费带宽。
@media 查询分条件加载:@media (min-width: 768px) { .hero { background-image: url(img/hd.jpg); } }
@media (-webkit-min-device-pixel-ratio: 2), (min-resolution: 192dpi)
768px + 2x 的组合规则,否则会被覆盖<picture> + srcset
它只控制加载时机,不控制加载哪张图。如果 srcset 配得不对,懒加载反而让错误尺寸的图更晚暴露问题。
srcset + sizes 同时使用,否则移动端可能懒加载出 desktop 尺寸图loading="lazy" 对首屏图片无效(浏览器自动取消 lazy),别给首屏图加<img> 无尺寸会导致布局抖动,务必提前设好 aspect-ratio 或容器 padding-top 占位IntersectionObserver,纯 CSS 无法实现最易被忽略的一点:所有响应式图片优化都建立在「容器尺寸可预测」前提下。如果父容器宽高由 JS 动态计算或 CSS Grid / Flex 异步撑开,sizes 和 object-fit 都可能失效——这时得退回到 JS 驱动的图片加载逻辑。