图片优化的核心是在缩小文件体积的同时保持视觉质量。基本流程为：调整到实际显示尺寸、以 75-85% 质量进行压缩、转换为 WebP 或 AVIF 格式、添加懒加载、以及设置明确的 width/height 属性。一项 DebugBear 案例研究 使用这套流程实现了 97.5% 的体积缩减（4.3 MB → 109 KB）。
为什么图片优化如此重要
图片约占网页总体积的 64%（Sanity）。未经优化的图片会直接影响：
| 指标 | 影响 | 原因 |
|---|---|---|
| LCP（最大内容绘制） | 超过 2.5 秒阈值 | 首屏大图体积过大 |
| CLS（累积布局偏移） | 内容在加载时跳动 | 缺少 width/height 属性 |
| 跳出率 | 访客在内容加载前离开 | 首次绘制速度慢 |
| 移动端排名 | 搜索排名下降 | 在多变网络环境下带宽消耗过大 |
三大支柱：调整尺寸、压缩、格式选择
支柱一：调整尺寸——收益最大的单项优化
按实际显示尺寸提供图片是最大的优化。根据 DebugBear 的案例，一张 7108×4744 的照片实际只以 1266×845 显示：仅调整尺寸就将文件从 4.3 MB 降至 495 KB（缩减 89%）。
操作步骤：
- 确定显示尺寸——WordPress.com 建议以上传宽度为内容区域的 1.5-2 倍为佳，可获得清晰效果。
- 在上传前调整尺寸——可使用预览（Mac）、画图（Windows）或 GIMP。
- 使用
srcset和sizes属性添加响应式图片，根据视口大小提供不同宽度（400w、800w、1600w）的版本。
这样浏览器可以为每个视口选择合适的文件——移动端用户下载更小的文件，桌面端用户获得清晰的版本。
支柱二：压缩——有损 vs 无损
| 模式 | 工作原理 | 文件大小 | 适用场景 |
|---|---|---|---|
| 有损 | 永久移除部分数据 | 更小（缩减 40-60%） | 照片、复杂图像 |
| 无损 | 精确保留所有数据 | 较大 | Logo、文字、截图、透明图 |
对于大多数网页图片，以 75-85% 质量进行有损压缩是最佳平衡。WebP 和 AVIF 都支持这两种模式。
支柱三：格式选择——WebP vs AVIF vs JPEG
| 格式 | 与 JPEG 对比压缩率 | 编码速度 | 浏览器支持率（2026） | 适用场景 |
|---|---|---|---|---|
| WebP | 小 25-35% | 快 | 97%+ | LCP 图片、通用场景 |
| AVIF | 约小 50% | 比 WebP 慢 50% | 92%+ | 极限压缩 |
| JPEG | 基准 | 最快 | 100% | 通用兜底格式 |
决策框架：
| 场景 | 推荐格式 |
|---|---|
| LCP/首屏主图 | WebP（编码更快、支持更广） |
| 整体页面体积缩减 | AVIF（压缩率更高） |
| 产品摄影（HDR） | AVIF（广色域） |
| 用户上传内容 | WebP（处理更快） |
| 动画图形 | WebP（支持动画） |
| 含文字/锐利线条的图形 | WebP 无损 |
混合方案（推荐）：参考 Framer 的做法，首次请求时提供 WebP，后台异步转换为 AVIF，后续访问时提供 AVIF。这样可以兼顾快速初始交付和更小的缓存文件。
懒加载与响应式图片
懒加载会延迟加载屏幕外的图片，直到需要时才加载，从而节省带宽并加快首屏加载。为所有首屏以下的图片添加 loading="lazy" 属性即可。
规则：
- 不要懒加载首屏图片——这会延迟 LCP。
- 使用
fetchpriority="high"提升 LCP 图片的优先级。 -
在
<head>中使用rel="preload" as="image" fetchpriority="high"预加载关键 CSS 背景图片。 -
始终为图片元素设置明确的 width 和 height 属性，以防止 CLS。
工具对比
| 工具 | 适用场景 | 格式 | 批量处理 | 费用 |
|---|---|---|---|---|
| Squoosh | 开发者格式对比 | WebP、AVIF、JPEG、PNG | 支持 | 免费 |
| TinyPNG | 设计师单图优化 | WebP、JPEG、PNG | 20 张 | 免费 |
| ImageLean | 注重隐私的浏览器端压缩 | WebP、AVIF、JPEG、PNG | 支持 | 免费 |
| Smush | WordPress 站长 | WebP、AVIF、JPEG、PNG | 批量 | 免费/专业版 |
| Cloudflare Images | CDN 全球分发与缩放 | 自动转换 | 实时处理 | 按量计费 |
| Next.js Image | React/Next.js 项目 | 自动 WebP/AVIF | 自动 | 免费 |
CDN 与插件优化对比
| 方案 | 工作原理 | 优点 | 缺点 |
|---|---|---|---|
| CDN 方案（Cloudflare、Fastly） | 在网络边缘优化并缓存结果 | 零手动操作、自适应设备 | 需要 CDN 订阅 |
| 插件方案（Smush、TinyPNG） | 上传时或通过 API 处理 | 对输出结果有更多控制 | 已有图片需运行批量处理 |
最佳实践：混合方案——CDN 负责实时交付，插件负责上传压缩。CDN 可将国际访客的图片加载时间缩短 50% 以上（DebugBear）。
自动化工作流
CI/CD 流水线
GitHub Actions 可以在每次推送时使用 Squoosh CLI 或 sharp 自动压缩和转换格式。代码库中的所有图片在部署前都会被优化。
无头 CMS
Sanity 等平台支持实时转换来提供优化图片——只需存储一张高质量源图，即可自动获得缩略图、响应式尺寸和现代格式。
电子商务
- WooCommerce：Smush 直接集成——上传时自动压缩、批量优化图片库、CDN 全球分发。
- Shopify：内置流水线处理优化。确保上传的源图尺寸正确，且主题生成了正确的
srcset属性。
修复 PageSpeed Insights 警告
| 警告 | 原因 | 修复方法 |
|---|---|---|
| “正确调整图片尺寸” | 图片大于显示尺寸 | 调整到匹配容器尺寸 + 使用 srcset |
| “使用下一代格式提供图片” | 使用 JPEG/PNG 而非 WebP/AVIF | 使用 Squoosh 或 Smush 自动转换 |
| “延迟加载屏幕外图片” | 所有图片立即加载 | 仅为首屏以下图片添加 loading="lazy" |
| “消除阻塞渲染的资源” | CSS/HTML 中有大段 Base64 编码图片 | 作为独立文件提供；避免对超过几百字节的内容使用 Base64 |
总结
按顺序优化图片：调整尺寸 → 压缩 → 转换为现代格式 → 添加懒加载 → 设置明确尺寸。使用 CDN/插件混合方案实现自动化。从使用 DebugBear 审计网站开始——案例研究中的 97.5% 体积缩减，大多数网站通过这些技术都能实现。
常见问题
有损压缩和无损压缩有什么区别？
有损压缩会永久移除数据以获得更小的文件——适用于照片。无损压缩精确保留所有数据——适用于 Logo、文字和截图。WebP 和 AVIF 都支持两种模式。对于网页图片，75-85% 质量的有损压缩是业界标准。
2026 年应该使用 WebP 还是 AVIF？
LCP/首屏图片使用 WebP（编码更快、支持更广）。追求极限压缩时使用 AVIF（文件更小、编码更慢）。推荐混合方案：首次加载使用 WebP，缓存后的后续访问使用 AVIF。
如何修复 PageSpeed 中“正确调整图片尺寸”和“下一代格式”的警告？
将图片调整为匹配其显示尺寸。将 JPEG/PNG 转换为 WebP 或 AVIF。使用 srcset 配合 <picture> 元素，根据屏幕尺寸和格式支持提供合适的版本。WordPress 用户可以通过 Smush 插件实现自动化。
发表回复