本文约 3,617 字，预计阅读 10 分钟。文中命令与配置均经过实测，可直接参考执行。
引言：装了插件却没变小，问题往往不在插件
很多站长的操作是这样的：后台装一个图片压缩插件，点一下「Bulk Optimize」，看到进度条跑完就以为万事大吉。过几个月打开媒体库一看，单张配图还是 1.8MB，PageSpeed Insights 依旧提示「使用下一代图片格式」。
这里面有两个常见的认知偏差。第一，压缩插件的「一次批量」只处理当时已存在的图片，之后新上传的图片要走「上传时自动优化」开关，而这个开关在不少插件里默认是不开的。第二，压缩插件主要负责「减掉元数据、做有损重编码」，它不会替你改变图片本身的分辨率。一张 4000×3000 的相机原图，压缩完可能仍有 800KB——真正该做的是在上传前把长边缩到 1600px 以内。所以选型之前，先明确插件能替你解决的是哪一段：编码优化、格式转换、尺寸适配，还是三者都要。
原理分析：三款插件的计费口径不一样
三款插件底层都调用了 cwebp、jpegoptim/optipng、pngquant 之类的编码器（云端方案在服务端完成），差别主要在免费额度怎么算和压缩等级怎么分。
| 对比维度 | ShortPixel | Imagify | Smush |
|---|---|---|---|
| 开发方 | ShortPixel | WP Media | WPMU DEV |
| 免费额度口径 | 按图片张数（含缩略图），常见为每月 100 credits | 按流量，常见为每月 25MB（约 250 张） | 不限制张数，但单图超过 5MB 无法压缩 |
| 压缩等级 | Lossy / Glossy / Lossless | Normal / Aggressive / Ultra | 免费版为无损，有损属 Pro 功能 |
| 批量处理 | 有，后台排队执行 | 有，按批次消耗额度 | 有，每次批量上限约 50 张 |
| WebP | 支持生成 WebP / AVIF | 支持，提供 .htaccess / nginx 改写规则 | 本地 WebP 多与 Pro / CDN 能力绑定 |
| 原图备份 | 可选择保留原图便于回滚 | 提供原图备份选项 | 以实际版本为准 |
这张表最该注意的是「按张数」和「按流量」的区别。图片站、摄影博客这类「张数多但单图不大」的站点，Imagify 的 25MB 流量计法反而更耐用；而产品详情页、 banner 大图这类「单图大但数量少」的站点，ShortPixel 按张计费更划算。Smush 不限制张数，对图片数量极大的老站很友好，但 5MB 的天花板意味着你依然得先解决「超大原图」问题。
具体价格档位会随官方活动变动，选型时以官网当前政策为准，不要照抄任何一篇教程里的数字。
保姆级实操：用数据而不是感觉来选型
步骤1：先摸清家底。 在动手之前，先统计媒体库里图片的数量和体积分布，避免插件跑了一半才发现额度不够。
# 统计 uploads 目录里大于 500KB 的图片数量与总体积
find wp-content/uploads -type f \( -iname '*.jpg' -o -iname '*.jpeg' -o -iname '*.png' \) -size +500k \
| wc -l
find wp-content/uploads -type f \( -iname '*.jpg' -o -iname '*.png' \) -printf '%s\n' \
| awk '{s+=$1} END {printf "总字节 %d, 约 %.2f MB\n", s, s/1048576}'
步骤2：校准尺寸再谈压缩。 确认主题的缩略图尺寸是否合理，然后重生成缺失的缩略图，别让浏览器去下载 2560px 的原图。
# 只生成缺失的缩略图尺寸，已存在的不重复处理
wp media regenerate --only-missing --yes
# 查看当前注册的图片尺寸
wp eval 'print_r( wp_get_registered_image_subsizes() );'
步骤3：开启上传时自动优化。 这点最容易被漏掉。三款插件的设置页里都有类似「Optimize images on upload / Automatically optimize new uploads」的开关，必须打开，否则历史图片压缩完，新图片依然原样入库。
步骤4：先用小批量试压缩率。 不要一上来就跑全站。挑 20 张有代表性的图（产品图、截图、照片各几张）单独压缩，记录压缩前后的体积。有损档位建议从中间档（Glossy / Normal）开始，肉眼几乎无损，压缩率却比无损高一大截。
步骤5：核对缩略图是否被一起处理。 用下面这段脚本把某个附件的各个尺寸实际落盘体积打出来，确认插件没有只压缩原图、漏掉缩略图。
<?php
// 临时脚本：查看某附件各尺寸的落盘体积（用完即删）
$id = 1234; // 替换成真实附件 ID
$meta = wp_get_attachment_metadata( $id );
$base = dirname( get_attached_file( $id ) );
printf( "原图：%s\n", size_format( filesize( get_attached_file( $id ) ) ) );
if ( ! empty( $meta['sizes'] ) ) {
foreach ( $meta['sizes'] as $name => $info ) {
$path = $base . '/' . $info['file'];
printf( "%-20s %-16s %s\n", $name, $info['width'] . 'x' . $info['height'],
file_exists( $path ) ? size_format( filesize( $path ) ) : '文件缺失' );
}
}
步骤6：确认额度消耗与回退方案。 压缩前确认插件是否保留原图（ShortPixel、Imagify 均提供相关选项）。有原图备份，才能在客户说「图变糊了」的时候一键回滚。关于图片格式的进一步处理，可以参考用插件自动转 WebP 并兼容旧浏览器。
步骤7：把压缩纳入发布流程。 在编辑规范里写清楚「上传前长边不超过 2000px、优先使用 WebP 或压缩后的 JPG」，插件只做兜底，而不是替人擦屁股。
常见踩坑
- 批量压缩跑一半就停。多数是 PHP
max_execution_time或内存上限被打满，表现为进度条卡在某一页不再动。把批次调小、在低峰时段跑，比盲目加大内存更稳。 - 压缩后图片变糊却不自知。Ultra / Aggressive 档位对含文字的截图非常不友好，锐利的文字边缘会出现振铃伪影。截图类图片建议用无损或中间档。
- 额度悄悄耗尽。ShortPixel 按张数计，缩略图也可能计入；媒体库里一次导入几百张图，额度可能瞬间归零，之后上传的图片就「静默不压缩」了——插件不会报错，只是不动。
- 原图和缩略图体积倒挂。手工改过
add_image_size()后没有重新生成缩略图，浏览器 srcset 会挑到比原图还大的尺寸。 - 透明 PNG 被转成 JPEG。部分插件或主题在处理带透明通道的图片时会出现黑底，务必抽查几张 logo、图标类图片。
- 案例：某外贸站把 3000 多张产品图一次性批量压缩，ShortPixel 免费额度用完后插件进入「等待额度」状态，后续半年上传的图全是原图；更糟的是当时勾选了删除原图，想回滚也回不去。最后只能重新导出原始素材再压一遍。教训是：批量前先算额度，且不要在没有备份的情况下删除原图。
- CDN 缓存住了旧图。压缩完成后前台体积没变，多半是 CDN 或页面缓存没刷新，去 CDN 后台刷新图片目录缓存即可。
- 多插件叠加。同时启用两款压缩插件会出现重复排队、互相覆盖文件的情况，任何时刻只保留一个。
总结
选型可以用三句话定下来：图片多、单图小的资讯站，看 Imagify 的流量计法；图片少、单图大的产品站，看 ShortPixel 的按张计费；老站海量历史图片且预算为零，Smush 的「不限张数」最省心。无论选哪个，都要先做尺寸治理、再开自动优化、最后留好原图备份。压缩插件解决的是编码层面的浪费，它替代不了上传前的尺寸控制——这一点想明白，你就不会再为「压完还是大」而困惑。想进一步优化首屏表现，可以继续看图片懒加载插件的选型与原生 loading 属性与用插件实现图片 CDN 加速与自适应尺寸。
