Skip to content

Edge Image Pipeline

Background AVIF/WebP encoding with deduped jobs. Originals untouched, the fastest variant always served.

Images are the single largest contributor to page weight on most Magento stores. A product page with six images at 1 MB each is delivering 6 MB of data to a mobile visitor — even with "good" compression. Accelerate Guru's image pipeline transparently re-encodes every image to modern formats and serves the smallest variant the browser can accept, without touching a single file on the Magento server.


#Why AVIF is better than JPEG, WebP, and PNG

#The format evolution

FormatYearCompressionBrowser support (2026)Use case
JPEG19928:1 typical100%Photos (lossy)
PNG19962:1 typical100%Graphics, transparency
WebP201030% better than JPEG97%Photos + graphics
AVIF201950–90% better than JPEG95%Everything

#AVIF compression ratios

The same product image, visually identical (quality 65):

FormatFile sizevs. JPEG
JPEG (quality 80)210 KBbaseline
WebP (quality 80)145 KB−31%
AVIF (quality 65)44 KB−79%

A Magento store with a 1 MB hero image serves a 44 KB AVIF to browsers that support it. For a visitor on a 3G connection, that is the difference between 3 seconds and 0.1 seconds of image load time.

#Why AVIF beats WebP too

AVIF is based on the AV1 video codec, which uses significantly more sophisticated compression algorithms than WebP (VP8). AVIF can represent smooth gradients, fine textures, and photographic detail with far fewer bits. At the same visual quality, AVIF files are typically 30–50% smaller than WebP.

AVIF also supports features WebP does not:

  • HDR (High Dynamic Range) — wider colour gamut for future displays.
  • Film grain synthesis — stores grain as metadata rather than pixel data (huge file size win for photographic content).
  • Better alpha channel compression — product images with transparent backgrounds are significantly smaller.

#Browser support

In 2026, AVIF is supported by:

BrowserSupport
Chrome 85+Full
Firefox 93+Full
Edge 121+Full
Safari 16.4+ (macOS/iOS)Full
Samsung Internet 14+Full
Opera 71+Full

Approximately 95% of real-world visitors receive AVIF. The remaining 5% (older Safari, Internet Explorer) receive WebP (if supported) or the original JPEG/PNG — all transparently, with no configuration.


#How the image pipeline works

First request for /image.jpg:
  1. Edge serves the original JPEG immediately (no added latency).
  2. In the background, a worker encodes AVIF + WebP versions.
  3. Both variants are stored in the image cache directory.

All subsequent requests:
  1. Edge detects AVIF support in the Accept header.
  2. Serves the AVIF variant from the image cache.
  3. No encoding overhead. No origin contact.

The original images on the Magento server are never modified. The encoded variants are stored in image_cache_dir (default: ./cache/images) on the edge server.

#Accept header detection

The Accept header tells the edge which image formats the browser supports:

Accept: image/avif,image/webp,image/apng,image/*,*/*;q=0.8

Accelerate Guru parses this header on every image request and serves the best format the browser supports. The mapping is:

Accepts AVIF?Accepts WebP?Served format
YesAVIF
NoYesWebP
NoNoOriginal (JPEG/PNG)

#Compression: why zstd and brotli beat gzip

For non-image responses (HTML, CSS, JavaScript), Accelerate Guru uses a compression ladder: zstd → brotli → gzip, serving the best encoding the browser accepts.

#Compression algorithm comparison

AlgorithmYearTypical HTML ratioTypical JS ratioDecode speed
gzip19923.5:13.0:1Fast
brotli20154.0:1 (+14%)3.5:1 (+17%)Fast
zstd20164.3:1 (+23%)3.8:1 (+27%)Very fast

Why zstd is the best choice for edge serving:

  1. Better compression ratio than gzip — the same HTML response compressed with zstd is 20–30% smaller than with gzip. For a 200 KB Magento homepage, that is 40–60 KB less data transferred on every cache hit.

  2. Faster decompression than brotli — brotli achieves slightly better ratios but is slower to decompress. zstd decompresses at ~1 GB/s on a mobile CPU, making it genuinely faster end-to-end.

  3. Available on all modern browsers — Chrome, Firefox, Edge, and Safari all support Accept-Encoding: zstd as of 2024/2025.

  4. Transparent fallback — browsers that don't support zstd advertise Accept-Encoding: br, gzip instead. The edge serves the appropriate compressed variant with zero extra CPU.

#How Accelerate Guru serves all three

