图片往往占据网页加载体积的大头。同一张图，优化前后体积可能相差十倍以上，而肉眼几乎看不出区别。图片优化是投入产出比最高的性能优化手段之一。
一、图片格式的选择
不同格式适合不同内容类型，选错格式会造成体积浪费。
JPEG适合照片和复杂色彩的图像。它是有损压缩，通过调节质量参数控制体积。推荐质量设为 75 到 85，肉眼难以分辨差异而体积显著下降。
PNG适合需要透明通道的图像、图标、线稿。它是无损压缩，但体积通常较大。不建议用 PNG 存储照片。
WebP同时支持有损和无损，还支持透明通道，同等画质下体积比 JPEG 小约 25% 到 35%。目前主流浏览器已全面支持，是网页图片的推荐格式。
AVIF压缩效率更高，体积可比 WebP 再小 20% 以上，但编码速度慢，部分旧浏览器不支持。适合对加载速度要求极高的场景。
SVG是矢量格式，用于图标和简单图形。它不受分辨率限制，任意缩放都清晰，且体积极小。但复杂图形用 SVG 反而可能比位图更大。
二、压缩的正确做法
先裁剪再压缩。很多人直接压缩整张大图，但页面上实际只显示一小块。先按需要的尺寸和构图裁剪，再压缩，效果远好于直接降质量。
匹配实际显示尺寸。如果图片在页面上最大显示宽度是 800 像素，就不必上传 3000 像素的原图。按显示尺寸的两倍准备（适配高分辨率屏幕）即可。
有损压缩的质量选择。质量参数不是越高越好。质量从 100 降到 85，体积可能减少一半而视觉几乎无差别；但从 85 降到 70，就可能出现明显块状和边缘模糊。建议在 75 到 85 之间测试。
元数据清理。相机拍摄的照片通常包含 EXIF 信息，除拍摄参数外，还可能包含地理位置。清理这些元数据既能减小体积，也能保护隐私。
三、响应式图片方案
同一张图片在不同设备上的需求尺寸不同。响应式图片的核心是「按需加载合适尺寸」。
srcset 属性允许为同一张图提供多个尺寸版本，浏览器根据屏幕宽度和像素密度自动选择。例如为一张图准备 480、800、1200、1600 四个宽度版本。
picture 元素支持更复杂的场景，可以根据条件加载不同格式。例如优先加载 AVIF，不支持时回退到 WebP，再回退到 JPEG。
懒加载（Lazy Loading）让首屏之外的图片在滚动到可视区域时才加载，能显著加快首屏速度。原生 loading=”lazy” 属性已经可以直接使用。
四、容易被忽视的优化点
占位图。为图片设置明确的宽高比，避免加载时布局跳动。布局跳动会显著影响用户体验和搜索引擎评分。
图片 CDN。使用支持自动格式转换和尺寸调整的 CDN，可以在不改动代码的情况下批量优化图片。
图标字体与雪碧图。这两种老方案在 HTTP/2 和 SVG 普及后已基本被取代，新项目建议直接使用 SVG 内联或独立文件。
五、检查清单
上线前逐项核对：格式是否匹配内容类型、尺寸是否匹配显示需求、是否清理了元数据、是否配置了响应式版本、首屏外图片是否启用懒加载、是否设置了宽高比避免布局跳动。
图片优化没有终点，但优先做前四项，通常就能获得八成以上的收益。
四、响应式图片的实践
响应式图片的核心，是让不同屏幕加载合适尺寸的图片。同一张图提供多个尺寸，通过响应式语法让浏览器按屏幕宽度与像素密度自动选择，避免在手机上加载为桌面准备的大图。这能显著减少移动端的流量消耗与加载时间，是提升体验最直接的优化之一。
除了尺寸，还要考虑格式的按需提供。新一代图片格式通常能在同等画质下大幅减小体积，但并非所有环境都支持。理想做法是同时提供新旧两种格式，让浏览器按支持情况选择，不支持新格式时回退到通用格式。这种”渐进增强”的思路，能在享受新格式红利的同时，保证广泛的兼容性。
五、图片性能的持续优化
图片优化不是一劳永逸的，需要持续关注。上线后应监测图片对页面加载的影响，找出体积过大的图片进行针对性处理。常见的问题包括：尺寸远超实际显示需求、压缩质量设置过高、格式选择不当、以及大量图片同时加载导致拥塞。借助性能分析工具，可以定位到具体是哪几张图片拖慢了加载，从而有的放矢地优化。
对于内容型站点，建议把图片优化纳入内容发布的规范：上传前统一压缩、按需裁切尺寸、选择合适的格式，并填写有意义的替代文本。规范化的流程能让优化成为习惯，而非事后补救。图片作为页面中最”重”的资源，把它管好，对整体性能的提升往往是立竿见影的。
