Magento image optimizer: brocode vs Yireo vs JaJuMa

Lead

The three best-known ways to ship WebP and AVIF on Magento 2 — the BroCode Image Optimizer, Yireo’s Webp2 (part of the Yireo NextGenImages family), and JaJuMa’s Ultimate Image Optimizer — are usually pitched as a feature checklist. That framing hides the only decision that matters: they sit at different layers of the stack. One serves modern formats at the web-server layer with zero markup changes; the other two rewrite your HTML to inject <picture> tags. Everything else — responsive variants, lazy-load, price — follows from that one architectural fork.

This Magento image optimizer comparison is not a "which module wins" article. Each is the right answer for a different shop. The point is to make the trade-off explicit and table-driven so you can pick on architecture, then verify against your own catalog.

One-sentence definition of each

• BroCode Image Optimizer — writes WebP/AVIF sidecar files next to each original (photo.jpg → photo.jpg.webp) and lets nginx/Apache serve them via HTTP Accept-header content negotiation. The storefront HTML never changes. MIT, free.
• Yireo Webp2 / NextGenImages — converts images and rewrites <img> tags into <picture> elements in Magento’s HTML output, so the browser picks the format client-side. WebP via Webp2; AVIF via the NextGenImages family. OSL-3.0, free.
• JaJuMa Ultimate Image Optimizer — a paid all-in-one that generates up to 9 variants per image (AVIF, WebP, responsive breakpoints, 2x/3x retina, LQIP placeholders) and injects a full <picture> element with lazy-load. Commercial, Adobe Marketplace.

Baseline

Out of the box, Magento 2 has no WebP or AVIF support — its image pipeline produces JPEG, PNG, and GIF, and serves exactly what you uploaded. All three modules start from that same baseline and bolt modern formats on top; the difference is where they bolt them on. Before comparing features, fix that baseline in your head: nothing here changes what Magento generates, only what the browser receives.

The architectural fork that actually decides it

Everything below the surface comes down to where format selection happens.

Server-layer (BroCode). The decision happens in nginx/Apache, keyed only on the request’s Accept header and whether a sidecar exists on disk. The PHP/Magento layer is never in the image request path on the hot path. Consequence: every image is upgraded — product, CMS, banners, third-party module output, even email templates — because nothing parses or rewrites HTML. Nothing in any .phtml, layout XML, or vendor template has to be touched or even audited. The cost: you must own the nginx/Apache rewrite rules (the module documents them but cannot install them), and there are no responsive/retina/lazy-load features — that is the web server’s job, not this module’s.

HTML-layer (Yireo, JaJuMa). The decision happens in Magento, which rewrites <img> into <picture> before the page is cached. Consequence: it only upgrades images that flow through the HTML these modules parse, and the markup itself changes (which is what enables responsive srcset, retina, and lazy-load). The cost: HTML rewriting has edge cases — JS-injected galleries (e.g. Fotorama reloading originals), email, and any output that bypasses the parser. On-the-fly generation also has a documented performance ceiling on large catalogs.

Neither layer is "better." Server-layer maximises coverage and simplicity; HTML-layer maximises per-image control (responsive/retina/lazy) at the cost of markup intrusion.

The core tradeoff

The whole Magento image optimizer comparison collapses to a single tradeoff: coverage and simplicity versus per-image control. BroCode buys total coverage and zero markup changes by giving up responsive/retina/lazy-load and asking you to own the web-server config. Yireo and JaJuMa buy responsive variants, retina, and lazy-load by rewriting your HTML — accepting narrower coverage and the edge cases that come with parsing markup. There is no option that gives you both without the cost; pick the side of the tradeoff that fits your hosting and your catalog.

The Magento image optimizer comparison table

> The Magento image optimizer comparison values below are compiled from each project’s README / docs / marketplace listing (June 2026) plus byte-savings measured on a real catalog in the AVIF vs WebP article. Verify against the current version before relying on any single row.

	BroCode Image Optimizer	Yireo Webp2 / NextGenImages	JaJuMa Ultimate Image Optimizer
Delivery mechanism	Server-layer content negotiation (sidecar + Accept header)	<img> → <picture> rewrite in HTML	<img> → <picture> rewrite in HTML
Template / markup changes	None	HTML output rewritten	HTML output rewritten
Covers 3rd-party & email images	Yes (invisible above web server)	Only parsed HTML	Only parsed HTML
WebP	Yes	Yes	Yes
AVIF	Yes (separate module)	Via NextGenImages family	Yes (first to market for M2)
Responsive srcset	No (web-server / theme concern)	No	Yes (configurable breakpoints)
Retina 2x/3x	No	No	Yes
Lazy loading	No	No	Yes (native + JS)
LQIP placeholders	No	No	Yes (5 styles)
Conversion	Cron + CLI; async via queue / RabbitMQ	On-the-fly + CLI	Cron + CLI (multi-thread)
Large-catalog story	Async queue/amqp modules	Docs warn against 1000s on-the-fly	Batch via cron/CLI
Server config required	Yes (nginx/Apache rewrites)	No	No
Hyvä support	N/A (no markup involvement)	Yes	Yes (OOTB v3.0+)
FPC interaction	None (below cache layer)	Picture markup cached in FPC	FPC-compatible by design
Extensibility	DI: new format / path / throughput = one module	Library-based converters	Configuration-driven
License / price	MIT, free	OSL-3.0, free	Commercial (paid; EE/ECE +€199)

