Image Optimization at Catalog Scale

At ten images, you can tune each one by hand. At ten million, you cannot, so you reach for a preset: one quality setting, applied to everything, forever. It feels like the responsible engineering choice. It is actually the moment the problem starts.

A large catalog is not a big pile of similar images. It is a marketplace of wildly different ones: studio hero shots, seller phone snaps, packshots on white, lifestyle scenes, screenshots, textiles, jewelry, flat vector logos. A single number that suits one of those ruins another.

Scale does not make the per-asset problem smaller. It multiplies it. The wrong compression choice, made once by hand, is a mistake. Made automatically across millions of SKUs, it is a policy.

Key Takeaways

• A diverse catalog has no single correct quality setting, so one preset is wrong on most of it by design.
• Images are the largest contributor to page weight on the median web page, which makes catalog decisions high leverage (HTTP Archive, 2022).
• The fix at scale is not a better preset. It is automated per-asset routing that decides each image on its own content.
• Every asset is verified against a perceptual floor of 0.975 structural similarity before delivery, with fallback for anything that cannot pass.

Why does one preset fail at catalog scale?

Because a catalog is heterogeneous and a preset is homogeneous. A single quality value assumes every image carries the same amount of visual information, which is false the moment your catalog contains both a jewelry macro and a plain packshot. Images already dominate page weight on the median page (HTTP Archive Web Almanac, 2022), so a bad default is expensive everywhere at once.

Picture the spread inside a real marketplace. Some images are almost entirely high-frequency detail and need quality held high to stay convincing. Others are flat, simple, mostly background, and can compress hard with no visible loss at all. One setting cannot serve both. Tune it for the detailed images and you overspend bytes on the simple ones. Tune it for the simple ones and you visibly damage the detailed ones.

So a preset does not remove the per-asset decision. It just makes the same wrong decision on every asset simultaneously. That is why blanket compression backfires precisely at the scale where it looks most necessary, a pattern we unpack in why blanket compression hurts your CMS. Bigger catalog, bigger blast radius.

What makes a large catalog so hard to compress?

Diversity, and the fact that the damage hides. A marketplace with millions of SKUs draws images from many sources, cameras, sellers, and eras, so no two are quite alike in content or quality. Baymard Institute's research shows product image quality directly shapes purchase confidence (Baymard Institute, 2023), which means uneven compression quietly costs sales.

The hard part is that you cannot eyeball ten million images. At small scale, a person notices when a shot looks soft and dials it back. At catalog scale, nobody is looking at any individual result, so degradation ships silently and stays shipped. The only signal on the dashboard is aggregate file size, and file size cannot tell you that texture was lost.

That is the real trap of scale. The thing that broke was quality, and the thing you measured was bytes, so the report says success while the catalog gets worse. We argue the case for retiring file size as the target metric in why file size is the wrong metric. At a million images, an invisible error is not rare. It is systematic.

How do you optimize millions of images without degrading them?

You decide per asset, automatically, and you verify every result. Instead of one preset, each image is evaluated on its own content and routed to the optimization path that fits it. Our Neural Media Orchestrator selects the optimal path per asset from 352 possibilities across more than 1,600 routing decisions, reaching up to 95% neural compression savings on photographic sources at best.

Automation is what makes per-asset decisioning possible at catalog scale. A human cannot tune ten million sliders, but a system can evaluate ten million images and give each the amount of quality it actually needs. The jewelry macro keeps its detail. The plain packshot compresses hard. Neither outcome required a person, and both are correct because both were decided individually rather than averaged.

The safety layer is what makes it trustworthy. Every optimized asset is verified against a perceptual quality floor, structural similarity at or above 0.975 against the original, before it ships. Anything that cannot clear the floor falls back instead of going out degraded. And the whole thing is Pareto-safe by routing, so no asset is ever delivered larger than the strongest adaptive baseline. Related reading on doing this at volume: optimize 1 million images without breaking your site.

Can your CDN handle catalog optimization on its own?

Not the decision part. A CDN is excellent at storing, transforming, and delivering images quickly, and every large catalog needs one. What a CDN does not do is decide how much quality each image should keep. It executes the parameters you hand it, and if you hand it one preset, it faithfully applies that preset to everything.

This is the distinction teams miss. Format conversion, resizing, and edge caching are execution. They move and reshape bytes fast. They do not judge whether a given image can lose quality without a shopper noticing, because that judgment requires evaluating the image's content, not just its dimensions. Hand a diverse catalog a single quality number and the CDN will serve millions of subtly wrong images, quickly.

So the CDN and per-asset decisioning are not competitors. The decision layer chooses the right target for each asset. The CDN delivers it. We spell out where the CDN stops and the decision begins in why your CDN isn't solving your image problem. You need both, doing their own jobs.

How should a marketplace roll this out?

Start with the existing library, then automate new uploads. A one-time scan can process the back catalog in bulk, prioritized by projected savings so the heaviest, highest-traffic images are handled first. From then on, every new SKU is optimized per asset as it enters, with no change to how sellers or merchandisers upload.

The migration risk at this scale is real, and it is worth naming. When you reprocess millions of live images, you need a way to reverse any result that looks wrong, cleanly and fast, without a manual audit of every file. That is why reversibility is not a nice-to-have at catalog scale, a case we make in rollback, the most critical media optimization feature.

The underlying discipline is the same one that governs a single product shot, applied by machine across the whole catalog: decide quality per asset, verify it, keep the fallback. The companion piece on a single high-detail image is product photography without the weight, and the full framework sits in the complete guide to perceptual media optimization.

Frequently Asked Questions

Why can't I just use one quality setting for my whole catalog?

Because a diverse catalog carries different amounts of visual information per image. One setting overspends bytes on simple images and visibly damages detailed ones. At catalog scale that single wrong choice is applied to millions of assets at once, so the error is systematic rather than occasional.

How do you optimize millions of product images automatically?

Each image is evaluated on its own content and routed to the optimization path that fits it, rather than sharing one preset. Automation makes this per-asset decision possible across millions of SKUs, and every result is verified against a perceptual floor before it ships.

Won't automated compression degrade some images without anyone noticing?

Not with verification. Every asset is checked against a structural similarity threshold of 0.975 against the original before delivery, and anything that cannot pass falls back instead of shipping degraded. The system is also Pareto-safe by routing, so no result is ever larger than the strongest adaptive baseline.

Isn't my CDN already handling this?

A CDN stores, transforms, and delivers images fast, but it does not decide how much quality each image needs. It applies whatever parameters you give it. Per-asset decisioning makes that choice for each image, and the CDN then delivers the result.

How do I safely reprocess an existing catalog of millions of images?

Run a one-time library scan prioritized by projected savings, handle new uploads automatically, and keep a fast rollback path. Reversibility matters most at scale because you cannot manually audit every reprocessed file, so any wrong result must be reversible cleanly.

The point

Scale is the reason teams reach for a preset, and the reason a preset is the wrong tool. A million diverse images do not share one correct quality setting, so applying one is not a simplification. It is a decision to be wrong on most of the catalog, silently, forever.

The alternative is not a smarter preset. It is moving the decision onto each individual asset and letting automation carry it across the whole library, with verification on every result and a fallback when a target cannot be met safely. Decide per asset, verify, keep the rollback, and catalog scale stops being the thing that forces you to compromise. More at the complete guide to perceptual media optimization.