WordPress图片优化怎么做：压缩、响应式尺寸与首屏加载检查

先挑几张代表性图片处理：一张首屏大图、一张正文说明图和一张列表缩略图。把它们的实际请求、显示效果和加载过程核对清楚，再把有效做法推广到同类图片，比一开始对全库反复压缩更容易知道改动有没有价值。

先找出访客真正下载的文件

进入包含目标图片的正式页面，打开 Chrome 开发者工具的 Network 面板，筛选 Img 后刷新。记录请求 URL、传输量、耗时和响应中的 Content-Type。若图片来自内存或磁盘缓存，这次结果不能代表首次下载成本。

为了做前后对照，可以在开发者工具打开时启用 Disable cache，保持相同视口和网络模拟条件再加载。这个选项影响浏览器缓存，不会替你清除主机或 CDN 缓存。工具操作见 Chrome Network 参考。不要把修改前的首次下载，与修改后的本机缓存命中直接相比。

接着在 Elements 里选中真正的 img 元素。Console 中输入 $0.currentSrc，可以查看浏览器当前选择的图片 URL；这里的 $0 必须是刚选中的图片元素。它与标签里最直观的 src 不一定相同。MDN 的 currentSrc 说明也提醒，该值本身不代表图片已成功加载，仍要结合 Network 的状态和实际显示。

先保存一行自己的记录：页面、图片用途、显示宽度、选中 URL、格式、传输量、是否首屏、开始加载时间。无需一开始统计全部媒体库。你真正要找的是哪一张图、哪一个环节造成了不必要的成本。

例如图片显示约 720 CSS 像素宽，浏览器却取得 4000 像素原图，就值得检查候选尺寸。但资源像素大于显示像素并不自动说明浪费：高密度屏幕需要更多像素，产品放大查看也可能另有大图用途。

按图片任务决定尺寸和画质

文章缩略图要在卡片中清楚表达主题，产品细节图要保留纹理，带中文的流程图要让字能读。这些图片不能用同一个压缩值验收。

图片用途	优先保留什么	先处理哪里
列表缩略图	小尺寸下可辨认的主体与合适裁切	多余画面、过大的候选尺寸
产品与材质照片	颜色、边缘、纹理和细节	实际展示尺寸，压缩后的局部对照
中文流程图或截图	文字、数字、细线可读	排版密度、导出清晰度，必要时减少图内文字
首屏视觉图	主要内容及时出现，手机裁切不丢信息	资源发现时间、尺寸与首屏优先级
点击后放大的细节图	放大时仍有足够信息	缩略图与大图用途分开，避免列表直接下载全部大图

先裁掉无意义的空白和不会展示的区域，再确定所需像素范围，最后比较编码格式与质量。保留原始文件，压缩时从原始文件导出候选，不要反复把已经有损压缩的成品再压一遍。

一个显示为 360 CSS 像素宽的图片，在 DPR 为 2 的屏幕上，720 资源像素宽可以帮助解释清晰度需求。但这不是所有手机图必须导出 720 像素的规定：实际容器、候选尺寸、屏幕密度、浏览器选择和内容细节都会影响结果。

JPEG、WebP 和 AVIF 可作为照片的候选；透明图片和文字图还要检查边缘与小字，有时需要更偏向保真的设置。不同编码器的质量数字不能简单横向比较。“质量 80”并不意味着不同格式都获得相同画质。格式特性可参考 MDN 图片格式指南。

最好用实际成品比较：以页面中的展示尺寸看整图，再放大检查关键细节。产品缝线出现色块、图表数字发虚，即使体积减少也未必值得。图内文字本身过小，则应该重新安排说明，而不是让读者靠一张超大位图勉强放大阅读。

选择一种主要处理方式，弄清它改的是哪一层

处理量少时，可以在本地准备好尺寸和格式后上传；持续大量上传时，可以使用服务器端插件生成候选；已有图片分发服务时，也可能由服务按请求动态处理。它们的操作位置不同，不能只根据“压缩率”选择。

本地处理容易直接检查成品，但后续多尺寸和格式要有一致做法。服务器端插件可以配合媒体上传生成文件，不过会占用处理时间与磁盘。动态图片服务可能保留原 URL 或改用服务域名，必须核对实际响应、缓存以及服务停用后的恢复方式。

以 WordPress Performance Team 的 Modern Image Formats为例，当前说明中，它针对新上传图片生成现代格式，主机支持时默认使用 AVIF，否则使用 WebP；旧图需要重新生成才会处理。其默认行为主要改变衍生尺寸，原上传文件仍可保留为原格式。这是一个具体的处理方案，不等于安装后所有旧页面立即变成同一种图片。

如果站点已经由 CDN 转格式，再启用一个会改写相同图片地址的插件，应先检查职责是否重复。两个工具可能可以配合，但也可能同时改写 srcset、生成多份文件或分别缓存旧版本。先在样本页面验证谁负责生成、谁负责输出、谁负责分发，再决定是否保留两者。

WordPress 自 6.5 起支持 AVIF，但上传与生成尺寸还依赖主机图像库。可以在“工具 → 站点健康 → 信息 → 媒体处理”检查支持情况，先上传样本，确认缩略图能生成。依据见 WordPress AVIF 支持说明。版本符合要求，不代表服务器处理能力一定齐全，也不意味着旧 JPEG 自动全部转换。

