图片优化是 WordPress 性能里最“高回报”的一项：同样的页面结构、同样的主题，只要图片体积、尺寸、格式、交付方式做对，加载体验往往立刻提升。

但图片优化也最容易让人“越弄越乱”，原因不是技术太难，而是信息太碎：
你看了几篇文章，知道要“压缩”“WebP/AVIF”“懒加载”，再看插件介绍又说“每月免费 100 credits”“免费 20MB”“每张图 1 credit”，结果越看越糊涂——到底免费够不够？扣费怎么扣？是不是你理解错了“同一个东西”？以及最关键的：你做完之后到底有没有真的生效？

这篇文章只做三件事：

  1. 给你一条可执行的路线图（先做什么、后做什么）
  2. 把你要选的方案讲清楚（免费/付费到底差在哪、各自适合谁）
  3. 把最常见的坑提前写出来（避免你做完还要到处搜索排查）

1. 底层：WordPress 自带什么，不自带什么

如果你不先搞懂 WordPress 核心已经做了什么，很容易出现两种情况：

  • 该享受的“免费能力”没用上，反而花时间/花钱重复造轮子
  • 以为 WordPress 会“自动把旧图都转 WebP/AVIF”，结果发现并不会

WordPress 核心已经内置了这些关键能力：

  • 响应式图片（srcset/sizes）：从 WordPress 4.4 起，核心会为图片输出 srcset 与 sizes，并利用上传时生成的多尺寸图片，让浏览器按屏幕条件选择更合适的资源加载。
  • 原生懒加载：WordPress 5.5 起默认对图片启用原生懒加载，使用 HTML 标准 loading 属性实现。
  • 支持上传 WebP：WordPress 5.8 起可以像 JPEG/PNG 一样上传并使用 WebP（前提是主机环境支持 WebP）。
  • 支持上传 AVIF：WordPress 6.5 起可以像 JPEG/PNG 一样上传并使用 AVIF（同样依赖主机环境支持）。

但注意：
“支持上传/使用” ≠ “自动转换/自动交付”。
也就是说：就算你已经是 WP 6.5，你的媒体库里那些 JPG/PNG 不会自己变成 WebP/AVIF；你也不会自动获得“按浏览器能力输出 AVIF/WebP、并对不支持的浏览器回退到原图”的完整链路——这部分通常需要插件或服务补齐。

2. 路线图：图片优化按 5 步走

做什么、为什么、做到什么算合格、典型坑是什么。

2.1 先把“尺寸”做对（最容易被忽略，但收益最大）

很多站慢并不是压缩没做，而是下载了远超显示区域的大图：
例如页面实际只显示 900px 宽，你却让访客下载 3000px 原图，浏览器只是“下载完再缩小显示”。这会浪费带宽、增加解码时间、拖慢首屏。

WordPress 4.4+ 的响应式图片机制（srcset/sizes）正是为了解决这个问题。

做到什么算合格：

  • 手机打开页面时，下载的图片尺寸应明显比桌面更小
  • 同一张图在不同设备上加载的资源大小不同（而不是永远下载原图）

最常见的坑：

  • 有的主题/构建器把图当作 CSS 背景图、或用自定义方式输出，可能绕开 srcset，导致一直下大图
  • 你用外链图床、第三方图片块，也可能绕开媒体库生成的多尺寸体系

2.2 压缩（把 KB 降下来，但不要把质量“压坏”）

压缩的核心不是“越小越好”，而是“肉眼几乎看不出差异，但体积下降明显”。

规则如下：

  • 照片/实拍（人物、产品、风景）：优先有损压缩（收益最大）
  • 界面截图/文字多的图片：压缩要更保守，避免文字发虚
  • Logo/图标：优先 SVG 或谨慎无损（有损很容易边缘糊）

做到什么算合格：

  • 大多数页面图片体积明显下降
  • 不出现明显的噪点、糊边、色块断层、文字变糊

2.3 WebP / AVIF（格式策略：同等清晰度更小）

WordPress 已支持上传 WebP（5.8）与 AVIF（6.5）。
但要把“下一代格式”真正用起来，通常要解决两件事：

  1. 历史媒体库如何批量转换（否则你只优化了“以后上传的新图”）
  2. 是生成副本，还是替换原图（这是风险分水岭；后面会重点讲 Plus WebP 的“替换并删除原图”）

