全屏背景大图优化需兼顾视觉质量、加载速度与设备适配，优先选用WebP或AVIF格式，按设备DPR提供多分辨率图片，配合preload与sizes精准加载。
全屏背景大图是页面性能的常见瓶颈，压缩不能只看“文件变小”，得兼顾视觉质量、加载速度和设备适配。关键不是压到最轻，而是压得“刚刚好”。
选对格式和编码参数
优先用 WebP 格式，比同质量 JPG 小 25%–30%，且支持透明和有损/无损双模式。压缩时别只调 quality 值——用 quality 0.7–0.8（Canvas toDataURL 或命令行工具如 cwebp）是清晰度与体积的平衡点。低于 0.6 易出色块，高于 0.9 体积增长快但人眼难辨提升。若原图含透明或渐变，改用 AVIF（现代浏览器支持良好），压缩率更高；老浏览器必须用 <picture> 包裹 fallback：
<source srcset="bg.avif" type="image/avif"><source srcset="bg.webp" type="image/webp">-
<img src="bg.jpg" alt="">（JPG 作为最终兜底）
尺寸匹配视口，不靠 CSS 缩放硬扛
background-size: cover 再聪明，也不能让一张 4000×2250 的图在手机上高效加载。应按设备能力提供多档分辨率：
- 桌面端：1920w 或 2560w 图（DPR=1–2）
- 平板：1200w–1600w
- 手机：768w 或 828w（注意 iPhone 竖屏实际渲染宽度常为 390–430px，但 DPR=3，所以需提供 ~1200px 宽的图）
配合 srcset 和 sizes 属性，例如：sizes="(max-width: 768px) 100vw, (max-width: 1200px) 50vw, 1920px"
这样浏览器才能按真实布局宽度选图，避免高 DPR 设备误载超大图。
预加载 + 懒加载策略分层
首屏全屏背景属于“关键资源”，必须尽早加载，但又不能阻塞渲染：
立即学习“前端免费学习笔记（深入）”；
- 用
<link rel="preload" as="image" href="bg-desktop.webp">提前触发下载 - 禁用该图的懒加载（
loading="eager"），尤其不要加loading="lazy"到背景图容器 - 非首屏背景图（如滚动后出现的 section 背景）才启用
loading="lazy"或 IntersectionObserver 手动控制
规避常见压缩翻车点
很多“压缩后反而更大”问题源于操作失当：
- 原始图已是高压缩 JPG（Chroma subsampling 2x2），再用 Canvas 以 0.9 质量导出，会二次采样导致体积暴涨——先用 ImageMagick 查
identify -verbose确认基础参数 - 没缩放尺寸只调 quality：比如原图 3840×2160，直接 toDataURL('image/jpeg', 0.7)，不如先 canvas 绘制为 1920×1080 再导出，体积可降 75%
- WebP fallback 未配 MIME 类型：服务器需返回
Content-Type: image/webp，否则 Chrome 拒绝解析
压缩不是一步到位的动作，而是“格式→尺寸→质量→传输”四步闭环。测完再上线，用 Chrome DevTools Network 面板切设备模拟器，确认加载的是预期尺寸和格式。
