Image Optimization Workflow for Client Websites, on a Mac

One place is the handoff. The templates can be flawless and the page still ships a camera original because someone dropped it into the media library on a Friday. Images account for the most bytes on the web: the HTTP Archive Web Almanac 2025 found the median desktop page used 1,059 KB of images and the median mobile page 911 KB, out of a median home page of 2.86 MB on desktop and 2.56 MB on mobile. Images accounted for the most bytes, ahead of JavaScript and fonts.

Those bytes show up in Largest Contentful Paint, which is judged at the 75th percentile of real page loads. A good value is 2.5 seconds or less and anything over 4.0 seconds is poor, per web.dev. Interaction to Next Paint should be 200 ms or less and Cumulative Layout Shift 0.1 or less (web.dev on the three vitals).

Be precise about what file compression can change. Google splits LCP into four sub-parts, with guideline shares of about 40% for time to first byte, under 10% for resource load delay, about 40% for resource load duration and under 10% for element render delay (web.dev, optimize LCP). A smaller file moves one of the four. Discovery, priority and reserved space are markup, and that is developer work that no compressor does for you. We cover it in image optimization for Core Web Vitals, measured and the how-to in image optimization for web developers. This page assumes you have read those or already know them.

What is specific to an agency is how the bytes arrive. Three doors: originals the client or a photographer sends you, exports your own designers make, and files the client’s editors upload after launch. You control the first two, and you can fix them in a folder. The third needs a rule, a plugin or a CDN, and the later sections say which.

Two things stand out. Webflow’s 4 MB is the tightest cap here and a full-size camera original can exceed it, while the 20 MB caps on Shopify and Squarespace reject only the largest. The Webflow figure is from its developer documentation, which is where we could open it, so confirm it in the Designer before you quote it to a client. The surprise is format acceptance. Shopify’s help page lists no AVIF and Squarespace says only .jpg, .gif, .png and .webp, so a blanket “convert everything to AVIF” rule breaks uploads on some hosted builders. AVIF belongs in files you host yourself, behind a <picture> element with a fallback, as MDN advises. For Shopify and Squarespace, deliver WebP or JPEG; Webflow’s documentation lists AVIF, so check the platform you are on.

WordPress needs a second look. It downscales anything over 2560 px, but the core team’s 5.3 announcement says the original image file is stored in the uploads directory, and wp_get_original_image_path() returns where it is. A multi-megabyte original keeps sitting in the uploads folder and in your backups. Downscaling is not the same as never having uploaded it.

Limits change with plans and platform releases, so treat the table as a dated snapshot. For any other CMS, search its help center for “image upload” and write the number into your handoff document.

Start from this table, then adjust it against three of the client’s worst images. Quality numbers are not comparable across AVIF encoders, so judge the output, not the number.

The width ladder is the one from our developer guide: 800, 1600 and 2400 for a full-bleed hero, 720 and 1440 for a content figure, 400 and 800 for cards. A srcset width descriptor has to match the file’s real width, so set the resize mode to width at the rung and open one output to check its pixel width before you run the batch. Use fit only to cap oversized originals, because it limits the longer edge and a portrait image then comes out narrower than the rung. Smol also has presets, which save a set of settings on that Mac; check that a preset holds the format, quality and size you need before you rely on it. The table is the recipe.

Three defaults to know before a client batch. By default, output is a copy next to the original with a _compressed suffix, so originals are not overwritten. Images are resized to fit 2000 × 2000 px unless you change it, and that default is wrong for the 2400 rung. And metadata is stripped by default, which removes GPS from a client’s phone snapshots but also removes embedded credit lines, so keep the masters. Smol keeps the original if compressing would make a file larger.