推荐写法：

  • WebP：一般作为默认首选（兼容性更稳）
  • AVIF：更进一步的压缩方向，适合大图/首屏大图/相册图（但更依赖环境支持）

2.4 懒加载要用对（不要一刀切）

WordPress 5.5 起默认懒加载图片。
它能减少初始渲染时的带宽占用：

  • 懒加载适合“屏外资源”
  • 首屏最关键那张大图（很多时候是首屏关键图）往往不适合被延后加载

2.5 交付层：CDN / 图片 CDN

压缩、尺寸、格式解决的是“文件更小更合适”。
但如果图片总是从源站远距离拉取，网络延迟仍会明显影响体验。这时就需要“交付层”的方案（CDN/图片 CDN）。

两个典型方向：

  • Cloudflare Polish：Cloudflare 文档介绍了 Polish 的压缩方式（无损/有损/WebP），并提到用 format=auto 允许使用 WebP/AVIF 格式。
  • Jetpack Site Accelerator：Jetpack 文档说明它会优化图片并与静态资源一起通过其网络分发。

图片优化负责变小变合适，CDN 负责交付更近更稳

3. 选型：只走两条主路线

图片优化最常见的失败，不是“没装插件”，而是装了太多插件导致重复处理：
A 在压缩、B 也在压缩；A 在转 WebP/AVIF、B 也在转；A 在改 URL、B 又做重写——最后你自己都说不清站里现在到底发生了什么。

规则：

只走一条路线：要么全免费本地，要么云压缩三选一。

  • 路线 A（全免费本地）：Plus WebP or AVIF + EWWW Image Optimizer（或者只选择其中一个）
  • 路线 B（云压缩三选一）：ShortPixel / Imagify / TinyPNG

3.1 路线 A：全免费本地（Plus WebP or AVIF 或 EWWW）

这条路线的特点是：

  • 你不依赖“按月额度/按张计费”的第三方压缩服务（当然有些功能也可能提供可选服务）
  • 代价是：批量处理可能更吃服务器 CPU/IO，需要你更关注“策略和风险”

3.1.1 Plus WebP or AVIF：核心是“生成/替换”，它不是传统意义的“压缩工具”

  • 生成全量图片时：原始图片文件 ID 会被 WebP/AVIF 覆盖、原始文件会被删除，内容中的 URL 也会被替换。
  • 插件提供 WP-CLI 命令，并提醒：文件多时用 WP-CLI 更可靠。

这意味着：它不是“悄悄帮你生成一份 WebP”，而可能是一次资产迁移（尤其你开启“替换并删除原图”相关选项时）。

两种模式的差别

模式 1：保留原图 + 生成 WebP/AVIF 副本（更稳）

  • 优点：遇到兼容问题更容易回退
  • 代价：磁盘占用会上升（原图 + 新格式 + 多尺寸缩略图）

模式 2：替换并删除原图（更激进）

  • 优点：磁盘不会膨胀得那么快；站内引用直接变成新格式
  • 风险：你在“改资产 + 改引用”，遇到兼容问题排查成本会更高（尤其当某些外部系统或主题逻辑依赖原文件名/路径/格式）

建议

选择“替换并删除原图”前，先做小范围测试 + 有可用备份；不要一上来就全库替换。

Plus WebP or AVIF 的典型坑

  1. 做完全库替换后，某些页面图片显示异常
    原因通常不是“图片坏了”，而是 URL 替换、缓存、缩略图策略等链路里某环没对上。
  2. 缩略图数量越多，改动范围越大
    WordPress 上传一张图会生成多个尺寸；主题/插件还可能增加更多尺寸。全量替换意味着你可能在改动一套很庞大的文件集合。
  3. 只做格式迁移，不等于体积一定最小
    WebP/AVIF 一般更小，但“尺寸策略”和“压缩策略”仍然很关键。不要把 Plus WebP 当成“一键变快”。

3.1.2 EWWW Image Optimizer：免费本地压缩的代表

