Frontend · Images
Image Optimisation in Magento
Product imagery is the single largest contributor to page weight in most Magento stores. Magento's built-in image processing leaves substantial savings on the table.
Product imagery is the single largest contributor to page weight on most Magento stores. A typical category page renders 12–24 product thumbnails plus a hero image; a product detail page renders 4–8 high-resolution variants of the same product. Serving those images badly is the difference between a fast and a slow Magento storefront, regardless of how much you've tuned the server side.
What Magento does automatically
Magento 2 generates resized image variants on first request and caches them under pub/media/catalog/product/cache/. Default behavior produces JPEG and PNG variants at the dimensions the active theme requests, with lossy JPEG quality controlled by Stores → Configuration → Catalog → Catalog → Storefront → Quality (default: 80, reasonable).
What Magento does NOT do automatically: WebP or AVIF conversion, modern responsive-image markup with srcset, native lazy-loading. All three are responsibilities of the theme or a module.
WebP conversion
WebP variants are typically 25–35% smaller than equivalently-quality JPEGs and 50%+ smaller than PNGs. The two common ways to add WebP support in Magento:
- Hyvä themes — ship with native WebP support and srcset markup. If you're already using Hyvä, you've already got WebP. If you're not, this is one of the strongest performance arguments for migrating.
- Third-party module on Luma — modules like Yireo's WebP module or Yotpo's image optimisation extension generate WebP variants alongside the JPEG/PNG variants Magento creates and emit
<picture>elements with WebP sources and JPEG fallbacks. Effective on Luma stores where a Hyvä migration isn't planned.
Native lazy-loading
Modern browsers support loading="lazy" as a native HTML attribute. Adding it to product images below the fold defers their network requests until the user scrolls — typically saving 1–3 MB of unused image data on the initial page load.
Magento 2.4.5+ adds native lazy-loading to most image renderings automatically. Older versions need a theme override or module. Hero / above-the-fold images should explicitly opt out with loading="eager" to avoid LCP-degrading deferral.
Responsive sizing with srcset
Default Magento renders one image size per element, regardless of viewport. A 600px-wide product thumbnail being served as 1200px (because that's what the theme asked for) wastes 75% of the bytes on most viewports. Modern themes use srcset to declare multiple sizes and let the browser pick the right one:
<img src="/media/catalog/product/cache/600x/image.webp"
srcset="/media/catalog/product/cache/300x/image.webp 300w,
/media/catalog/product/cache/600x/image.webp 600w,
/media/catalog/product/cache/1200x/image.webp 1200w"
sizes="(max-width: 768px) 50vw, 25vw"
alt="..."
loading="lazy">The Magento image:resize command pre-generates the size variants used in srcset markup, so the first hit on a new size doesn't have to wait for runtime resizing.
Practical impact
On a typical Luma-themed Magento 2 store with default image handling, page weight from imagery is in the 3–6 MB range. With WebP + lazy-loading + responsive sizing in place, the same page renders at 600 KB – 1.5 MB. The Largest Contentful Paint metric improves by 1–3 seconds on slower connections — the difference between a Core Web Vitals 'good' rating and a 'needs improvement' rating for a substantial fraction of stores.