An Image Compression Workflow for Designers and Frontend Developers

The Short Version

Image compression should not rely on designers and frontend developers each making manual guesses.

But you also do not need to start with scripts for every single image.

The practical rule is this:

Use friendly desktop or web tools for everyday files, and use an engineering workflow for long-term project assets.

Start with this tool map:

If you only remember one sentence:

Designers and content teams should use software for everyday assets; frontend developers should turn long-term project assets into a repeatable workflow.

Software Recommendations

TinyPNG: Fastest for a Few Images

TinyPNG is the easiest option when you only need to compress one or two images.

Its biggest advantage is zero learning curve: open the site, drop in the image, download the result. For designers, marketers, and product teams, this is often more practical than learning WebP quality settings.

Good for:

• Blog images
• Social media images
• Website content images
• Non-sensitive assets
• Cases where you do not want to install an app

Not ideal for:

• Unreleased client assets
• Internal screenshots
• Large project asset batches
• Workflows that need fixed naming and output folders

ImageOptim: The Mac App Worth Installing

ImageOptim fits the FreeMac philosophy well: it is Mac-native, free, open source, and drag-and-drop friendly.

It is a good everyday tool for both designers and frontend developers. Drop images into the app, and it can compress them and remove hidden metadata. The official site also explains that it can remove EXIF metadata, thumbnails, comments, and other hidden data before publishing images on the web.

Good for:

• Local compression on Mac
• Avoiding online upload tools
• Removing image metadata before publishing
• Daily drag-and-drop image cleanup

By default, ImageOptim is relatively conservative. If you need smaller files, you can enable lossy optimization in its preferences.

XnConvert: Batch Resize and Format Conversion

XnConvert is useful for designers and content teams that need batch operations.

It is not just an image compressor. It is more like a graphical batch image processor: resize, crop, rotate, convert formats, add watermarks, adjust colors, and export to a chosen folder. The official site says it supports a large number of formats and provides Windows, Mac, and Linux versions.

Good for:

• Resizing a batch of images to 1440px wide
• Converting PNG to JPG or WebP in bulk
• Adding watermarks
• Renaming and exporting many images at once

One licensing note: XnConvert is free for private and educational use. If a company uses it long term, check the official license terms.

Squoosh: Best for Comparing Settings

Squoosh is better suited to frontend developers or visual QA work.

It is not the simplest tool, but it is very good for making decisions:

• Is WebP 80 better than JPG 80 for this background?
• Does this long image still look good at 1440px wide?
• Is AVIF worth generating as an extra format?
• Does a transparent PNG still look clean after WebP conversion?

Squoosh does not have to be the designer's default tool. It is most useful when frontend developers need to choose compression settings intentionally.

HandBrake: Best First Choice for Video Compression

HandBrake is a free and open-source video transcoder for Mac, Windows, and Linux.

If a designer gives you a large .mov or .mp4 file and you only need a smaller web-friendly MP4, HandBrake is much easier for non-technical users than ffmpeg commands.

Good for:

• Compressing large videos
• Converting MOV to MP4
• Exporting H.264 MP4 for the web
• Using presets instead of command-line options

Shutter Encoder: A Graphical Interface for ffmpeg

Shutter Encoder is better for video editors and advanced users.

It uses ffmpeg underneath but gives you a graphical interface. Compared with HandBrake, it can handle more advanced transcoding, trimming, subtitle, queue, and format conversion tasks.

Good for:

• Converting GIF to video
• Batch video transcoding
• More detailed encoding settings
• Video teams preparing web assets

If you do not want designers to remember ffmpeg commands, let them use HandBrake or Shutter Encoder. Frontend developers only need to define the final output requirements.

From Source Files to Production Assets

Software solves the question of how to process one file.

A workflow solves the question of how the team avoids chaos over time.

A stable flow looks like this:

Designer exports source files: PNG / JPG / GIF / original video files
Developer generates web assets: WebP / JPG / PNG / MP4 / WebM
Pages only reference: compressed dist assets

Use a fixed folder structure:

assets-source/    Original exports, not used directly by pages
assets-dist/      Optimized assets, referenced by the website

Designers should deliver high-quality source files. Compression quality, fallback formats, dimensions, naming rules, and production paths should be handled by the engineering workflow.

This is not about making the process more complicated. It prevents the common situation where one person uses an online tool, another exports from Photoshop, and a 12MB GIF quietly lands on the homepage.

Why You Should Not Use Designer Exports Directly

Designer exports are usually made for visual review or further editing, not for direct page loading.

Common problems:

• PNG files exported from Figma, Photoshop, or Keynote can easily be several megabytes.
• Long detail images become slow on mobile if used as large PNG files.
• GIF feels convenient, but the file size is usually poor.
• Manual compression creates inconsistent quality, dimensions, and naming.
• Mixing source files and optimized files makes cleanup difficult later.

The real problem is not which compression app you use. The real problem is whether the whole asset handoff is defined.