EWWW 插件页的定位非常明确：

  • 它可以在你的服务器上使用一系列工具进行优化（jpegtran、optipng、pngout、pngquant、gifsicle、cwebp 等）
  • 如果你需要更高压缩或更省 CPU，也可以把耗 CPU 的处理卸载到其服务器（可选）。

EWWW 在路线 A 里应该承担什么角色？

如果你用 Plus WebP 做“格式迁移/替换策略”，那么 EWWW 更适合承担：

  • 压缩与体积优化（尤其是 JPG/PNG 等原始资源的减重）
  • 批量优化历史媒体库（以“体积下降”为目标，而不是“替换 URL”）

注意

Plus WebP 和EWWW ： 均可以转换成AVIF 或 WebP
建议只安装其中一个，否则可能会造成冲突

EWWW 的典型坑

  1. 批量优化时服务器负载升高
    因为本地压缩就是吃 CPU/IO。解决思路不是“别用”，而是“分批、低峰、必要时选择卸载/云方案”。
  2. “生成了 WebP”不等于前台一定在出 WebP
    很多插件都存在这个误会：生成是一回事，交付策略（重写、picture 标签、缓存命中等）是另一回事。
  3. 和别的插件重复做同一件事
    如果你走路线 A，就尽量别再叠加 ShortPixel/Imagify/TinyPNG 之类云压缩；如果你走路线 B，就不要再开 Plus WebP 的替换逻辑。核心原则：一条路线走到底。

3.2 路线 B：云压缩三选一（ShortPixel / Imagify / TinyPNG）

这条路线适合“想省服务器资源、想更省心做批量、接受按额度/按量计费”的人。
但云压缩最容易产生误解的点是：免费额度并不是“免费张数”那么简单。缩略图尺寸数量、是否生成 WebP/AVIF、是否反复重压，都会显著影响消耗。

下面会说明：免费/收费怎么回事、额度怎么扣、最容易踩什么坑、适合什么站点类型。

3.2.1 ShortPixel：100 free credits/月，但 credits 会被缩略图与 WebP/AVIF 放大消耗

免费/付费怎么回事

ShortPixel 插件介绍明确写到：

  • 每月 100 个免费 credits
  • 也有“额外的无限月度 credits”（插件页给出了对应价格信息）
  • 也提供“永不过期的一次性 credits 包”（并给出起始价格信息）

提示：

  • 免费：每月给一定 credits，用于轻量站点或测试
  • 一次性包：适合“媒体库很大、想一次性清库存”的站点（买一次用完为止，通常不会过期）
  • 月度/无限：适合持续更新图片、长期稳定优化的站点

ShortPixel 官方 KB 对“一次性包 vs 无限月度”也给了清晰解释：无限月度是按月（或按年）付费，提供无限 credits，并带固定的 CDN 配额；一次性 credits 不会过期，让你更可控地按需使用。

建议

  • 老站清库：优先考虑一次性包
  • 持续更新：更适合月度/无限（不想算 credits 就用无限

最关键：ShortPixel 的 credits 怎么算？

ShortPixel 官方文档 KB 讲得非常直白：

  • WordPress 上传一张图片会生成多个缩略图；
  • 每个缩略图的优化都会算一个 credit；
  • 如果你选择生成 WebP 或 AVIF，每个原图与缩略图的 WebP/AVIF 版本会额外再消耗一个 credit；
  • 你可以排除某些缩略图不优化以减少 credits 消耗。

credits 示例：

假设你上传 1 张图片，主题/插件生成了 8 个缩略图：

  • 只优化原图+缩略图：1（原图）+ 8（缩略图）= 9 credits
  • 如果还要生成 WebP/AVIF：上面 9 个每个再多一个 next-gen 版本 → 再 +9 credits
    也就是说，你以为“1 张图”，实际可能消耗接近“2 位数 credits”。

所以：“免费 100 credits”并不等于“免费 100 张图”。