Where each one wins

Choose BroCode when you want WebP and AVIF with the smallest possible surface area: no template audit, guaranteed coverage of third-party and email images, and an async rollout path (queue → RabbitMQ) for large catalogs — and you (or your ops team) are comfortable owning a few lines of nginx/Apache rewrite config. Free and MIT, so no per-edition licensing.

Choose Yireo when you want a free, open-source, automatic solution that needs no server-config access, integrates with Hyvä, and you are mainly after WebP (with AVIF available through NextGenImages). Best fit for shops that can’t touch the web-server layer and have catalogs small enough that on-the-fly conversion stays within the documented performance envelope.

Choose JaJuMa when you want a turnkey, fully-featured commercial package — responsive srcset, 2x/3x retina, lazy-load, and LQIP placeholders out of the box — and you are happy to pay for a supported, all-in-one extension rather than assemble those pieces yourself.

Where BroCode is the wrong choice

Honest disqualifiers — picking the wrong tool wastes a sprint:

• You can’t change the web-server config. Sidecar files are useless without the nginx/Apache rewrite rules. Conversion will run and browsers will still receive originals. On locked-down managed hosting where you can’t add a map/try_files or .htaccess rule, Yireo or JaJuMa’s HTML-layer approach is the pragmatic choice.
• You need responsive srcset, retina, or lazy-load from the module. BroCode deliberately serves one URL per image and leaves responsiveness to the theme and web server. JaJuMa builds these in.
• A CDN or image service already negotiates format upstream (Cloudinary, Imgix, Fastly IO). Then none of these modules earns its place — see the module page’s "Who should skip".

Working example: decide on your own catalog

Don’t pick from the table — the savings depend on your image mix, not the vendor’s marketing number. Format choice (WebP vs AVIF) drives the byte reduction far more than module choice does, so measure both on a representative slice of pub/media before committing to any module or quality setting. Generate sidecars directly with the standard encoders and sum bytes by extension:

# WebP + AVIF sidecars for a sample slice, then total bytes by extension.
find pub/media/catalog/product/cache -type f \( -iname "*.jpg" -o -iname "*.png" \) \
  | xargs -P4 -I{} sh -c 'cwebp -q 80 "$1" -o "${1}.webp"; avifenc -q 60 "$1" "${1}.avif"' _ {}

for ext in jpg png webp avif; do
  total=0
  while IFS= read -r f; do total=$((total + $(stat -c '%s' "$f" 2>/dev/null || stat -f '%z' "$f"))); done \
    < <(find pub/media/catalog/product/cache -type f -iname "*.${ext}")
  printf '%-5s %12d bytes\n' "$ext" "$total"
done

On a real ~213k-image catalog this came out to −74.6% for AVIF and −61.9% for WebP (byte-weighted), AVIF’s lead widest on large JPEG product shots and the two formats roughly equal on flat PNG graphics. The full per-class method is in the AVIF vs WebP article. Whichever module you choose, the real output of any Magento image optimizer comparison is the same byte reduction; the module only decides how it reaches the browser.

Verification

Whichever module you install, confirm the browser actually receives the modern format — a converted file with broken delivery (missing nginx rewrite, or a <picture> tag stripped by FPC) silently serves the original:

# Server-layer (BroCode): the negotiated response should return the sidecar's size.
curl -sI -H 'Accept: image/avif,image/webp,*/*' \
  https://your-store/media/catalog/product/x/y/photo.jpg \
  | grep -iE 'content-type|content-length'

# HTML-layer (Yireo / JaJuMa): the rendered page should contain a <picture> with modern sources.
curl -s https://your-store/some-product.html | grep -iE '<picture|type="image/(avif|webp)"'

For BroCode, a Content-Type: image/avif on the same URL proves negotiation works. For the HTML-layer modules, the presence of <source type="image/avif"> in the cached page proves the rewrite survived full-page cache.

FAQ

Is BroCode Image Optimizer really free?

Yes — MIT-licensed and open source, including the WebP and AVIF converter modules. There are no per-edition (CE/EE) license fees.

Does Yireo Webp2 support AVIF?

Webp2 itself is the WebP front-end. AVIF support lives in the broader Yireo NextGenImages family that Webp2 depends on. If AVIF is a hard requirement, confirm against the current NextGenImages version.

Why does BroCode need nginx/Apache config when the others don’t?

Because BroCode does format selection at the web-server layer instead of rewriting HTML. That is exactly what lets it upgrade every image (including third-party and email) with zero template changes — but the trade-off is that the web server must carry the Accept-based rewrite rules. Yireo and JaJuMa avoid server config by changing the HTML instead.

Which one is fastest on a large catalog?

For delivery, server-layer negotiation is a static file transfer with no PHP in the hot path. For conversion, avoid any on-the-fly approach at catalog scale; BroCode offers async queue and RabbitMQ modules, JaJuMa offers multi-threaded batch CLI, and Yireo’s docs explicitly warn against on-the-fly for thousands of images.

Do I have to choose only one?

Effectively yes for delivery — running two <picture>-rewriting modules, or a rewriter plus content negotiation, double-converts and fragments caches. Pick the layer that matches your hosting and feature needs.

Related reading

• BroCode Image Optimizer — the module compared here
• AVIF vs WebP for Magento: measure your own catalog — the byte-savings data
• No template changes: serving WebP and AVIF with nginx — the content-negotiation config
• Rolling out AVIF on a live store without breaking your CDN