WordPress 图片瘦身实操（2026）：2.9MB 大图压到 99KB，不装插件

媒体库是 WordPress 站里最容易失控的一块。文章没写多少，上传目录先涨到了 169MB，我翻了一遍，里面躺着一张 6.2MB 的 PNG 和好几张 7680 像素宽的 JPEG，这些尺寸在手机上根本用不到。

思路不复杂：先看清楚谁在处理你的图，把真正大的那些找出来，上传前压一道，再让 WordPress 自己把子尺寸产出成 WebP。全程用核心钩子，不装图片优化插件，站点加载流程里不多挂东西，也省掉哪天插件互掐的麻烦。

一、先体检，别急着动手

WordPress 处理图片靠 PHP 的图像库，一般是 Imagick 和 GD 两套，站点实际用哪套可以直接问它：

wp eval 'echo _wp_image_editor_choose( array( "mime_type" => "image/jpeg" ) ), "\n";'

把 image/jpeg 换成 image/png、image/webp 各跑一次，就知道哪条路通。我那台跑出来是 JPEG 和 WebP 走 Imagick、PNG 走 GD，原因是 8.1 那份 imagick 缺 PNG 解码器，WordPress 自己检测到之后把 PNG 交给了 GD，不用我操心。两个库对 WebP 的支持单独查：

wp eval 'var_dump( WP_Image_Editor_Imagick::supports_mime_type( "image/webp" ) );'
wp eval 'var_dump( WP_Image_Editor_GD::supports_mime_type( "image/webp" ) );'

接着把真正的大图揪出来，这条按体积倒序列出上传目录里最大的十张：

find wp-content/uploads -type f \( -iname "*.jpg" -o -iname "*.png" \) -printf "%s %p\n" | sort -rn | head -10

我这边第一名是张 2176×1952 的 PNG，6224 KB，第二名是 7680×4320 的 JPEG，2905 KB。225 张附件合计 169MB，问题全集中在头部那几张。

二、上传前先压，这一步最省钱

7680 像素宽对博客没有任何意义，正文里最大也就显示到 1200 上下。用 ImageMagick 一条命令转掉：

convert in.jpg -resize 1200x -quality 82 in_1200.webp

同一张 2905KB 的原图，实测下来转成 1200 宽的 JPEG q82 是 149KB，转成 1200 宽的 WebP q82 是 99KB。如果只换格式不砍尺寸，全尺寸 WebP 还有 853KB，所以顺序是先缩尺寸再挑格式，别指望 WebP 一个把 7680 像素救回来。PNG 那边用 GD 的 imagewebp 也能压，那张 6.2MB 的转 WebP q82 是 332KB，缩到 1200 宽是 108KB。带透明通道的图转完去浏览器里看一眼边缘，透明区域处理不好会变黑底。

三、让 WordPress 自己吐 WebP 子尺寸

每张上传的图 WordPress 都会生成几个子尺寸，默认格式跟着原图走。加一个 mu-plugin 就能把这些子尺寸统一输出成 WebP：

<?php
// wp-content/mu-plugins/webp-subsizes.php
add_filter( 'image_editor_output_format', function ( $mappings ) {
    $mappings['image/jpeg'] = 'image/webp';
    $mappings['image/png']  = 'image/webp';
    return $mappings;
} );

这个钩子是 WP 5.8 引入的，6.7 起默认带了一条 HEIC/HEIF 转 JPEG 的映射，我站跑 6.9。它只管子尺寸，原图仍然留在原格式上，所以想回滚直接删文件就行，历史图片一张都没动。生成质量走 jpeg_quality，WordPress 默认 82，想单独给 WebP 调可以用 wp_editor_set_quality。上这条之前先确认第一节那两条 supports_mime_type 都是 true，不然子尺寸会生成失败。

四、老图要不要重生成

WP-CLI 可以按新格式把老附件的子尺寸重做一遍，先拿一张试：

mkdir -p ~/uploads-bak && rsync -a wp-content/uploads/ ~/uploads-bak/
wp media regenerate 457 --skip-delete   # 457 换成你的附件 ID

这里有个真实的坑：重生成默认会把旧的子尺寸文件删掉，而老文章正文里的图片地址写死在 post_content 里，指向的都是旧文件名，文件一删就裂图。--skip-delete 会把旧文件留在原地，是最省事的保底。全量跑的时候用 --only-missing，只补缺失的尺寸，比无脑 --yes 稳得多。我的做法是老图暂时不动，新上传的图开始生效就够了，真要动老图，先挑一两篇没配图的文章试完再推。

五、验证是不是真的变轻了

改完随便传一张图，看三件事。上传目录里应该出现 .webp 结尾的缩略图；响应头对得上：

curl -sI https://你的域名/wp-content/uploads/2026/09/xxx.webp | grep -i content-type

返回 image/webp 就对了。最后一件事是 du -sh wp-content/uploads/，看总量有没有往下走。同一张图按第二节那套压完，最直观的变化就是首屏从 2.9MB 掉到 100KB 以内。另外 WP 5.5 起图片默认带 loading="lazy"，6.3 起还会自动给最可能是 LCP 的那张图加 fetchpriority="high"，这两样不用自己写。站点前面挂了 CDN 或者边缘缓存的，改完记得刷一下，不然你看到的还是旧图，我这台接的是阿里 ESA，规则和刷新方式在之前那篇 ESA 配置笔记里。

图片这块没必要上插件，核心钩子加几条命令行就够，好处是每一步在干什么你自己清楚。顺手做个备份更稳，方法见我之前写的全站备份与恢复。要是服务器上还缺 WebP 支持，这篇装 ImageMagick webp 扩展的笔记能省点时间。图片和缓存这两块理顺了，一个自建小站的速度基本没什么可挑的。