响应式图片需要候选正确，也需要模板描述正确

WordPress 可以在生成的图片标记里输出 srcset 和 sizes。前者提供不同尺寸的候选，后者帮助浏览器理解图片在相应视口中占多宽，再结合设备条件选择文件。具体机制见 WordPress 响应式图片文档。

媒体库有多个尺寸，只完成了文件准备。模板直接写死原图地址、外链图片缺少候选，或组件输出不合理的宽度描述，都可能让这些文件没有发挥作用。

四类异常对应不同处理位置：

现象	检查位置	修复方向
没有候选尺寸	组件引用媒体库附件还是仅保存原图URL；前台是否输出响应式标记	让主题或构建器正确输出候选。只在编辑器把图拖小，不会减少原文件下载
有候选，手机却取得明显偏大的图	实际显示宽度、DPR和sizes；三列卡片是否被描述成接近整屏宽	在模板中正确描述布局，避免浏览器高估需要的尺寸；不要随意删掉大尺寸候选
某个候选返回404	尺寸生成结果、迁移文件、路径和CDN	先恢复或重新生成缺失尺寸。主图能打开，不代表派生文件都存在
图片是CSS背景	背景组件在不同设备下实际引用的文件	按背景组件调整对应资源；普通img的候选检查未必适用，缩小背景显示比例也不会自动减少下载量

分别在手机和桌面条件下重新加载，观察 currentSrc 与 Network。只把已经加载大图的窗口拖窄，浏览器可能继续使用现有资源，不能据此认定响应式失效。web.dev 响应式图片说明介绍了候选选择与显示尺寸的关系。

换主题后缺少新模板需要的尺寸，可以在备份后对少量附件测试重新生成。它解决的是派生文件问题，不能修复模板写错的 sizes，也不会自动把 CSS 背景改成响应式图片。

首屏图片要早被发现，正文下方图片可以后加载

首屏慢可能包含不同原因：HTML 返回晚，图片发现晚，文件下载久，或者文件下载完后页面还不能渲染。只有下载阶段确实占据明显时间时，继续压缩才直接对应那个问题。

先通过性能工具确认当前页面的 LCP 元素是否为图片。若是，检查它是否带有 loading="lazy"，是否要等待轮播初始化、滚动或某段脚本执行后才写入地址。LCP 图片不应懒加载；非首屏图片才更适合按需要延后。

对于藏在样式文件中的关键背景图，可以评估提前发现资源的方式；对确认重要的图片，也可以通过合适的加载优先级给予提示。但不要给整页图片全部设置高优先级或预加载，那会让非关键资源也参与竞争。预加载还必须与浏览器最终选择的资源匹配，避免又下载一份未使用的大图。相关原则见 LCP 优化说明。

如果 Network 显示图片下载结束很早，但页面过了很久才显示，应继续查看样式、脚本或组件隐藏状态。图片已经很小，仍继续降低质量，不能解决渲染被阻塞的问题。

另外，为图片预留正确的宽高比例，让正文不必等图片下载完成后再重新排位。模板的宽高属性或组件比例设置应与实际显示协调，手机裁切也要检查。布局稳定性与文件大小是两项检查，参考 CLS 优化说明。

批量处理前，先把一张图的完整路径验收完

完整链路可以按这个顺序看：原文件是否合适，派生尺寸是否生成，模板是否引用正确候选，CDN 是否返回新版本，浏览器是否及时取得并显示。哪一层没有变化，就在那一层查原因。

格式转换尤其要看响应 Content-Type 与实际内容。有些图片服务通过协商保持原 URL 后缀，却返回 WebP 或 AVIF；所以看到 .jpg 不足以判断没转换。反过来，有新后缀也不能代替文件可访问和画质检查。

如果模板仍引用旧 URL，先修组件和候选；引用已更新但响应旧，检查页面或图片缓存；候选路径 404，先修生成和迁移。分发层的检查可接着看 WordPress CDN 配置。不要在这些问题没定位时重复压缩同一张原图。

小样通过后，再按图片用途分批处理。处理前确认原文件保留方式、恢复路径、磁盘余量，以及工具对旧缩略图的处理。转换成功后也不应立刻清理所有旧文件，因为旧文章、缓存页或其他组件可能仍引用它们。媒体引用与清理问题可继续看媒体库管理与优化。

每批完成后，用原测试条件核对三件事：

1. 请求确实改变。 比较选中 URL 或响应格式、实际传输量、开始加载时间，确认作用在目标页面上。
2. 内容仍然清楚。 检查手机与桌面的产品细节、中文文字、透明边缘和裁切，没有为了体积牺牲关键信息。
3. 阅读没有新问题。 首屏可及时显示，滚动时图片不会持续推开正文，点击放大和图片链接仍正常。

若图片请求已改善，整页仍慢在 HTML 响应或复杂脚本，就转到WordPress 速度优化继续定位。图片优化有自己的效果与边界，不需要用一次总分决定它是否有意义。 已明确是 HTML 等待时，再按WordPress 缓存设置与验收检查；不要继续重复压缩已经合适的图片。