WebP & AVIF Images in Magento 2: The Page-Speed Win

WebP and AVIF in Magento 2: build and measure an image pipeline

Magento 2 does not convert images to WebP or AVIF natively — it will display a WebP file you upload, but it will not convert an existing catalogue, generate modern formats on upload, or serve fallbacks to older browsers. The fix is an image pipeline with four parts: convert automatically on upload and in bulk, serve WebP or AVIF with a fallback, resize images to what the page actually displays, and lazy-load everything below the fold.

The prize is real because product imagery is usually the heaviest thing on a Magento page, and most catalogues still serve the original JPG or PNG uploads. WebP and AVIF can reduce transfer size for suitable images, but the result depends on the original, quality setting and codec. Delivery and LCP only change when the storefront actually serves the smaller file. Serving generated files may require theme or CDN integration. Check output quality and measure the actual page before promising a speed gain.

The formats at a glance

Format	Compression	Browser support	Role in the pipeline
JPG / PNG	Baseline — the sizes you have today	Universal	The fallback of last resort; keep the originals
WebP	Meaningfully smaller than JPG/PNG at equal quality	All modern browsers	The workhorse format for most visitors
AVIF	Often smaller again than WebP	Current major browsers; older versions need fallback	Best-case format, served when the browser accepts it

What "doing it right" involves

• Generate alternate files. Choose a controlled batch or background process for existing images. Whether new images are converted on upload or first use depends on the tool and configuration.
• Serve with fallback. Configure the theme or image service to select supported formats and keep an original fallback. Verify real browser responses and cache keys.
• Resize to what is displayed. A huge original in a small category-grid slot wastes most of its bytes before format even enters the discussion. Responsive sizing matters as much as conversion.
• Check lazy loading. Defer appropriate off-screen images, but inspect the actual LCP image rather than assuming the first few HTML images are above the fold.

What stock Magento can and cannot do

Before adding anything, get the native controls right — they help, they just do not finish the job:

1. Set upload limits. Under Stores → Configuration → Advanced → System → Images Upload Configuration you can set the quality and the maximum width and height applied to uploads, and enable frontend resizing. This stops oversized originals entering the catalogue in the first place.
2. Regenerate cached sizes. After changing image settings or your theme, run bin/magento catalog:images:resize so the resized variants Magento serves are rebuilt to the new rules. On a large catalogue, run it out of hours — regenerating every cached size is CPU-heavy work.
3. Check your theme's image definitions. The sizes Magento generates per placement (grid, thumbnail, gallery) come from the theme's view.xml, so a theme that requests sensible dimensions saves more bytes than any compression setting.
4. Measure the gap. Run a category page and a product page through PageSpeed Insights and look for the "Serve images in next-gen formats" and "Properly size images" audits — that is your before picture, in bytes.

What none of this does is change format: there is no native switch that turns your JPG catalogue into WebP or AVIF, no on-upload conversion, and no format-based fallback. That is the gap a module fills.

How Image Optimisation for Magento closes the gap

Our Image Optimisation for Magento 2 module generates WebP and supported AVIF siblings for catalogue images through a product-image hook, cron or CLI. It keeps the conversion source files; optional JPEG/PNG upload resizing changes the saved upload when enabled. Optional HTML lazy loading skips a configured number of initial images, but does not identify the visual hero. The buyer package returns the original Magento image URL and does not emit a picture element or swap GraphQL URLs. Connect its generated files to a tested Luma theme, headless frontend or image service to deliver them.

Where images sit in the wider speed picture

Image weight is one of the biggest levers on LCP, but it is one lever among several — theme JavaScript, third-party tags and server response time all take their share. If speed is the wider goal, start with why your Magento store is slow and the fixes that work, then use Magento Core Web Vitals to measure what Google actually scores you on. Image work can help, but conversion, delivery and cache integration each need checking; measure the actual storefront before and after.

FAQ

Does Magento 2 support WebP natively?

Magento can display a WebP file you upload, but it does not convert your catalogue to WebP or AVIF, does not generate modern formats on upload, and does not serve format-based fallbacks. Conversion and delivery need a module or an external image service.

Will converting to WebP break my existing product images?

The module's format generator writes alternate files and keeps its source images. Serving them with browser fallbacks requires separate storefront integration. Its optional upload resize does change the saved new JPEG/PNG file, so retain your source copy.

How much faster will my pages be?

There is no reliable fixed gain. Compare real page requests and LCP before and after your theme or image service serves the alternates; generation alone does not change bytes delivered to shoppers.

Should product images be lazy-loaded?

Below the fold, yes — it defers weight the visitor may never scroll to. The exception is the main above-the-fold image, which is usually the page's LCP element: lazy-loading it delays the very metric you are trying to fix, so it should load eagerly.

Image Optimisation is listed in the AgenticEcom Suite. Check the exact package's tested Magento/PHP pair and current commercial terms before installation.