ShortPixel 最常见的坑

  1. 免费 100 credits 很快用完
    根因：缩略图多 + 生成 WebP/AVIF 额外 credits。
    建议：
  • 先评估站点缩略图数量
  • 排除不必要的缩略图尺寸（只优化真正会用到的尺寸）
  • 先确定压缩策略再批量跑，避免反复试错消耗
  1. 同时叠加别的转格式插件
    如果你又开 Plus WebP 替换，又让 ShortPixel 生成/插入 next-gen 标签，逻辑会叠加，排查变难。路线 B 就让 ShortPixel 单独负责。
  2. 以为装了就一定“前台在出 WebP/AVIF”
    ShortPixel 插件页提到它能转换 WebP/AVIF，并能把 next-gen 图片加入前台页面（例如通过标签方式）。
    但做完仍然要验证效果。

3.2.2 Imagify：免费 20MB/月；按“原图大小 + 缩略图数量”扣配额，重压会重复扣

免费额度与定位

Imagify 官方价格页写得很明确：免费账户每月 20MB 配额。
它的插件页也明确它能压缩、调整尺寸，并转换 WebP/AVIF。

配额怎么扣？

Imagify 官方文档 “How is Quota Usage Calculated?” 把扣费机制拆得很清楚：

  • 缩略图数量会影响消耗：比如你有 10 个缩略图尺寸，优化 1 张图片会变成优化 11 张（原图 + 10 个缩略图），这些都会贡献配额消耗。
  • 按原始文件大小扣配额：例如你把一张 100KB 的图片发送给 Imagify，就会从配额中扣 100KB。
  • 更改压缩级别并重新优化，会再次消耗配额。
  • 同一个 API Key 可用于多个站点，但配额会在这些站点之间共享。

这就是 Imagify 的“核心理解方式”：
它更像流量包：你送多大，它扣多大；缩略图越多扣得越多；你反复重压会重复扣。

容易看懂的 Imagify 配额示例

假设你上传一张原图 800KB，站点生成 8 个缩略图。

  • Imagify 优化时会把“原图 + 8 个缩略图”都纳入（如果你选择全部优化），也就意味着这一次动作会消耗接近“所有这些文件的原始大小总和”的配额。
    这就是为什么有些站点觉得“20MB 很快用完”：不是 Imagify 不够用，而是你每次上传的图片太大、缩略图太多、并且你可能还反复试压缩级别。

Imagify 最常见的坑

  1. 免费 20MB 不够做“全站历史清库”
    20MB 通常更适合测试与轻量更新；如果你媒体库本来就很大，一次性清库很可能要升级。
  2. 反复调整压缩级别导致配额重复消耗
    Imagify 明确说明重新优化会再次消耗配额。
    建议你在本页就把“策略”写清楚：
  • 先用少量图片确定压缩级别与观感
  • 确定策略后再批量跑
    避免在全库上反复试错
  1. 多站共用 API Key 导致配额“莫名其妙变少”
    如果你把同一个 API Key 用在多个站，配额会共享。
    所以在团队/多站场景，最好明确：哪些站共用，哪些站单独用，以免预算不可控。

3.2.3 TinyPNG（Tiny Compress Images）：免费 500 credits/月；转 WebP/AVIF 会“每个尺寸额外扣 1 credit”

免费额度与它的计费思路

TinyPNG 的 WordPress 插件页写得非常清楚：

  • 每月 500 credits 免费
  • 在“常规 WordPress 安装”里，大概能压缩 约 100 张图片/月
  • 但如果启用 AVIF 或 WebP 转换：每个图片尺寸会额外消耗一个 credit，因此大概只能压缩并转换 约 50 张图片/月（具体取决于你有多少缩略图尺寸）。

同时，Tinify（TinyPNG/TinyJPG 的开发者）也在其 API 定价页写明：注册即可获得每月 500 次免费压缩；超过后是按成功压缩次数计费、没有强制订阅。

用一句话概括 TinyPNG 的理解方式：
它按 credits 计数；缩略图尺寸越多、你开启 WebP/AVIF 越多，就越快消耗 credits。

容易看懂的 TinyPNG credits 示例

假设你站点对每张图片生成 8 个缩略图尺寸：

  • 仅压缩：原图 + 8 个缩略图 → 需要 9 credits
  • 若开启 WebP/AVIF 转换：每个尺寸还要额外扣一次 credit → 可能接近翻倍
    这正对应插件页的说明：开启转换后免费额度大约从“100 张/月”变成“50 张/月”。

