设计师和前端都该有的图片压缩流程：从原图到线上资源

先说结论

图片压缩不要只靠设计师和前端“各凭经验手动处理”，但也没必要一上来就写脚本。

更现实的选择是：普通人用图形界面软件，项目资源再进入工程化流程。

可以先按这个表选工具：

如果只记一句话：

设计师和内容同事优先用软件解决日常问题，前端负责把长期项目资源沉淀成统一流程。

软件推荐：不同人用不同工具

TinyPNG：少量图片最快

TinyPNG 适合临时压一两张图片。

它最大的优点是没有学习成本：打开网页、拖入图片、下载结果。对设计师、运营、产品来说，这比研究 WebP 参数更实际。

适合：

• 文章配图临时压缩
• 小红书、公众号、官网配图
• 非敏感素材
• 不想安装软件的场景

不适合：

• 客户未发布素材
• 内部截图
• 大批量项目资源
• 需要固定命名和输出目录的工程流程

ImageOptim：Mac 上最值得装的图片压缩工具

ImageOptim 很符合 FreeMac 的推荐标准：Mac 原生、免费、开源、拖拽即用。

它适合放在设计师或前端的 Mac 里当常备工具。图片拖进去后，它会自动做压缩和元数据清理。官方也说明它可以移除 EXIF、缩略图、注释等隐藏信息，适合发布到网页前做一次清理。

适合：

• Mac 本地压缩 PNG / JPG / SVG / GIF 等素材
• 不想上传图片到在线服务
• 发布前清理图片元数据
• 设计师和前端日常拖拽处理

默认情况下，ImageOptim 偏谨慎，主要做不明显损伤画质的优化。如果想更小，可以在偏好设置里开启有损压缩。

XnConvert：批量改尺寸和转格式

XnConvert 适合设计师和内容团队做批处理。

它不是单纯压缩工具，更像一个图形界面的批量图片处理器：可以批量 resize、crop、rotate、改格式、加水印、调颜色。官方页面写到它支持大量常见图片格式，也提供 Windows、Mac、Linux 版本。

适合：

• 一批图片统一缩到 1440px 宽
• 批量把 PNG 转 JPG / WebP
• 批量加水印
• 批量改命名和输出目录

需要注意的是，XnConvert 对个人和教育用途免费；如果公司长期使用，要按官方授权规则购买 license。

Squoosh：给前端对比参数

Squoosh 适合前端或对画质比较敏感的人。

它不是最省事的工具，但它很适合做判断：

• WebP 80 和 JPG 80 哪个更适合这张背景图？
• 长图缩到 1440px 宽会不会糊？
• AVIF 是否值得多生成一份？
• 透明 PNG 转 WebP 后边缘是否干净？

所以 Squoosh 不一定是“设计师首选”，但它是前端判断压缩策略时很有用的工具。

HandBrake：普通人压视频首选

HandBrake 是免费开源的视频转码软件，支持 Mac、Windows、Linux。

如果设计师给了一个很大的 .mov 或 .mp4，但只是想放到网页上循环播放，HandBrake 比 ffmpeg 命令行更适合普通用户。

适合：

• 大视频压小
• MOV 转 MP4
• 给网页导出 H.264 MP4
• 普通用户用预设快速处理视频

Shutter Encoder：图形界面的 ffmpeg

Shutter Encoder 更适合视频编辑和进阶用户。

它底层使用 ffmpeg，但提供图形界面。相比 HandBrake，它能处理更多转码、剪切、字幕、队列、格式转换之类的任务。

适合：

• GIF 转视频
• 视频批量转码
• 需要更细的编码参数
• 视频编辑人员交付网页素材

如果你不想让设计师记 ffmpeg 命令，可以让他们用 HandBrake 或 Shutter Encoder；前端只需要定义最终格式要求。

从原图到线上资源的流程

软件解决的是“怎么处理单个文件”，流程解决的是“团队以后怎么不乱”。

更稳的流程应该是：

