网页编辑器项目里，图片往往占页面总资源体积的 50% 以上。
很多站点“做完很好看，但打开很慢”的根因，几乎都和图片策略有关。
结论先说：图片优化要走 4 步闭环
| 步骤 | 目标 | 验收 |
|---|---|---|
| 格式选择 | 先选正确格式 | 摄影图优先 webp/jpeg |
| 体积控制 | 压缩到可接受阈值 | 首屏单图尽量可控 |
| 加载策略 | 避免首屏阻塞 | 非首屏懒加载 |
| 回归验证 | 防止“变快但糊” | 清晰度与性能双达标 |
Step 1：格式选择原则
- 摄影类：
webp/jpeg - 图标类：
svg - 透明背景：
png/webp
不要“一把梭”全部 PNG。
Step 2：按场景设体积阈值
建议：
- Hero 图：尽量压在可控范围
- 列表缩略图：更小优先
- 非关键视觉：优先压缩而非追求原图
可执行阈值示例（按常见营销站）：
- Hero 图：优先控制在 200~400KB
- 列表缩略图：优先控制在 60~120KB
- 图标与装饰图：优先使用 SVG 或更小位图
不同图片类型，处理策略要分开
| 图片类型 | 目标 | 优先策略 |
|---|---|---|
| Hero 主视觉 | 保证首屏感知质量 | 控尺寸 + 优先加载 + 预留宽高 |
| 产品截图 | 保证细节可读 | 保守压缩 + 按设备分尺寸 |
| 博客配图 | 保证阅读流畅 | 中等压缩 + 懒加载 |
| 图标/装饰元素 | 尽量轻 | SVG 优先 |
这一步很关键，因为“统一压缩参数”几乎一定会误伤其中一类图片。
Step 3：加载策略
- 首屏关键图：优先加载
- 非首屏图：懒加载
- 避免一次性加载长页面全部图片
同时建议补齐：
- 不同屏宽提供不同尺寸资源（响应式图片）
- 对首屏关键图预留尺寸，减少 CLS
- 对非关键图延迟加载并设置占位
Step 4：回归验证
至少验证两件事：
- 页面速度确实提升
- 品质没有明显劣化（不出现糊图、错位）
建议增加第三项： 3. 业务指标不受损（停留时长、CTA 点击率不下降）
常见误区：只压缩，不改分发策略
很多团队已经压缩图片，但仍然慢，原因是：
- 同一张大图在移动端和桌面端都被全量下载
- 首屏关键图没有优先级策略
- 长页面图片全部同时请求
所以图片优化是“格式 + 体积 + 分发 + 加载”的组合，不是单点动作。
QA 抽检模板（发布前）
页面：/pricing
检查项：首屏图体积、移动端清晰度、懒加载触发
结果：通过 / 不通过
问题：xxx
处理：xxx
这类模板能帮助内容、设计、前端在发布前快速对齐。
发布后重点看 3 个指标
- LCP：首屏关键图是否真的更快出现
- CLS：图片占位是否足够，页面是否抖动
- 转化相关指标：点击率、停留时长、跳出率是否异常
如果只有 LCP 变好，但跳出率变差，通常说明图片质量或首屏信息表达被破坏了。
失败案例：一键压缩后文字图标糊掉
现象： 性能提升了，但产品图上的文字不可读。
根因： 同一压缩策略用于所有图片类型。
修复：
- 文本密集图使用更保守参数
- 图标与摄影图分策略处理
Checklist
- 图片格式按场景选择
- 首屏图片体积可控
- 非首屏已启用懒加载
- 页面速度有量化提升
- 无明显画质/布局回归
FAQ
Q1：编辑器里直接上传原图行不行？
可用但不推荐，长期会拖慢全站体验。
Q2：先压缩还是先裁剪？
通常先裁剪到目标尺寸，再压缩。
Q3：图片越小越好吗？
不是，关键是“在目标设备上视觉可接受”。
Q4：应该先做全站优化还是先做关键页？
优先关键流量页（首页、落地页、转化页），先拿到明显收益再扩展全站。
Q5：图片优化后需要重新看 SEO 吗？
需要。尤其要确认图片文件名、alt 文本和首屏内容语义没有因为替换资源而变差。