TinyPNG 最常见的坑

  1. 以为 500 credits=500 张图
    不是。它按“图片尺寸/变体”消耗。插件页已经明确提醒“转换会对每个图片尺寸额外扣 1 credit”。
  2. 主题/电商插件生成尺寸太多，免费额度下降很明显
    尺寸越多，credits 越容易被放大消耗。
  3. 启用转换后发现额度突然不经用
    这不是 bug，是它的计费机制。
    策略建议：
  • 如果免费阶段主要用于压缩减重，可以先只压缩，等你确认站点结构稳定、确实需要 next-gen，再开启转换

4. 分场景推荐：不同类型站点怎么选

同样是 WordPress，内容站、电商、作品集、会员站的“图片压力点”并不一样。

4.1 内容站/博客（文章图多、更新频率中等）

优先级建议：

  1. 尺寸策略（Step 1）
  2. 压缩（Step 2）
  3. WebP（Step 3）

更适合的路线：

  • 想省心：路线 B 三选一（ShortPixel / Imagify / TinyPNG）
  • 想免费：路线 A（Plus WebP + EWWW），但建议先从“保守模式（不删除原图）”开始评估风险

典型坑：

4.2 电商/产品站（缩略图多、图片变体多、稳定性第一）

电商最容易出问题的地方不是“压缩效果不好”，而是“优化后某些尺寸不对、缩略图缺失、前台组件取不到图”。

优先级建议：

  1. 先稳：压缩策略保守一点、不要一上来就做全库替换
  2. 评估缩略图尺寸：电商主题通常生成更多尺寸，额度消耗会放大（ShortPixel/TinyPNG 特别明显）
  3. 先做小范围验证再批量（非常关键）

更适合的路线：

  • 路线 B 往往更省心：ShortPixel/Imagify/TinyPNG 都能批量，关键是你要理解额度机制，提前评估成本
  • 路线 A 也可以，但要更谨慎对待 Plus WebP 的“覆盖 ID/删除原图/替换 URL”行为：这属于资产迁移，不建议一上来就全量替换。

4.3 作品集/摄影站（单图质量敏感、图片大、对观感要求高）

优先级建议：

  1. 尺寸策略（显示区域控制）
  2. 压缩策略（宁可大一点，也不要把细节压坏）
  3. WebP/AVIF（大图场景收益很明显，但要验证观感）

更适合的路线：

  • Imagify：按“原图大小”扣配额，这种站点更容易做“预算可控”（你知道每张大图大概扣多少），但要避免反复重压。
  • ShortPixel：如果缩略图尺寸不多，credits 也很直观；但如果你生成很多尺寸+next-gen，credits 消耗会放大，需要提前规划。

5. 额度/计费对比：把“免费够不够用”说透

到底选哪个更划算、免费能撑多久？

5.1 三种扣费模型

  • ShortPixel（credits）：按“原图+缩略图数量”计 credits；生成 WebP/AVIF 会对每个对应版本额外扣 credit。
  • Imagify（MB 配额）：按“原始文件大小”扣配额；缩略图越多扣得越多；重压会再次扣。
  • TinyPNG（credits）：每月 500 credits；启用 WebP/AVIF 转换会对每个图片尺寸额外扣 credit。

5.2 快速估算方法

你可以这样估算：

  1. 随便找一张“你常上传的原图”，看它大概多大（比如 300KB / 1MB / 3MB）
  2. 看你站点大概生成多少缩略图尺寸（比如 5 个 / 10 个 / 20 个）
  3. 决定你是否要生成 WebP/AVIF（是/否）

然后用下面的“心算”理解消耗：

  • ShortPixel：每张图≈（1 + 缩略图数）credits；如果生成 WebP/AVIF，≈再翻一倍（因为 next-gen 版本也要 credit）
  • Imagify：每张图≈（原图大小 + 各缩略图大小）扣配额；改压缩级别重压会再次扣
  • TinyPNG：免费 500 credits；如果你站点每张图产生很多尺寸，且启用转换，免费张数会明显下降（插件页给了“约 100 张/月”与“约 50 张/月”的直观预期）

6. 风险提示

风险 1：不要让多个插件重复做同一件事

