Images are typically the largest single payload on an Adobe Commerce storefront, accounting for 50-80% of total page weight on a typical product detail page. They are also the dominant driver of Largest Contentful Paint on most pages, because the LCP element on a PDP is almost always the primary product image, and the LCP element on a homepage is almost always the hero banner. This makes image optimization one of the highest-leverage performance interventions available to a mid-market Adobe Commerce retailer, and one of the most consistently underdone.
This article describes how image optimization actually works on a serious Adobe Commerce implementation: what CDN approaches deliver the largest gains, which image formats matter and which do not, how lazy loading should and should not be implemented, and the operational discipline that distinguishes one-time wins from sustained performance. The framing here reflects how Bemeir’s Adobe Commerce performance team actually structures these engagements for mid-market retailers.
What “at scale” actually means
Image optimization is straightforward in principle and operationally challenging in practice. A retailer with a hundred SKUs and three banner images can hand-optimize every asset and the result will be excellent. A retailer with twenty thousand SKUs, six languages, multiple stores, and a continuous merchandising cadence cannot. The operational problem is keeping every asset optimized across an evolving catalog, an evolving design system, and an evolving set of devices and network conditions.
“At scale” means the optimization has to happen automatically, in the delivery layer, without manual intervention. The retailer’s merchandising team uploads a 4 MB product photo; the visitor receives a 60 KB WebP at the right dimensions for their device. That delivery transformation is what serious image optimization looks like, and it is not something Magento does natively. It requires an image CDN, configured correctly, integrated with the storefront, and maintained as part of the performance discipline.
The CDN-layer transformation
The right architecture for Adobe Commerce image delivery is a CDN that applies format conversion, dimension resizing, quality adjustment, and compression at the edge, based on the requesting device and network conditions. The major options in this category are Cloudinary, Imgix, Fastly Image Optimizer, Cloudflare Images, and AWS CloudFront with Lambda@Edge transformations. Each has trade-offs.
| CDN approach | Strengths | Trade-offs | Typical Magento fit |
|---|---|---|---|
| Cloudinary | Most powerful transformation API, AI-driven content-aware resizing | Higher per-image cost at scale | Premium DTC brands with heavy merchandising |
| Imgix | Excellent URL-based transformation, good developer ergonomics | Less Magento-native integration | Mid-market with strong engineering team |
| Fastly Image Optimizer | Integrates with existing Fastly delivery layer | Requires Fastly as primary CDN | Already-on-Fastly retailers |
| Cloudflare Images | Affordable at scale, decent transformation | Less powerful transformation API | Cost-conscious mid-market |
| AWS CloudFront + Lambda@Edge | Maximum control, minimum vendor lock-in | Highest engineering investment | Enterprise with strong AWS team |
The choice matters less than the discipline. Any of these tools, configured correctly and integrated into the storefront, will produce 200-600 ms of LCP improvement on mobile. The discipline is in the integration: the storefront has to actually request the transformed image, with the right dimensions for the device, in the right format for the browser, and the merchandising team has to upload assets in a way that lets the CDN do its job.
Format selection: WebP, AVIF, and the long tail
The format question has settled meaningfully over the last two years. WebP is universally supported on modern browsers and produces 25-35% smaller files than JPEG at equivalent visual quality. AVIF is supported on the latest two years of browser releases and produces another 20-30% reduction beyond WebP. The pragmatic delivery pattern serves AVIF to browsers that support it, falls back to WebP for everything else, and only serves JPEG to very old browsers (a vanishingly small share of mid-market eCommerce traffic).
According to the HTTP Archive’s Web Almanac, the share of eCommerce sites serving modern image formats has climbed from roughly 15% in 2022 to over 60% in 2025, and the top quartile of performance-optimized sites is well above 90%. Adobe Commerce sites in the bottom half of this distribution have meaningful LCP improvement available simply by enabling format negotiation at the CDN layer.
The image-server pipeline Bemeir’s Hyvä migration team typically deploys for clients applies WebP/AVIF negotiation by default, with quality settings tuned per use case: 75% quality for product detail images, 70% for category thumbnails, 65% for non-critical decorative imagery. The visual difference at these quality levels is essentially imperceptible; the file size difference is dramatic.
Lazy loading: what to do and what not to do
Lazy loading is one of the most misapplied performance techniques on Adobe Commerce. Done well, it dramatically reduces initial page payload and improves LCP. Done badly, it actively hurts LCP because the LCP image itself gets deferred. The pattern that works:
Eager load the LCP element. The hero image on the homepage, the primary product image on the PDP, the category banner on the CLP. These are the LCP elements. They must NOT be lazy-loaded. They should be preloaded with `<link rel=”preload”>` in the document head and served with `fetchpriority=”high”`.
Lazy load below-the-fold images with native browser lazy loading. Modern browsers support `loading=”lazy”` on `<img>` tags. This defers image loading until the image is near the viewport. The performance impact is meaningful on PDPs with image galleries and on category pages with long product grids.
Do not lazy load images that are above the fold for the typical viewport. This sounds obvious and is consistently violated. Many third-party Adobe Commerce theme implementations lazy-load every image by default, including ones that are visible on initial render. The result is LCP that is artificially worse than it needs to be.
Do not use third-party JavaScript lazy loading libraries when native lazy loading exists. The native browser implementation is faster, more reliable, and free. Most legacy Adobe Commerce sites still use a JavaScript lazy loading library from 2017 because it shipped with the theme. The remediation is to remove the library and rely on native `loading=”lazy”`.
The Magento-specific catalog image pipeline
Adobe Commerce has its own catalog image processing pipeline that generates resized variants of every product image. The default configuration is reasonable but rarely optimal for high-traffic sites. The catalog image cache should be tuned to generate the dimensions actually used by the storefront, the cache should be regenerated proactively when product images change, and the cache should be served through the CDN with appropriate cache headers.
The specific Magento configuration that matters lives in `view.xml` files for each theme. Most mid-market sites have inherited the default theme configuration and have never re-evaluated whether the generated dimensions match the dimensions the storefront actually uses on modern devices. The result is the storefront requesting one set of dimensions, the catalog cache generating a different set, and the browser doing unnecessary work to resize the delivered image. The remediation is to audit the `view.xml` configuration against the actual storefront usage and align them.
Responsive images and srcset discipline
Modern responsive image delivery uses the `srcset` and `sizes` attributes to give the browser multiple image variants and let it choose the one appropriate for the user’s device and viewport. Done correctly, srcset can reduce the bytes-delivered for a product image on a mobile device by 60-80% relative to serving the desktop variant.
Done incorrectly, and most Adobe Commerce sites do this incorrectly by default, srcset attributes are generated by the theme without awareness of the CDN’s transformation URL pattern, and the result is the browser requesting images that don’t exist or that aren’t properly cached. The audit and remediation work is to align the srcset generation with the CDN’s URL structure, so every srcset entry actually maps to a CDN-transformed asset.
According to Google’s Core Web Vitals best practices documentation, responsive image delivery is one of the highest-leverage interventions for LCP improvement on mobile traffic. The implementation is fiddly but the impact is large.
The operational discipline
The hardest part of image optimization at scale is not the technical implementation. It is the operational discipline that maintains the optimization over time. The merchandising team uploads new images. The marketing team launches new campaigns. The product team adds new categories. Each of these events is an opportunity for the optimization pipeline to break, and most do break eventually.
The discipline that prevents this looks like: monitoring image weight as a Core Web Vital input via Real User Monitoring, alerting when median image weight on key page types exceeds defined thresholds, requiring CDN transformation as a default for all storefront image references, and quarterly audits to catch drift. Adobe Commerce sites that maintain strong CWV scores over multi-year periods are doing this kind of operational work, not relying on a one-time configuration.
Bemeir’s Adobe Commerce performance practice typically scopes image optimization work as both an initial implementation engagement (4-8 weeks to set up the CDN integration, format negotiation, lazy loading discipline, and srcset alignment) and an ongoing monitoring service (light-touch quarterly check-ins to catch drift). The combination is what produces sustained performance, not just an initial improvement that decays over the following year.
What good looks like
A well-optimized Adobe Commerce storefront delivers product detail page images at 60-150 KB on mobile, in WebP or AVIF format, with appropriate dimensions for the device, with the LCP image preloaded and prioritized, and with below-the-fold images natively lazy-loaded. Total image weight on a PDP comes in under 800 KB on mobile, often well under. Mobile LCP sits comfortably under 2.0 seconds on the median product. The site does not require a hero image overhaul to maintain these metrics; the delivery pipeline does the work automatically.
Reaching this state from a typical mid-market starting point is a four-to-twelve week engagement, with measurable LCP improvements visible in CrUX data within the first month after deployment. The improvement compounds with other CWV work, and it survives merchandising change because the optimization happens in the delivery layer rather than in manual asset preparation. That is what image optimization at scale actually delivers.
