必须用srcset+sizes精准匹配css布局宽度，按断点写sizes表达式并统一单位；picture中source须按格式兼容性从高到低排序，webp/avif在前、jpeg/png在后；img必须设置width/height防layout shift。
直接压缩 HTML 中的 <img> 标签所引用的图片资源，不能只改文件本身，必须同步调整引用方式、格式策略和加载逻辑——否则压了也白压，甚至引发布局偏移或兼容性故障。
用 srcset + sizes 避免高分辨率设备加载大图
浏览器不会自动“选小图”，它靠 srcset 提供的源列表和 sizes 声明的容器宽度来决策。常见错误是写了 srcset 却没配 sizes，或 sizes 写成宽泛断点（如 (max-width: 768px) 100vw, 50vw），导致 400px 宽的卡片里加载了 1200w 的图。
- 先量清 CSS 容器实际渲染宽度（比如
320px），然后写sizes="320px"，最准 -
srcset中的w描述符必须是原图真实宽度（320w、640w、960w），不是缩放后尺寸 - 保留
src属性指向 fallback 图（如photo.jpg），否则不支持srcset的旧浏览器空白 - 用 Chrome DevTools → Network → 切换设备模拟器后刷新，看实际加载的是哪个 URL，别猜
转 WebP/AVIF 必须配 <picture></picture> 和正确 MIME 类型
把 a.jpg 改名成 a.webp 然后直接塞进 src，IE 和旧 Safari 会显示断裂图标，且服务器若没返回 image/webp MIME 头，Chrome 也可能拒绝解析。
- 必须用
<picture></picture>包裹：<source type="image/webp" srcset="a.webp"><img src="a.jpg" alt=""></source> - Nginx 需加配置：
types { image/webp webp; }；Apache 要确保.webp关联image/webp - AVIF 同理，但需额外确认目标浏览器支持（iOS 16.4+、Chrome 109+），且服务端要返回
image/avif - WebP 不支持动画，GIF 动画不能硬转，得另存为 MP4 或保留原格式
前端 Canvas 压缩时宽高比和元数据处理最容易翻车
Canvas 压缩不是“设个 canvas.width 就完事”，原始尺寸、方向、透明通道、EXIF 元数据全会影响输出质量与体积。
- 永远用
img.naturalWidth/img.naturalHeight计算缩放比例，别用img.width（可能被 CSS 修改） - iOS 拍照图带 EXIF Orientation，不校正会导致旋转错乱；要用
exif-js或类似库解析并手动 rotate canvas - 原图是 PNG 且含透明 → 强制导出为 JPEG 会填充黑底，体积反而更大；此时应保持 PNG，靠降尺寸压缩，而非质量参数（PNG 不吃 quality）
- 导出用
canvas.toBlob(callback, 'image/jpeg', 0.75)，质量 0.7–0.8 是多数场景平衡点；iOS Safari 对toBlob支持不稳定，可 fallback 到toDataURL再转 Blob
懒加载 loading="lazy" 仅对 <img> 生效，<picture></picture> 不继承
很多人给 <picture></picture> 加 loading="lazy"，结果毫无效果——这个属性只作用于 <img> 标签本身，<source></source> 和 <picture></picture> 容器不识别。
- 必须把
loading="lazy"写在<img>上，且它是 fallback 图，所以最终 lazy 的是 JPG/PNG 版本，不是 WebP - 若需对所有格式统一 lazy，得用 IntersectionObserver 手动控制
src/srcset注入时机 - 注意 Safari 15.4+ 才支持
loading="lazy"在<img>上，更老版本需 polyfill 或降级处理 - 服务端渲染（SSR）页面中，首次 HTML 返回时若
<img>已有src，即使加了 lazy，首屏仍会加载；真正 lazy 需配合 JS 动态注入
真正卡住上线的往往不是“会不会压”，而是“压完有没有改引用”“fallback 是否兜得住”“MIME 头有没有漏配”——这些细节不验，再小的图片也能拖垮首屏。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