这是最常见的“灾难源头”

  • 路线 A：Plus WebP or AVIF + EWWW（两者分工，不要同时做同类转换与交付，或者只安装其中一个）
  • 路线 B：ShortPixel / Imagify / TinyPNG 三选一（选一个负责压缩与 next-gen）

风险 2：Plus WebP 的“覆盖 ID / 删除原图 / 替换 URL”属于资产迁移

再次强调：Plus WebP 的描述明确写到全量生成时会覆盖原图 ID、删除原文件，并替换内容 URL。
这意味着它不是“可随时撤回的小设置”，而是一次资产层面的改动。

建议的策略应该是：

  • 先小范围测试（几十张～几百张）
  • 确认前台显示、缩略图、缓存更新都正常
  • 再考虑全库处理

风险 3：云压缩“免费额度”的真实消耗取决于缩略图数量与 next-gen 选择

  • ShortPixel：缩略图和 next-gen 会显著影响 credits
  • TinyPNG：启用 WebP/AVIF 会对每个图片尺寸额外扣 credit
  • Imagify：按原图大小扣，缩略图越多扣越多，重压会重复扣

风险 4：“生成了 WebP/AVIF”不等于“前台在交付 WebP/AVIF”

很多人做完转换后感觉“没变快”，根因是前台仍在出 JPG/PNG（缓存/重写/标签/浏览器协商等任一环没对上）。

7. 做完怎么验证有没有生效

4 个非常简单的验证点：

  1. 同一页面刷新第二次，加载是否更稳定更快（缓存与优化是否起作用的体感）
  2. 手机与桌面加载的图片尺寸是否明显不同（响应式 srcset/sizes 是否发挥作用）
  3. 抽查几张图：是否出现 WebP 或 AVIF 文件/资源（站点是否真的在用 next-gen）
  4. 抽查几张图：放大看是否明显糊、文字是否发虚（压缩质量是否过头）

如果这四条都符合，说明你选的路线已经跑起来了。接下来再去做 CDN “交付层”，整体会更稳。

8. 行动建议

  1. 先选路线：
  • 想尽量免费：Plus WebP or AVIF + EWWW（或者只安装其中一个）
  • 想省服务器资源、按额度付费更省心：ShortPixel / Imagify / TinyPNG 三选一
  1. 先做小范围测试（几十张）
  2. 确认没问题再批量
  3. 需要进一步提升交付稳定性：阅读 CDN 加速

常见问题

1. 我到底要装几个插件？能不能都装上？

尽量只走一条路线。

  • 路线 A：Plus WebP or AVIF + EWWW Image Optimizer（或者只安装其中一个）
  • 路线 B：ShortPixel / Imagify / TinyPNG 三选一
    同一个站里同时让多个插件做“压缩/转 WebP/AVIF/改 URL/交付重写”，最容易越弄越乱、也最难排查。

2. WordPress 不是已经支持 WebP/AVIF 了吗？我还需要插件吗？

需要分清：
“支持上传/使用” ≠ “自动转换/自动交付”。
WordPress 6.5 也不会自动把旧的 JPG/PNG 批量转成 WebP/AVIF，也不会自动帮你做“按浏览器能力输出 AVIF/WebP 并回退”的完整链路。要想让历史媒体库也跟上，通常需要插件或服务补齐。

3. 图片优化里，最“高回报”的到底是哪一步？

通常是 先把“尺寸”做对（srcset/sizes）。
很多站慢不是因为没压缩，而是页面只显示 900px 却让用户下载 3000px 原图。压缩能省 KB，但“尺寸不对”会让你白白多下几倍的数据。

4. 我怎么确认现在加载的是不是“更小的那张”，而不是永远下原图？

看两个现象：

  • 手机打开页面时，下载的图片尺寸明显比桌面更小
  • 同一张图在不同设备加载的资源大小不同
    如果永远下载原图，常见原因是主题/构建器把图当作 CSS 背景图或自定义输出，绕开了媒体库的多尺寸与 srcset。

5. “生成了 WebP/AVIF”是不是等于前台一定在出 WebP/AVIF？

