图片优化：我踩过的坑和经验，全在这儿了
图片优化？这玩意儿说起来简单。不就是压一下尺寸吗？但你要真信了这句话——等着网站速度拖垮你的排名吧。 我干 SEO 这么多年，栽在图片上的跟头一只手数不过来。最惨的一次，客户一个电商站，所有产品图都是设计直出的，一张 banner 干到 8MB，你以为在逛高清壁纸网站呢？首页加载 15 秒，跳出率高得离谱，老板差点把我开了。后来我一顿操作，同样的视觉质量，体积砍到 200KB 不到。怎么做到的？往下看，我把那些年流过的泪——全倒给你。大部分图片，根本没被压够
很多人一听“压缩”就皱眉头，觉得画质会糊。其实现代图片格式已经牛到你想象不到的地步了。比如 WebP——谷歌家的，同质量下体积比 JPEG 小 25%～35%。AVIF 更狠，能再小 20%。但选格式不是拍脑袋。我有次全站换成 AVIF，iOS 老版本直接白屏……那个客户是做老年旅游的，用户手里一堆 iPhone 7，你能怎么办？只能灰度降级，搞了个 picture 标签回退方案。折腾好几天。
工具也很关键。设计给的图，我第一件事就是扔进 Squoosh（一个 Google 出的在线工具），对比不同格式的体积。有时候肉眼完全看不出差别，但容量差一倍。打死别用 Photoshop 的“另存为 Web 所用格式”——那算法老掉牙了，压出来的图又大又糊。就 Squoosh 或者命令行用 sharp、imagemagick，自动批量搞。对了，还有个坑：渐进式编码。JPEG 一定要勾上“渐进式”，这样图片会从模糊到清晰逐步呈现，用户至少不用对着白屏发呆。这是体验的细节，但很多教程压根不提。
https://obgeo.oss-cn-beijing.aliyuncs.com/pvc-articles/5b073a63-0636-4c81-99ae-9f91813fbcca.jpg
图片优化工具 Squoosh 操作界面截图
响应式图片——你以为你懂，其实你错了
现在谁还没用过 srcset？但80% 的人写错了，包括几年前的我。常见的错误：只列了一堆宽度，没加 sizes 属性，或者 sizes 瞎写。浏览器不是神仙，它不知道你设备上实际渲染的尺寸，只能依赖 sizes 去估算。举个例子：
<img src='fallback.jpg' srcset='small.jpg 300w, medium.jpg 600w, large.jpg 1200w' sizes='(max-width: 600px) 100vw, 50vw'>
这条规则的意思是：视口宽 600px 以下，图片占满屏宽（100vw）；超过 600px，图片只占一半宽。如果没 sizes，浏览器默认按 100vw 算——你手机上那个 300px 宽的容器里，可能加载了 1200px 的图，流量在燃烧啊。还有，srcset 里的顺序是按宽度从小到大排的，千万别弄反，不然浏览器可能永远选不到合适的源。我见过一个博客，因为写反了，移动端一直拉桌面端大图，debug 到怀疑人生。
https://obgeo.oss-cn-beijing.aliyuncs.com/pvc-articles/03401e3b-0df7-419b-892f-8958d50b8f16.jpg
正确使用 srcset 属性响应式图片代码示例图
懒加载的坑：别把首屏图片也懒加载了
https://obgeo.oss-cn-beijing.aliyuncs.com/pvc-articles/fb3b620b-a7a1-47e4-b7f8-b653495aea26.jpg
懒加载的坑：别把首屏图片也懒加载了
自从 Chrome 原生支持 loading='lazy'，我那个开心啊，以为可以告别一堆脚本。结果——LCP（最大内容绘制）指标直接翻车。首屏的 banner 图，你给加 lazy 干嘛？ 浏览器看到 lazy 就延后下载，用户第一眼看到的就是一个大空框，然后才蹦出来。LCP 不炸才怪。后来学乖了：首屏关键图片一律加 loading='eager'，或者就干脆什么也别加，让它默认 eager。非首屏的图，再用 lazy 不迟。另外，lazy 配合占位符也很重要，不然页面一直抖，布局不稳定又会丢 CLS 分。我用个简单的 <img> 加上宽高属性，或者 CSS aspect-ratio，确保空间先占住。别小看这些分，Google Core Web Vitals 盯着呢。
CDN 和缓存策略——差点让我删库跑路的教训
https://obgeo.oss-cn-beijing.aliyuncs.com/pvc-articles/bc3142d7-f35e-4ab5-be5a-fa3cb77a1dcd.jpg
CDN 和缓存策略——差点让我删库跑路的教训
图片存在 CDN 上，加载飞快，对吧？直到有一天，我更新了产品图，上线半小时了，自己看还是旧的……CDN 缓存刷新不及时，坑死人不偿命。后来我把所有图片 URL 都加了版本哈希，比如 product_v2a3f5.jpg，文件名一变，CDN 直接拉新的。但这样又带来另一个问题：老版本图片还留在存储里，慢慢累积成本。现在我的方案：图片上传时自动生成唯一文件名（用内容哈希），然后设置长期的缓存头（Cache-Control: max-age=31536000, immutable）。immutable 告诉浏览器这文件绝不会变，连协商缓存请求都省了。但前提是你得保证文件名唯一且不变，所以搞个靠谱的构建流程最重要。
还有，图片 CDN 服务商选错了也是灾难。某家有点贵但国内线路稳，另一家便宜但偏远地区加载要 5 秒——做国内业务的可长点心吧。
说到底，图片优化就是个精细活。没有银弹，只有一个个工具试，一个个坑填。但每次看到 Lighthouse 分数涨上去、客户数据变好看的时候——值了。 支持楼主继续更新，这么好的内容值得让更多人看到和学习。 帖子内容很扎实，不浮夸不炒作，真正有用的信息都在里面。 说得很有道理，很多观点都说到点子上了，希望以后能多看到这类帖子。 虽然篇幅不长，但句句都是重点，简洁又有深度，非常不错。 讨论氛围很好，大家都在理性交流，这样的论坛环境太舒服了。 感谢楼主愿意花时间分享，让我们这些后来者能少踩很多坑。 楼主考虑得很全面，不仅讲了方法，还提到了注意事项，非常贴心。 这个话题确实很值得讨论，我也有类似的经历，非常认同楼主的观点。 观点很成熟，分析也很理性，值得大家静下心来认真看一看。 感谢楼主无私分享经验，少走了很多弯路，对我们帮助特别大。 思路很清晰，步骤也很详细，跟着操作应该不会出什么问题。 看了这么多帖子，还是觉得你这篇最实在，条理清晰又容易理解。 这个问题困扰我很久了，看了你的帖子终于有思路了，非常感谢。 认真看完了整篇内容，感觉受益匪浅，期待楼主后续更多优质的分享。 对新手特别友好，解释得很细致，就算零基础也能看懂大半。 支持理性讨论，反对无脑争吵，楼主带了个很好的头。 没想到还有这么多细节，之前一直没注意到，感谢楼主提醒和科普。 楼主的经历很有参考价值，给了我很多新的思考方向，非常感谢。
页:
[1]