图片加载慢怎么处理：从压缩、格式到CDN的排查顺序

图片加载慢，多数情况不是服务器带宽不够，而是单张图片体积太大、格式不合适，或者没有设置缓存。
处理顺序建议是：先量出图片实际大小和加载耗时，再压缩和换格式，然后补上懒加载与缓存头，最后才考虑CDN。
下面按这个顺序讲具体操作。

先确认慢在哪一步

打开浏览器开发者工具，切到 Network 面板，勾选 Img 过滤，刷新页面。
重点看三列：Size（传输大小）、Time（耗时）、Status。
如果某张图 Size 是几 MB，问题就是体积；
如果 Size 不大但 Time 很长，可能是服务器响应慢或网络链路问题；
如果第二次刷新仍然重新下载，说明缓存没生效。

也可以用命令行快速看单张图的体积和响应头：

curl -sI https://你的域名/images/banner.jpg | grep -i -E "content-length|cache-control|content-type"

content-length 换算成 MB 就能判断体积，cache-control 为空或 no-cache 说明缓存策略缺失。
这一步不做，后面容易盲目压缩或盲目上CDN。

压缩和换格式是最直接的收益

体积是图片慢最常见的原因。
普通照片类图片压到 100KB 到 300KB 通常肉眼差别不大，图标和插画可以更小。
压缩工具用本地或命令行都行，比如 imagemagick：

convert banner.jpg -quality 80 -strip banner-opt.jpg

-quality 80 是压缩质量，-strip 去掉EXIF等元数据，能再省一点体积。
批量处理可以写成循环，注意先备份原图。

格式上，照片优先转 WebP，同画质下通常比 JPEG 小。
转换命令：

cwebp -q 80 banner.jpg -o banner.webp

然后在页面里用 picture 标签做兼容回退，或直接输出 WebP 并保留原格式备份。
注意：透明背景的 PNG 转 WebP 要确认透明度保留，转换后抽查一张。

懒加载和缓存头别漏掉

首屏之外的图片没必要一次性加载。
原生懒加载只需给图片加属性：

写上 width 和 height 能避免图片加载时页面跳动。
首屏主图不要加懒加载，否则反而拖慢首屏。

缓存方面，在 Nginx 里给图片目录加长缓存：

location ~* \.(jpg|jpeg|png|webp|gif|svg)$ {
    expires 30d;
    add_header Cache-Control "public, max-age=2592000";
}

改完执行 nginx -t 检查语法，再 nginx -s reload 生效。
带哈希文件名的静态资源可以设更长缓存，但图片若经常替换，缓存时间别设太长，或者换文件名再上线。

什么情况才需要上CDN

如果图片已经压缩、缓存也配好，但外地用户仍然慢，再看CDN。
判断条件：用户分布跨地区、源站带宽或出口有限、图片访问量大。
源站在国内、用户也集中在国内，先优化源站往往比直接上CDN更省事。
CDN 的作用是把图片缓存到离用户更近的节点，配置时注意回源地址和缓存规则要和源站一致，否则容易出现更新后用户看到旧图。

改完怎么验证

回到 Network 面板硬刷新（Ctrl+F5），对比改动前后的 Size 和 Time；
用 curl -sI 确认响应头里已经出现 cache-control 和正确的 content-type。
抽查移动端网络下的加载情况，重点看首屏图片是否被误加懒加载。
如果体积降了但依然慢，再回头查服务器响应时间和DNS解析，而不是继续压图片。

几个容易踩的坑

压缩前不备份，画质损失后无法回退；
只在本地替换图片却忘了清CDN缓存；
给首屏大图加懒加载导致白屏时间变长；
缓存时间设得过长，换图后用户长期看到旧版本。
按“先测量、再压缩换格式、补缓存、最后CDN”的顺序处理，多数图片加载慢的问题能在前两步解决。