设计师导出原图：PNG / JPG / GIF / 视频原文件
开发统一压缩：WebP / JPG / PNG / MP4 / WebM
页面只引用：压缩后的 dist 资源

目录也应该固定下来：

assets-source/    原始导出，不直接给网页用
assets-dist/      压缩后资源，页面只引用这里

设计师只管交付高质量原图。压缩质量、格式兜底、尺寸限制、文件命名和线上路径，都交给工程流程处理。

这不是为了把事情变复杂，而是为了避免一个很常见的问题：今天 A 同学用在线工具压了一张图，明天 B 同学用 Photoshop 另存了一张图，后天页面里又混进一个 12MB 的 GIF。

为什么不能直接用设计师导出的原图

设计师导出的原图通常是给“视觉检查”和“二次加工”准备的，不是给网页直接加载的。

常见问题有几个：

• Figma、Photoshop、Keynote 导出的 PNG 很容易几 MB 起步。
• 详情长图如果直接用 PNG，移动端打开会非常慢。
• GIF 看起来方便，但体积通常很差，同样一段动画转成 MP4 后可能小很多。
• 每个人手动压图，质量、尺寸、命名都不统一，项目越做越乱。
• 页面里混用原图和压缩图，后期很难判断哪个文件能删、哪个文件还在被引用。

所以真正要规范的不是“用哪个压缩软件”，而是整个交付链路。

图片优化不是设计师一个人的事，也不是前端上线前临时补救的事。它应该是项目资源管理的一部分。

设计师应该怎么导出

设计师不需要提前猜线上格式，也不需要把图片反复压缩。

推荐规则很简单：

文件命名也尽量有语义：

hero-banner.png
pricing-card-bg.jpg
product-step-01.png
login-flow-demo.gif

不要用这种名字：

截图 2026-07-14 下午3.21.08.png
未命名-1.png
final-final-new.png

如果设计师能做到这一步，后面的压缩和发布就会轻很多。

前端应该怎么处理

前端要做的不是“随手压一下”，而是把格式策略固定下来。

可以先按这个表执行：

压缩参数可以先用这套默认值：

WebP 长图：quality 75-85
WebP 透明素材：quality 80-90
JPG 兜底：quality 75-85
PNG：只作为透明兜底，不建议用于大图
GIF：能不用就不用
MP4：H.264，crf 23-28

这里的关键不是追求“压到最小”，而是找到一个稳定的团队默认值。

图片压缩永远是在清晰度、体积、兼容性之间做取舍。你需要的是可重复的流程，而不是每次上线前重新肉眼判断。

前端工程化工具

上面的软件解决了大部分手工场景。但如果图片会进入项目仓库、跟着版本发布，就应该有工程化处理。

sharp：项目批量压图

sharp 适合写进项目脚本。

官方文档说明，它常见用途就是把大图转换成更小、更适合 Web 的 JPEG、PNG、WebP、GIF、AVIF 等格式，也支持读取 JPEG、PNG、WebP、GIF、AVIF、TIFF、SVG 等图片。

前端项目可以写一个统一命令：

npm run optimize-assets

然后把 assets-source/ 里的图片统一输出到 assets-dist/。

这样每次新增图片时，流程都一样：

1. 设计师放原图。
2. 开发运行压缩命令。
3. 页面引用压缩后的文件。
4. 原图保留，方便以后重新生成。

ffmpeg：项目视频和 GIF 自动处理

FFmpeg 是处理视频、音频和格式转换的标准工具。官方文档里也专门列出了 ffmpeg、ffprobe 等命令行工具。

只要涉及 GIF 转视频、视频压缩、生成 WebM、调整码率和尺寸，基本都绕不开它。

例如普通 GIF 没有透明背景，优先转视频：

ffmpeg -i demo.gif -movflags faststart -pix_fmt yuv420p -vf "fps=24,scale=960:-2" -c:v libx264 -crf 24 demo.mp4

如果需要 WebM：