Responses are pre-compressed at cache-fill time (when the response is first fetched from Magento). All three variants are stored:

DragonflyDB:
  sa:page:/catalog/product/view/id/123:0:abc123:zstd  → 38 KB
  sa:page:/catalog/product/view/id/123:0:abc123:br    → 42 KB
  sa:page:/catalog/product/view/id/123:0:abc123:gzip  → 55 KB

On subsequent requests, the edge checks the Accept-Encoding header and returns the correct variant in microseconds — zero CPU spent on compression at request time.


#Configuration reference

All image settings are in [optimization_images]:

[optimization_images]
; Enable AVIF encoding (recommended: true)
image_avif                  = true

; AVIF quality: 1-100. 65 is the sweet spot.
; Higher = larger file, lower perceived quality difference.
avif_quality                = 65

; Encoder speed: 1 (best compression, slow) to 10 (fastest, larger).
; In background encoding, speed 1 is fine.
avif_speed                  = 1

; Skip images larger than this (bytes). Very large images take minutes to encode.
avif_max_size               = 10485760

; Where to store encoded images
image_cache_dir             = ./cache/images

; false = encode in background (recommended)
; true  = encode on first request (adds 200-2000ms latency on first hit)
avif_on_the_fly             = false

; Generate BlurHash low-res placeholder for lazy images
image_placeholders          = false

; Re-check cached images against origin every N seconds (0 = never)
image_revalidation_interval = 1800

; Force re-fetch if upstream Age header exceeds this (prevents stale content)
freshness_max_age           = 5

; Add width/height to <img> tags (prevents CLS)
inject_asset_dimensions     = true

; Detect LCP image, add fetchpriority=high and <link rel=preload>
preload_lcp_image           = true

; Disable lazy-loading on the first N images (above-fold)
optimize_above_fold         = true
above_fold_count            = 3

; Generate srcset and sizes for product images
responsive_images           = true

#LCP image optimisation

The Largest Contentful Paint (LCP) is the most important metric in Lighthouse for user-perceived performance. On Magento product pages, the LCP element is almost always the hero/main product image. Two settings directly address this:

#preload_lcp_image = true

Accelerate Guru detects the LCP candidate during the first response (usually the first large image in the document) and on subsequent requests injects:

<link rel="preload" as="image" href="/media/catalog/product/hero.avif" fetchpriority="high">

This causes the browser to start downloading the hero image immediately — before it has even parsed the <body> tag — reducing LCP by 300–800 ms on typical Magento stores.

#inject_asset_dimensions = true

Images without width and height attributes cause Cumulative Layout Shift (CLS) — the page "jumps" as images load and push content down. Accelerate Guru reads actual image dimensions from the encoded AVIF and injects correct width and height attributes on every <img> tag that lacks them. This eliminates CLS from images with a single config line.


#Responsive images (srcset)

When responsive_images = true, Accelerate Guru generates srcset and sizes attributes for product images:

<!-- Before -->
<img src="/media/catalog/product/shoe.jpg" alt="Running Shoe">

<!-- After -->
<img
  src="/media/catalog/product/shoe.avif"
  srcset="/media/catalog/product/shoe.avif?w=320 320w,
          /media/catalog/product/shoe.avif?w=640 640w,
          /media/catalog/product/shoe.avif?w=1280 1280w"
  sizes="(max-width: 640px) 320px, (max-width: 1280px) 640px, 1280px"
  width="1280"
  height="960"
  alt="Running Shoe">

A mobile visitor downloading this page on a 375 px screen receives a 320 px AVIF instead of the full 1280 px original. On a 4G connection with a 1 MB original, this is the difference between 25 KB and 1 MB of image data — a 40× reduction.


#BlurHash placeholders

When image_placeholders = true, Accelerate Guru generates a BlurHash — a compact mathematical representation of the image's colour and structure — and injects it as a CSS background-image on lazy-loaded <img> elements:

<img
  loading="lazy"
  src="/media/catalog/product/shoe.avif"
  style="background-image: url('data:image/svg+xml,...blurHash...');"
  ...>

The visitor sees a blurred version of the image immediately while the full image loads. This significantly improves Perceived Performance — visitors don't see blank white boxes.


#Cache management

Encoded images are stored permanently until the source image changes (detected via content hash) or until manually cleared. To clear the image cache:

# Clear all cached images
rm -rf /var/cache/accelerate-guru/images/

# Or selectively from the stats dashboard
# Settings → Cache → Clear image cache

After clearing, images are re-encoded on their first request (in the background — visitors see the original on first hit).