Optimising one image by hand is easy. Keeping every image on a growing site optimised, forever, without anyone remembering to do it, is the real challenge. The answer is automation: wire compression into your build, your upload flow, or your CDN so optimisation happens by default and badly sized images can never ship. This guide covers the practical patterns for automating image optimisation across common stacks, along with the trade-offs of each.
The techniques mirror what the optimise JPEG tool does interactively — you are simply moving them into a pipeline so they run without you.
Why Automate at All?
Manual optimisation fails for predictable reasons. People forget. New team members do not know the process. A CMS lets editors upload raw camera files directly. A redesign re-imports assets at full resolution. Automation removes the human from the loop so that every image — past, present, and future — is processed to the same standard. The payoff is a permanently lighter site and far fewer performance regressions creeping back in over time. Just as importantly, it frees your team from a tedious, error-prone manual task, letting them focus on work that genuinely needs human judgement while the machine handles the repetitive squeezing of bytes.
Where to Hook In
There are three common places to automate, and most mature setups use more than one:
- Build time: Optimise assets as part of your bundler or static-site build. Deterministic and version-controlled.
- Upload time: Process images the moment a user or editor uploads them, before they reach storage.
- Delivery time: Let a CDN or image service transform and compress on the fly, per request.
Pattern 1: Build-Time Optimisation
If your images live in a repository and are served as static files, optimise them during the build. Most bundlers and static-site generators have plugins that compress JPEG and PNG, generate WebP variants, and emit responsive sizes. Because the build is deterministic, you get the same output every time and can review changes in version control before they ship.
- Add an image plugin to your build tool that handles JPEG compression and metadata stripping.
- Set a quality target such as 80, matching the manual guidance in how to optimise JPEG.
- Generate WebP variants alongside JPEG fallbacks; see JPEG versus WebP for why this matters.
- Emit responsive widths so srcset can serve the right size per device.
- Cache the output so unchanged images are not re-processed on every build.
Pattern 2: Upload-Time Optimisation
When non-technical users upload images through a CMS, you cannot rely on them choosing the right size or format. Intercept the upload and process it server-side: resize to a sane maximum with the same logic as the resize image tool, strip metadata (important for privacy, since EXIF can contain GPS data — see stripping EXIF metadata), compress to your quality target, and store both JPEG and WebP variants. This guarantees clean assets regardless of what was uploaded.
Pattern 3: Delivery-Time Optimisation
A CDN or dedicated image service can transform images on the fly using URL parameters: resize, re-compress, and even auto-negotiate WebP based on the browser's Accept header. This is the least code to maintain and adapts per device automatically, at the cost of relying on a third-party service and its caching behaviour. It is popular precisely because it requires almost no application changes.
Comparing the Three Approaches
- Build time: Deterministic, version-controlled, free; but only covers repo assets and rebuilds can be slow.
- Upload time: Catches user content and protects privacy; needs server logic and storage for variants.
- Delivery time: Minimal code, per-device adaptation; depends on a service and ongoing cost.
Don't Forget Verification
Automation can silently regress when a plugin updates or a config changes. Add a check — even a simple script — that fails the build if any committed image exceeds a byte budget, or monitor real-world image weight as part of your performance tracking. Tie this back to outcomes with our guide on images and Core Web Vitals so you know the automation is actually moving the metrics that matter.
Starting Small
You do not need a perfect pipeline on day one. Start by optimising your existing library in bulk with the compress JPEG tool, then add build-time optimisation for new assets, then layer on upload-time processing if you accept user images. Each step is incremental and independently valuable, and you can stop wherever the returns level off for your site.
Idempotency and Caching
A well-designed pipeline must be idempotent: running it twice should produce the same result, not compound the compression. If your build re-optimises every image on every run, you risk degrading already-optimised files and slowing builds to a crawl. The fix is to track which images have been processed — by hashing the source file, for example — and skip anything unchanged.
Caching the optimised output keyed by the source hash gives you both correctness and speed. New or modified images are processed; everything else is served straight from cache. This is especially important on large sites where re-processing thousands of images on each deploy would be prohibitively slow and could introduce subtle quality drift over time.
Choosing Settings That Scale
When you optimise manually, you can eyeball each image and tune its quality. A pipeline cannot do that, so you need settings that are safe across a wide range of content. A quality target around 80 with metadata stripping and progressive layout is a reliable default that rarely produces visible artefacts on photographs. For categories of image with known characteristics — say, product shots on a white background — you might apply a tailored profile.
The practical way to pick these defaults is to take a representative sample of your real images, run them through the optimise JPEG tool at a few different settings, and find the lowest quality that still looks acceptable across the whole sample. Then codify that as your pipeline default. Revisit it occasionally as your content mix changes.
Monitoring Over Time
Automation is not set-and-forget. Dependencies update, configs drift, and new content types appear. Track the total image weight of key pages over time so a regression shows up as a trend, not a surprise. Pair that with the byte-budget check in your build so a single oversized image fails fast rather than slipping into production unnoticed.
It also pays to log what the pipeline actually did: how many images it processed, the total bytes saved, and any files it skipped or flagged. That visibility turns a silent background process into something you can reason about and tune. When someone asks why a page got heavier, you have an answer at hand rather than a mystery to investigate, and you can spot a misbehaving step long before it affects real users. Over months, these logs also build a useful record of how much bandwidth your optimisation pipeline has saved, which is exactly the kind of concrete number that justifies the effort to the rest of the team.
Conclusion
Automating image optimisation turns a chore people forget into a guarantee the system enforces. Pick build time, upload time, delivery time, or a mix; set a quality target around 80; generate WebP variants; and verify against a budget. To define the exact settings your pipeline should apply, run a few images through the optimise JPEG tool at jpegoptim and codify what works.