How to Optimize Images for Next.js, Including Static Export

Often yes. On a server deployment next/image serves correctly sized images, picks a format from the browser’s Accept header (see the Image component reference), lazy loads, and prevents layout shift, per the Next.js images guide. If that is your setup, you do not need another tool in the delivery path. Agencies running many client sites can also see Smol for web agencies.

What it does not do is shrink your repository. It reads the full file you committed and produces smaller variants at request time. A 14 MB source stays 14 MB in git, in every clone and in every CI checkout. This page is about that gap: the source files, and the cases where next/image is switched off. For the page-speed side, see image SEO and page speed.

With output: 'export', image optimization using the default loader is not supported. The static export guide lists it under unsupported features, and says to define a custom image loader instead, for example one that builds Cloudinary URLs. The other documented route is the unoptimized prop, which per the Image component reference serves the source “as-is” with no change to quality, size or format.

That second route is where Smol fits. With unoptimized, the bytes you commit are the bytes your visitors download, so the file must already be the right size, quality and format. Compress it to AVIF or WebP at the width you actually render, then point src at it. For the broader loading picture, see image optimization for Core Web Vitals, measured.

One limit to say out loud: Smol produces one size per run. It does not generate a set of responsive widths from one image, and the default output name is the same for every run (name_compressed.ext). If you need 640, 1200 and 1920 pixel versions for an srcset, that is three runs with renaming, or a build script. For one well-chosen size per image, a single run is enough.

Yes for most photographs, with a fallback. The Next.js docs say AVIF “generally takes 50% longer to encode but it compresses 20% smaller compared to WebP”, and that when you enable both formats, AVIF is preferred for browsers that support it with WebP as the fallback. To enable it on a server deployment, set images.formats to ['image/avif', 'image/webp']. The default is WebP only. Read the The same Image component reference notes that each format is cached separately, which raises storage needs.

For a static export, AVIF means committing the AVIF file. Smol’s own measurements on the benchmark page show the size of the opportunity on 24 small (768 × 512) test photos: AVIF needed 22 to 26% fewer bytes than the best JPEG at the same SSIMULACRA2 score, and compressing those photos from PNG to AVIF at quality 65 saved 92.1%. Camera-size files and illustrations will differ, so judge each by eye. Two honest caveats: the test set is small film photographs, and a browser that cannot decode AVIF needs a fallback in your markup, such as a <picture> element. The AVIF converter page covers the format itself.

Compress before you commit, because git keeps every version forever. Files in public are served from the site root, and statically imported images get width, height and a blurDataURL automatically, per the images guide. Neither feature shrinks the file. GitHub warns above 50 MiB, rejects above 100 MiB per file, and suggests repositories stay ideally under 1 GB.

Hosts have their own ceilings. Cloudflare Pages allows 25 MiB per asset and 20,000 files per site on the Free plan, which matters when an export copies everything in public. A folder of originals straight from a designer can break a deploy long before it breaks a page.

Once a large file is committed, compressing it later does not remove it from history. Our guide to compressing images before you commit explains why, and that is the reason to make Smol the step between the designer’s export and git add.

Choose by who does the final optimization. Smol’s defaults are quality 75, metadata stripped, and images resized to fit inside 2000 × 2000 pixels unless you change it. Quality numbers below are starting points to check by eye, not guarantees.

Quality belongs to the Compress operation, not Convert, so choose the output format inside a compress job. Resize modes are fit (stays inside the box), fill (covers the box and crops, with no control over what is cropped), and width or height. For layout-safe output, use fit or width. Smol keeps the original when a compression would make the file larger, and by default writes a copy next to it.

1. 1

   Find the widest rendered width

   Check the largest size the image displays at in your layout, in CSS pixels. Double it only if you serve high-density screens.

2. 2

   Drag the folder into Smol

   Whole folders and mixed types are fine. Set the output format and quality from the table above.

3. 3

   Set the maximum dimension

   Use the width from step 1 in fit mode. Leave the 2000 px default only if your layout needs it.

4. 4

   Check the result by eye

   Open the copies beside the originals at the size users see. Raise quality if gradients band or text fringes.

5. 5

   Replace the sources and commit

   Move the _compressed copies into public or your assets folder, drop the suffix, and commit. The originals stay wherever you keep them.

Save the settings as a preset so the next export is one drag. Presets live on that Mac, so a team agrees the numbers in the README and recreates the preset on each machine.

Free and built-in options come first because they are often enough.

For a fuller look at one-off methods, see every Mac compression method compared, and image optimization for web developers. If you need compression on a server instead, the Smol API exists for that.

• You need responsive sets or on-demand variants. Smol makes one size per run. A loader, a service or a build script generates widths automatically.
• Your pipeline runs on Linux CI. Smol is a Mac app. Use an image library in the build for automation.
• You need pixel-identical output. Smol has no lossless mode and always re-encodes. ImageOptim’s lossless setting is the answer there.
• Your images are SVG. Smol does not handle SVG, and next/image serves SVG without optimization anyway.
• The project is small and next/image already covers it. If every source is under a few hundred KB, skip the extra step.

Speed note

Smol is not the fastest option: 24 small images take about 7 seconds, where a sips loop takes under one. It is a quality-first step you run before commit, not a hot path.