To serve WebP and AVIF on a Hyva Magento storefront, generate both formats ahead of time, deliver them through a picture element that lists AVIF first, then WebP, then a JPEG fallback, and size each image responsively. Magento core does not produce these formats, so the conversion comes from Hyva’s media optimization, a dedicated extension, or an image CDN.
Images are the heaviest thing most storefronts ship. On a typical product or category page they dwarf the HTML, CSS, and JavaScript combined, and they usually contain the largest element the browser has to paint. That makes image format the highest-return performance change you have available, and it is often the one left on the default setting. Moving from JPEG and PNG to WebP and AVIF cuts image weight substantially with no visible quality loss, which shows up directly in Largest Contentful Paint, a ranking-relevant Core Web Vital. This guide covers format choice, correct fallbacks, responsive delivery, and how to do the conversion on Hyva without melting your servers.
The formats, and what they actually save
Three formats matter for a 2026 storefront, plus the legacy pair you are replacing.
| Format | Size vs JPEG | Browser support (2026) | Use it for |
|---|---|---|---|
| JPEG / PNG | baseline | Universal | Final fallback only |
| WebP | ~25 to 34% smaller | ~96% of users | The practical default |
| AVIF | ~50% smaller, ~20 to 30% below WebP | ~95% of users | The upgrade layer where you control delivery |
The pattern that follows from those numbers: WebP is the default because it is cheap to produce and nearly universal, and AVIF is the layer you add on top when you want the last slice of file size and can afford the extra conversion cost. Neither replaces the other. They work as a pair behind a fallback chain. Browser support for both now clears roughly 95% of users worldwide, with the gap being mostly older devices that the fallback quietly handles.
The one real cost of AVIF is encoding. It is far more CPU-intensive to generate than WebP or JPEG, which is exactly why you never convert it on the fly during a page request. More on that below.
Serving them correctly: the picture element
The safe, standards-based way to serve modern formats is the HTML picture element with ordered source tags. The browser reads top to bottom and takes the first format it supports.
<picture>
<source type="image/avif" srcset="/media/catalog/product/hero.avif">
<source type="image/webp" srcset="/media/catalog/product/hero.webp">
<img src="/media/catalog/product/hero.jpg" alt="Descriptive alt text" width="800" height="800">
</picture>
AVIF-capable browsers take the first source. Everyone else falls back to WebP, and the oldest clients get the JPEG in the img tag. This is why “does AVIF have full browser support” is the wrong question. The fallback means you never need 100% support to ship AVIF safely.
Two attributes on that img tag are not optional. The width and height reserve layout space so the page does not shift as the image loads, which protects your Cumulative Layout Shift score. And the alt text carries the accessibility and SEO weight. Skip either and you trade an image win for a different Core Web Vital loss.
Responsive images: stop shipping desktop pixels to phones
Format is half the win. The other half is not sending a 1600-pixel hero to a 390-pixel phone. Responsive delivery uses srcset and sizes so the browser picks an appropriately scaled file.
<img
src="/media/catalog/product/hero-800.jpg"
srcset="/media/catalog/product/hero-400.avif 400w,
/media/catalog/product/hero-800.avif 800w,
/media/catalog/product/hero-1600.avif 1600w"
sizes="(max-width: 768px) 100vw, 800px"
width="800" height="800" alt="Descriptive alt text">
A phone downloads the 400-wide file, a desktop the 1600-wide one, and nobody pays for pixels they cannot see. Combined with AVIF, a mobile shopper can receive an image a fraction of the weight of the old one-size JPEG. For catalog and hero imagery this is often the single biggest mobile speed gain available.
LCP: treat the hero image as a special case
Most images on a page should lazy-load. The Largest Contentful Paint image almost never should. Getting this backwards is one of the most common Hyva performance mistakes.
The rules for the above-the-fold hero or main product image:
- Do not lazy-load it. Native
loading="lazy"is correct for below-the-fold images and wrong for the LCP element, because it delays the very paint you are being measured on. - Give it high priority. Add
fetchpriority="high"so the browser fetches it before lower-value resources. - Preload it in the document head when it is predictable, so the request starts before the browser has parsed the markup that references it.
- Serve it as AVIF or WebP at the right responsive size, because a lighter LCP image is a faster LCP.
Switching the LCP image to AVIF alone commonly shaves a few hundred milliseconds off LCP. Layer preload and correct priority on top and the improvement compounds. Everything below the fold, meanwhile, gets loading="lazy" so it never competes with the hero for bandwidth. Bemeir treats this LCP discipline as core to every Hyva development engagement, because format and loading strategy have to be designed together to move the metric.
Why Magento core will not do this, and what will
Magento’s built-in image processing resizes and can compress JPEG and PNG, but it does not generate WebP or AVIF. So the conversion has to come from somewhere else. There are three routes, and stores often combine them.
1. Hyva’s media optimization. Hyva ships a media optimization feature that converts images to WebP and AVIF, with configurable engine, output formats, replacement modes, and quality. An observer can automatically replace images in the HTML and CSS with optimized versions, a developer API lets you process images directly in templates, and a CLI command manages the generated set. This is the natural fit for a Hyva store because it is built for the theme rather than retrofitted.
2. A dedicated extension. Tools such as the JaJuMa Ultimate Image Optimizer or comparable page-speed extensions add WebP and AVIF, lazy loading, and responsive variants, and several now advertise Hyva compatibility. These suit teams that want a configurable admin-managed solution without custom development.
3. An image CDN. A CDN with image optimization, such as Fastly’s image optimizer available on Adobe Commerce cloud, or a comparable service, converts and resizes at the edge and negotiates the best format per request through content negotiation. This offloads the work entirely from your origin, at a recurring cost. Our Magento and Adobe Commerce team picks among these based on your hosting, traffic, and how much of the catalog changes, because the right answer for a 2,000-SKU boutique is not the right answer for a 200,000-SKU catalog.
Do the conversion ahead of time, never on the request
This is the operational rule that keeps image optimization from becoming a performance problem of its own.
AVIF encoding is heavy. If you convert an image the first time it is requested, that request waits for the encode, and a burst of cold traffic can pin your CPU and slow the whole store. The correct pattern:
- Pre-generate WebP and AVIF variants through a cron job or CLI command, not synchronously during page rendering.
- Cache the output and serve it with long
Cache-Controllifetimes so the encode happens once per image, not once per visitor. - Regenerate on change, tying variant generation to product image updates so new photography is optimized before it goes live, not on the first shopper to hit it.
Handled this way, the CPU cost of AVIF is paid once, in the background, and every shopper receives a pre-built, cached, lightweight file.
A delivery checklist
Before you call image optimization done, verify each of these on a real page:
- The LCP image is AVIF or WebP, correctly sized, preloaded,
fetchpriority="high", and not lazy-loaded. - Below-the-fold images use
loading="lazy". - Every image ships through a
pictureelement orsrcsetwith an AVIF and WebP source and a JPEG fallback. - Every
imghas explicitwidthandheightand meaningfulalttext. - Variants are pre-generated and cached, not converted on request.
- You measured LCP in the field, not just in a lab test, before and after.
Where this sits in the bigger performance picture
Image format is the highest-return single change, but it is one lever among several. A Hyva migration exists precisely to strip the frontend weight that Luma carries, and images are where that weight is most visible on a product page. Whether you run Magento, or are comparing platforms like Shopify, Shopware, or BigCommerce, the physics are identical: lighter images in modern formats paint faster and rank better. What differs is how much control the platform gives you over the delivery, and Hyva gives you a lot. Start with the Bemeir approach to fast storefronts if performance is the reason you are here.
FAQ
Does Magento support WebP and AVIF natively?
No. Magento’s native image processing resizes and compresses JPEG and PNG but does not generate WebP or AVIF. The conversion comes from Hyva’s media optimization feature, a dedicated image optimization extension, or an image CDN that converts at the edge.
Should I use WebP or AVIF for my product images?
Both, behind a fallback. WebP is the practical default because it is cheap to produce and supported by roughly 96% of browsers. AVIF is around 20 to 30% smaller again and worth layering on top for hero and product imagery where you control delivery. A picture element serves AVIF first, then WebP, then a JPEG fallback, so every browser gets the best format it supports.
Will switching to AVIF slow down my server?
Only if you convert on the fly. AVIF encoding is CPU-intensive, so you pre-generate WebP and AVIF variants through a cron job or CLI command, cache them with long lifetimes, and regenerate when product images change. Done this way the encoding cost is paid once in the background and shoppers always receive a cached, lightweight file.
How much faster will modern image formats make my Hyva store?
Image weight is usually the largest share of page weight, and the image is often the Largest Contentful Paint element. Serving the LCP image as AVIF at the correct responsive size commonly cuts a few hundred milliseconds off LCP, and correct lazy loading below the fold frees bandwidth for the hero. The exact gain depends on your current images, so measure LCP in the field before and after.
Do I still need JPEG fallbacks in 2026?
Yes, though they rarely fire. WebP and AVIF each cover roughly 95% or more of users, but the picture element needs a final JPEG in the img tag so the small share of older clients still see an image. The fallback costs nothing to include and removes any risk from serving modern formats.
Getting image optimization built into your storefront
Modern image formats are the closest thing to a free performance win a storefront has, and most stores are only halfway there: converting to WebP but skipping AVIF, or converting formats but still shipping desktop pixels to phones, or lazy-loading the one image that should never be lazy. Bemeir builds the full delivery path, format, responsive sizing, LCP priority, and pre-generated caching, into Magento and Hyva stores. See how we work as an extension of your team, or review the technology partners and tools we use to make storefronts fast.