ffmpeg -i demo.gif -vf "fps=24,scale=960:-2" -c:v libvpx-vp9 -crf 32 -b:v 0 demo.webm

这类命令不需要设计师记。它应该沉淀到项目脚本或文档里。

GIF 要单独管

GIF 最大的问题不是不能用，而是太贵。

很多页面里一个 GIF 就能顶好几张大图。更麻烦的是，GIF 的颜色表现也有限，透明边缘还容易脏。

如果 GIF 没有透明背景，推荐转成视频：

<video autoplay muted loop playsinline>
  <source src="/assets/anim/demo.webm" type="video/webm" />
  <source src="/assets/anim/demo.mp4" type="video/mp4" />
</video>

如果 GIF 需要透明背景，优先考虑：

• animated WebP
• Lottie
• 透明 PNG / WebP 序列帧

不要大量使用透明 GIF。它通常体积大，颜色脏，也不适合长期维护。

一个可执行的目录规范

项目里可以定成这样：

public/
  assets-source/
    hero-banner.png
    app-demo.gif
    product-detail-long.png

  assets-dist/
    hero-banner.webp
    hero-banner.jpg
    app-demo.webm
    app-demo.mp4
    product-detail-long.webp
    product-detail-long.jpg

页面里只引用 assets-dist：

import Image from 'next/image'

export function HeroImage() {
  return (
    <Image
      src="/assets-dist/hero-banner.webp"
      alt="产品首页展示图"
      width={1440}
      height={900}
      priority
    />
  )
}

如果需要兜底，可以用 <picture>：

<picture>
  <source srcset="/assets-dist/detail.webp" type="image/webp" />
  <img src="/assets-dist/detail.jpg" alt="产品详情长图" loading="lazy" />
</picture>

注意：assets-source 里的文件不要直接进页面。它们是素材源，不是线上资源。

团队协作时怎么约定

你可以把规则写得更明确一点：

设计师负责

• 导出高质量原图。
• 使用清晰文件名。
• 保留透明素材的透明通道。
• 动效尽量提供视频源文件或 Lottie。

前端负责

• 统一压缩图片和视频。
• 控制尺寸、质量、格式和命名。
• 页面只引用 assets-dist。
• 必要时提供 JPG / PNG / MP4 兜底。

项目负责

• 提供 npm run optimize-assets。
• 在 README 或团队文档里写清楚目录规范。
• 上线前检查是否误用了 assets-source。
• 大图和动效进入页面前必须经过压缩流程。

这个分工很重要。不要让设计师为 WebP、CRF、H.264、WebM 这些细节负责，也不要让前端每次都重新猜设计原图应该怎么导。

上线前检查清单

每次发版前可以快速过一遍：

• 页面里有没有直接引用 assets-source？
• 首页首屏图片是否过大？
• 详情长图是否已经转 WebP？
• 是否还有大体积 PNG 被当作普通图片使用？
• GIF 是否能转成 MP4 / WebM？
• 视频是否加了 muted、playsinline、必要时 loop？
• 图片是否有明确的 width、height 或稳定容器尺寸？
• 重要图片是否写了合理的 alt？

这一轮检查比“上线后发现页面慢再回头排查”便宜得多。

最终建议

如果只是偶尔压一两张普通图片，用 TinyPNG。

如果你在 Mac 上经常压图，装 ImageOptim。

如果要批量改尺寸、转格式、加水印，用 XnConvert。

如果图片敏感，或者你想细看格式和质量差异，用 Squoosh。

如果是普通视频压缩，用 HandBrake；如果是 GIF / 视频高级转码，用 Shutter Encoder。

如果是项目资源，写 sharp 脚本。

如果项目里要自动处理 GIF 和视频，用 ffmpeg。

最重要的是这句话：

设计师交付原图，开发统一生成线上资源，页面永远只引用压缩后的 dist 文件。

这个流程一旦固定下来，图片压缩就不再是上线前的临时手工活，而是项目工程的一部分。