Image optimization is not only a designer task, and it should not be a last-minute frontend cleanup step. It should be part of project asset management.

What Designers Should Export

Designers do not need to guess the final web format.

They also should not compress the same image again and again.

Use this simple rule:

Use meaningful filenames:

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

Avoid names like:

Screenshot 2026-07-14 at 3.21.08 PM.png
Untitled-1.png
final-final-new.png

If designers can do this, the rest of the compression and publishing process becomes much easier.

What Frontend Developers Should Handle

Frontend developers should not just "compress it quickly."

They should define a format strategy.

Start with this:

Default compression settings:

WebP long images: quality 75-85
WebP transparent assets: quality 80-90
JPG fallback: quality 75-85
PNG: only as transparent fallback, avoid large PNG files
GIF: avoid when possible
MP4: H.264, crf 23-28

The goal is not to make every file as small as physically possible.

The goal is to create stable team defaults that balance clarity, file size, and compatibility.

Engineering Tools for Frontend Teams

The tools above solve most manual cases.

But when images live in the repo and ship with the product, they should be processed by a repeatable engineering flow.

sharp: Batch Image Processing

sharp is a good fit for project scripts.

Its documentation describes it as a tool for converting large images into smaller, web-friendly JPEG, PNG, WebP, GIF, and AVIF images. It also supports common input formats such as JPEG, PNG, WebP, GIF, AVIF, TIFF, and SVG.

A frontend project can expose one command:

npm run optimize-assets

Then process everything from assets-source/ into assets-dist/.

Every new asset follows the same flow:

1. The designer adds the source file.
2. The developer runs the optimization command.
3. The page references the optimized file.
4. The original source stays available for future regeneration.

ffmpeg: Automated Video and GIF Processing

FFmpeg is the standard tool for video, audio, and format conversion. The official documentation also lists command-line tools such as ffmpeg and ffprobe.

If you need GIF-to-video conversion, video compression, WebM output, bitrate control, or resizing, ffmpeg is usually the right tool.

For a regular GIF without transparency, convert it to video:

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

If you also need WebM:

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

Designers do not need to remember these commands. Put them in project scripts or documentation.

Treat GIF as a Special Case

The biggest problem with GIF is not that it never works.

The problem is that it is expensive.

One GIF can be larger than several images combined. Color quality is limited, and transparent edges can look dirty.

If the GIF does not need transparency, use video:

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

If the animation needs transparency, consider:

• animated WebP
• Lottie
• transparent PNG / WebP sequences

Avoid using lots of transparent GIF files. They are usually large, visually rough, and hard to maintain.

A Practical Folder Convention

Use a structure like this:

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

Pages should only reference assets-dist:

import Image from 'next/image'

export function HeroImage() {
  return (
    <Image
      src="/assets-dist/hero-banner.webp"
      alt="Product homepage preview"
      width={1440}
      height={900}
      priority
    />
  )
}

If you need a fallback, use <picture>:

<picture>
  <source srcset="/assets-dist/detail.webp" type="image/webp" />
  <img src="/assets-dist/detail.jpg" alt="Product detail image" loading="lazy" />
</picture>

Do not reference assets-source from pages. Those files are source assets, not production assets.

Team Agreement

Make responsibilities explicit.

Designers Own

• Exporting high-quality source files.
• Using meaningful filenames.
• Preserving transparency when needed.
• Providing source video or Lottie for motion assets when possible.

Frontend Developers Own

• Optimizing images and videos.
• Controlling dimensions, quality, formats, and naming.
• Ensuring pages only reference assets-dist.
• Providing JPG / PNG / MP4 fallbacks when needed.

The Project Owns

• Providing npm run optimize-assets.
• Documenting the folder convention in README or team docs.
• Checking that pages do not reference assets-source.
• Requiring large images and motion assets to go through the optimization flow before release.

This split matters. Designers should not need to understand WebP, CRF, H.264, or WebM details. Frontend developers should not guess from scratch every time they receive a source file.

Pre-Release Checklist

Before shipping, check:

• Does any page reference assets-source directly?
• Are above-the-fold images too large?
• Have long detail images been converted to WebP?
• Are large PNG files being used as regular images?
• Can any GIF be converted to MP4 / WebM?
• Do videos use muted, playsinline, and loop when appropriate?
• Do images have fixed dimensions or stable containers?
• Do important images have useful alt text?

This is cheaper than debugging a slow page after release.

Final Recommendation

For one or two regular images, use TinyPNG.

If you compress images often on Mac, install ImageOptim.

For batch resizing, format conversion, or watermarking, use XnConvert.

If the image is sensitive, or if you need to compare quality settings, use Squoosh.

For regular video compression, use HandBrake. For advanced GIF and video transcoding, use Shutter Encoder.

For project assets, write a sharp script.

For automated GIF and video processing in a project, use ffmpeg.

The key rule is:

Designers deliver source assets. Developers generate production assets. Pages only reference compressed dist files.

Once this rule is in place, image compression stops being a last-minute manual task and becomes part of the project workflow.