What does it buy? On our published benchmark, 24 PNG photographs compressed to AVIF at quality 65 came out 92.1% smaller; that starts from lossless PNG, so it flatters the result. Separately, 24 high-quality JPEG photographs recompressed as JPEG at the defaults came out 69.3% smaller, which is the closer comparison if your originals are already JPEG. At matched SSIMULACRA2 scores, Smol’s AVIF needed 22 to 26% fewer bytes than the best JPEG. Those test images are small, 768 × 512 film photographs, so read the percentages as direction, not as a promise for a full-size camera hero. The format question has its own page, AVIF conversion on a Mac, and converting PNG to WebP covers the fallback.

1. 1

   Baseline the page

   Run PageSpeed Insights on the key templates and write down the heaviest images and the image bytes per template. This is the before number for the client report in the last step.

2. 2

   Freeze the originals

   Copy everything the client sent into an originals/ folder and never edit it. It is the master every rung below is cut from. iPhone photos arrive as HEIC: use Compress with the output set to JPG, never Convert, and see converting HEIC to JPG on a Mac.

3. 3

   Make one folder per rung

   By default, Smol writes its output beside the input with a _compressed suffix, so outputs for different rungs would land in the same folder with the same names. Give each rung its own copy of the originals:

   mkdir -p work/800 work/1600 work/2400
   for r in 800 1600 2400; do cp originals/* work/$r/; done

4. 4

   Compress each folder to the table row

   Drop work/1600 onto Smol. Choose Compress, output format AVIF, quality 65, resize mode width at 1600. Do the same for the other rungs. Whole folders and mixed file types work in one batch. Open the three largest outputs and check edges, gradients and any text.

5. 5

   Move the outputs out and name them by width

   Check one output’s name first; the loop assumes name_compressed.avif. Moving the outputs after every pass also keeps the next pass from compressing them again:

   mkdir -p web
   rung=1600; ext=avif
   for f in work/$rung/*_compressed.$ext; do
     b=$(basename "$f" "_compressed.$ext")
     mv "$f" "web/$b-$rung.$ext"
   done

   Repeat for the other rungs. Then run each folder again with output format WebP or JPG (still Compress) and move those the same way. This gives hero-800.avif, hero-1600.avif and hero-2400.avif, with matching fallbacks.

6. 6

   Check that every image got an output

   Smol keeps the original when compressing would make a file larger, which for a format ladder may mean that image has no AVIF and your picture element has a hole. List the gaps (change the extension to match yours):

   for f in originals/*.jpg; do
     b=$(basename "$f" .jpg)
     [ -f "web/$b-1600.avif" ] || echo "missing: $b"
   done

7. 7

   Mark up, measure and report

   Add width and height, srcset and fetchpriority on the one LCP image; the picture markup is in our developer guide. Run PageSpeed Insights again and send the client a before and after line: image bytes per template, and the LCP change.

You cannot stop them with a tool alone. You choose where the check sits, and each place fails differently.

Our default advice is two layers. Put the automatic layer in the CMS, because it catches every editor, and put the spec in the handoff, because it teaches them why a full-size camera original is not a hero. If the client team is on Macs and cares, Smol’s Finder Quick Action makes compression a right-click. It uses whatever settings were last configured in that Mac’s app, and every Mac running Smol needs its own license, so that is a cost to put in the proposal. We wrote up the do-it-yourself Automator version in adding a compress Quick Action to Finder.

A watched folder is tempting for an “upload-ready” drop box, and it has one known defect: it can make already-optimized files larger. Use it only for folders of fresh, unoptimized files such as screenshots or camera exports, never for a folder holding finished assets. The measurement is in watching a folder and compressing what lands in it.

The table’s sources: ImageOptim and Squoosh are compared against Smol in our ImageOptim test and the Squoosh comparison; the roundup of Mac tools is the best image compressor for Mac; and the built-in command has its own guide in the sips command. TinyPNG’s figures are from its homepage, Cloudflare’s from its transformations documentationsharp’s from its own site, and the ImageOptim release date from its update feed, all read on 9 October 2026. Our Smol versus TinyPNG page goes deeper on the upload question.

That upload question is a contract question for an agency. Unreleased campaign imagery and client-supplied product shots may sit under an NDA or a services agreement, so check whether they do; sending them to an online compressor means a third party receives them. Smol processes files on the Mac, has no account, and uploads nothing. Whether a given online tool is allowed under your client agreement is for you and the client to decide; we are not giving legal advice.

A coding agent can, on a Mac with Smol running. Smol includes a Model Context Protocol server, and Claude Code, Codex and Google Antigravity each connect with one click from the Smol for AI panel. The agent then calls compress, convert, strip-metadata and preset tools with explicit parameters, on local files. It cannot touch your license or install updates, every path must be absolute, and originals are not overwritten by default.

Where that fits an agency day: a developer is in Claude Code editing a client’s template, and a folder of new product photos has just arrived. A prompt is enough:

Compress every image in /Users/me/clients/acme/incoming to AVIF at 1600 px wide
and list any file that did not get smaller.

Agents can also list and create presets, so “set up reusable image settings for this client” is a task you can hand over once. The CI side of the same problem, a byte budget that fails the build, is in compressing images before you commit. One caution: Smol keeps files on the Mac, but what your AI client sends to its own model provider is that client’s business. Check its data settings before pointing an agent at embargoed assets.

An agent on your laptop is still not a server. When the compression has to run where your client’s visitors upload files, the paid Smol API (plans from $20 a month) does it on the server side; the Mac app does not belong in that path.

Pay once per Mac. Solo is $29 for one Mac. Team is $49 for three Macs, with seats managed from an admin dashboard. Enterprise is $20 per seat for 5 to 500 seats, so five people is $100. A four-Mac shop buys Team plus Solo ($78) or the five-seat Enterprise minimum ($100). There is no subscription, no per-file quota and no daily cap, and updates are free. The pricing page has the checkout for each.

Consistency comes from two things. The first is the settings table above, copied into your handbook and your client handoff template, because a table is the one artifact every teammate and every client can read. The second is the settings each person enters from it on their own Mac. A preset saves settings on the Mac where it was made, so each person recreates it from the table. We make no promise that two Macs produce identical files, so the written table is the shared artifact, and your check is opening the same three worst images on each machine.

A note on who this is for. Smol needs macOS 13 or later on Apple Silicon, or macOS 14 or later on Intel. A shop with Windows machines in the mix needs the CMS-side layer for those people. If your team spans design, content and campaigns as well as engineering, the design studio and marketing team pages cover their halves of the same handoff, and photographers delivering to clients covers the people who send you the originals.

Seven cases, starting with the two that matter most for production work.

The images live in the repo and CI deploys them. Use a build-time library. sharp writes JPEG, PNG, WebP, GIF, AVIF and TIFF. A build step cannot be forgotten and a desktop app can. Smol is not a build tool for Linux CI.

Editors or visitors upload images all day. Then the transform has to happen at the CMS or at an image CDN, and Smol cannot sit in that path. Cloudflare Images, Cloudinary, imgix and a self-hosted sharp service are all reasonable.

You need many widths of many images. A catalog of hundreds of products at three rungs each is thousands of files by hand. A CDN generates the widths from one master at request time. Smol does the rungs fine for a landing page, not for a catalog; the e-commerce product images page is where that case is treated properly.

You need the pixels untouched. Smol has no lossless mode. Brand masters, print artwork and anything you will re-edit should go through ImageOptim or stay as they are.

You want a script, not an app. A sips loop finished 24 small images in under a second against Smol’s 7. If your batch is recurring and JPEG is enough, script it.

Your deliverable is SVG, or JPEG XL. Smol writes neither. Logos and icons should be SVG, which no raster compressor touches.

Your team is not on Macs. Smol is macOS only. Nobody on Windows or Linux can use it, and that is a hard stop for a mixed team.

Where it earns its price: the pile that never reaches a pipeline. Client originals, press kits, README screenshots, the folder someone AirDropped the hour before launch. For the plain version of that job there is compressing images for the web.