不等于。
生成只是“文件层”完成了；前台是否真的交付 WebP/AVIF，还取决于重写、picture 标签策略、缓存是否命中、浏览器协商是否生效等。你做完一定要“抽查几张图的资源类型”。

6. Plus WebP or AVIF 到底危险在哪？我能不能一键全库跑？

它的风险点不是“压缩”，而是资产迁移级别的改动：

  • 全量生成时可能覆盖原始图片文件 ID、删除原始文件，并替换内容中的 URL。
    所以不建议一上来就全库替换：先小范围测试（几十张～几百张）+ 有可用备份，再考虑全库处理。

7. Plus WebP 的两种模式怎么选：保留原图 vs 替换并删除原图？

简单理解：

  • 模式 1：保留原图 + 生成 WebP/AVIF 副本（更稳）：方便回退，但磁盘会涨（原图 + 新格式 + 多尺寸缩略图）。
  • 模式 2：替换并删除原图（更激进）：磁盘不易膨胀，但你在“改资产 + 改引用”，出现兼容问题排查成本更高。
    站点越复杂（电商/多插件/多尺寸），越建议从更稳的模式开始。

8. EWWW Image Optimizer 免费本地压缩够用吗？会不会把服务器压垮？

EWWW 更像“本地干活的压缩工”：会吃 CPU/IO。
常见情况是批量优化时负载升高，这不代表它“不行”，而是策略要对：分批、低峰、必要时选择卸载/云方案。
如果你追求省心、或服务器资源紧张，路线 B 更省服务器。

9. ShortPixel 的 100 free credits/月，为什么我感觉几张图就没了？

因为 credits 不是“图片张数”，会被缩略图与 next-gen 放大：

  • 原图 + 每个缩略图都算 credit
  • 如果生成 WebP/AVIF，每个对应版本还会额外再消耗 credit
    所以你以为“1 张图”，可能实际消耗接近“2 位数 credits”。ShortPixel

10. Imagify 的免费 20MB/月，为什么也很快用完？

Imagify 更像“流量包”：

  • 按你发送的原始文件大小扣配额
  • 缩略图越多，消耗越大
  • 改压缩级别重新优化，会再次消耗配额
  • 同一个 API Key 多站共用，配额共享
    所以“20MB 很快用完”经常是图片太大、缩略图太多、或者反复试错造成的。

11. TinyPNG 免费 500 credits/月，为什么插件说大概只有 100 张/月，开 WebP/AVIF 后还变 50 张/月？

因为 TinyPNG 的 credits 也会被“尺寸/变体”放大：

  • 常规 WordPress 安装大概压缩约 100 张/月
  • 启用 AVIF 或 WebP 转换：每个图片尺寸会额外消耗一个 credit，所以大概只能压缩并转换约 50 张/月（取决于缩略图尺寸数量）。
    所以 500 credits ≠ 500 张图。

12. 我站里缩略图到底有多少？为什么它会影响这么大？

WordPress 上传一张图会生成多个尺寸；主题/插件（尤其电商）可能还会增加更多尺寸。
云压缩的 credits/配额通常是“原图 + 缩略图一起算”，所以缩略图数量越多，免费额度就越不经用。

13. 懒加载是不是一定能加速？为什么有人说懒加载反而变慢？

懒加载适合“屏外资源”。
如果首屏最关键那张大图也被延后加载，可能拖慢首屏体验。WordPress 5.5 起默认懒加载没问题，但不要“一刀切”。

14. 我走路线 A 或 B，什么时候需要 CDN / 图片 CDN？

压缩、尺寸、格式解决的是“文件更小更合适”；
CDN 解决的是交付更近更稳。
当图片从源站远距离拉取导致延迟明显时，再补 CDN/图片 CDN（例如 Cloudflare Polish / Jetpack Site Accelerator）整体会更稳，阅读 WordPress CDN加速。

15. 做完后我用什么最简单的方法验证“真的生效”？

最省时间的验证法：

  • 同一页面刷新第二次，加载是否更稳定更快
  • 手机与桌面加载的图片尺寸是否明显不同（srcset/sizes 是否发挥作用）
  • 抽查几张图：是否出现 WebP 或 AVIF 文件/资源
  • 抽查几张图：放大看是否明显糊、文字是否发虚