MageSpeedTestMagento performance benchmarking
All guides

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.

Frontend8 min read

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.