Image Optimization for SEO: Format, Compression, Delivery

1. Why image optimization determines SEO visibility and performance

Images are the single largest contributor to page weight in most Magento catalogs, often 60 to 70 percent of the data transferred on a category or product page. Since the Largest Contentful Paint element is almost always a hero banner or product photo, image optimization caps the achievable performance ceiling before any JavaScript optimization even matters. This article deliberately goes beyond a general Core Web Vitals overview and focuses on image-specific levers: format choice, compression, delivery, and the textual SEO signals that a generic performance audit usually skips.

Google Images is also an independent, often underestimated traffic channel, especially for visually driven categories like fashion, furniture, or home decor. Yet most stores treat product images purely as decoration and never optimize them for image search ranking factors: file name, alt text, surrounding context, structured data, and sitemap inclusion. Getting both dimensions right at the same time requires a coordinated pipeline rather than one-off manual edits per product image.

2. Image formats compared: WebP, AVIF vs. JPEG, PNG

JPEG remains the most widespread lossy standard for photos, but WebP typically achieves 25 to 35 percent smaller files at comparable visual quality, because it uses more modern prediction and entropy coding. WebP also supports lossless compression and an alpha channel for transparency, which lets it replace PNG in almost every use case without any quality loss for icons or product images with a transparent background.

AVIF goes even further and often saves another 20 to 50 percent over WebP at comparable perceived quality, because the underlying AV1 codec compresses significantly more efficiently. The downside: encoding is more compute-intensive and noticeably slower in build pipelines, and older Safari and Edge versions don't fully support AVIF. In practice, a format cascade via the <picture> element serves AVIF to modern browsers, WebP as a second tier, and JPEG as a universal fallback.

3. Compression: quality levels, lossy vs. lossless

Compression quality is the lever with the biggest impact on file size, yet it's often set incorrectly in practice. Many stores ship product images at quality 95 or 100, even though the visual difference to quality 75 through 82 is imperceptible to most users. For detailed product photography, quality 80 is typically enough; for icons and illustrations with few colors, lossless compression pays off, since lossy encoding produces visible artifacts around sharp edges there.

Tools like Squoosh, Sharp, or ImageMagick enable automated, reproducible compression as part of the build or deploy pipeline, instead of manually exporting images from an image editor. It's important to never re-compress an already lossy-compressed image, since compression artifacts accumulate with every pass. Target sizes should be defined per image type, for example a maximum of 150 KB for a hero image and 60 KB for a product listing thumbnail, and checked automatically as part of the CI process.

4. Responsive images: srcset, sizes, and art direction

Shipping a single, maximum-resolution image to every device wastes significant bandwidth on mobile viewports. The <img> attribute srcset with width descriptors gives the browser several resolution variants to choose from, while sizes tells the browser how wide the image will actually render in the current layout. The browser then picks the right file on its own, based on viewport width and pixel density, with no JavaScript involved.

For art direction, meaning different crops per viewport rather than just different resolutions, srcset alone isn't enough. The <picture> element with multiple <source> elements and media queries lets you show a tighter crop on mobile than on desktop, for example on text-heavy hero banners. In Hyvä themes, this logic can be cleanly encapsulated in a view model that generates the right breakpoint variants per image type from the Magento media gallery resizer, instead of duplicating markup across templates.

<!-- Hyvä phtml: responsive product image with a modern-format fallback chain -->
<picture>
    <source type="image/avif"
            srcset="{{$block->getImageUrl('avif', 400)}} 400w,
                    {{$block->getImageUrl('avif', 800)}} 800w,
                    {{$block->getImageUrl('avif', 1200)}} 1200w"
            sizes="(min-width: 1024px) 33vw, 100vw">
    <source type="image/webp"
            srcset="{{$block->getImageUrl('webp', 400)}} 400w,
                    {{$block->getImageUrl('webp', 800)}} 800w,
                    {{$block->getImageUrl('webp', 1200)}} 1200w"
            sizes="(min-width: 1024px) 33vw, 100vw">
    <img
        src="{{$block->getImageUrl('jpg', 800)}}"
        srcset="{{$block->getImageUrl('jpg', 400)}} 400w,
                {{$block->getImageUrl('jpg', 800)}} 800w,
                {{$block->getImageUrl('jpg', 1200)}} 1200w"
        sizes="(min-width: 1024px) 33vw, 100vw"
        width="800"
        height="800"
        loading="lazy"
        decoding="async"
        alt="{{$block->escapeHtmlAttr($block->getImageAlt())}}"
        class="w-full h-auto object-cover rounded-lg"
    >
</picture>

5. Using lazy loading correctly below the fold

Native loading="lazy" delays loading an image until it approaches the visible viewport, noticeably reducing initial data volume and server load, especially on category pages with many product images. The rule is simple, but frequently violated in practice: anything above the fold, especially the LCP element, must never be lazy-loaded, because that directly worsens the exact metric lazy loading is meant to protect.

A common mistake in product carousels: the first visible image gets lazy-loaded because the carousel markup applies a blanket loading attribute to every contained image. The fix requires a deliberate distinction between the first one or two visible slides and the rest. For background images set via CSS background-image instead of <img>, native lazy loading doesn't apply at all; an IntersectionObserver is needed there to set the image URL only once the element reaches the viewport.

// Lazy-load CSS background images once they approach the viewport
const bgObserver = new IntersectionObserver((entries, observer) => {
  entries.forEach((entry) => {
    if (!entry.isIntersecting) return;
    const el = entry.target;
    el.style.backgroundImage = `url(${el.dataset.bg})`;
    el.classList.remove('bg-placeholder');
    observer.unobserve(el);
  });
}, { rootMargin: '200px 0px' });

document.querySelectorAll('[data-bg]').forEach((el) => bgObserver.observe(el));

// Never lazy-load the first one or two above-the-fold carousel slides
document.querySelectorAll('.carousel-slide').forEach((slide, index) => {
  const img = slide.querySelector('img');
  if (index < 2) {
    img.loading = 'eager';
    img.fetchPriority = index === 0 ? 'high' : 'auto';
  }
});

6. CDN and delivery strategies for images

An image CDN such as Cloudflare Images, Fastly Image Optimizer, or imgix handles format negotiation, resizing, and compression directly at the edge, based on the requesting browser's Accept header. That means the origin server, meaning Magento itself, no longer has to keep hundreds of static image variants around for every combination of resolution and format; it just serves a source image that the CDN turns into the right variant on demand and caches.

For Magento stores, this also reduces load on pub/media and simplifies deployments, since setup:static-content:deploy no longer has to generate separate files for every image size. When configuring a CDN, long cache headers (Cache-Control: public, max-age of a year or more) combined with versioned or hashed file names matter, so a freshly uploaded product image never collides with a stale edge cache. Without a CDN, at least a dedicated media storage with its own aggressively cached vhost, separate from the application server, is recommended.

7. Alt text and file naming for image SEO

The alt attribute value is both an accessibility signal for screen readers and one of the few textual ranking signals Google has directly available for an image, since image content itself is only interpreted approximately. A good alt text precisely describes what's visible in the image, for example "Red leather sneakers, Aurora model, side view" instead of a generic "Product image" or a keyword-stuffed "Sneakers red leather buy cheap deal".

Purely decorative images, such as dividers or background graphics with no informational value, should get an empty alt="" so screen readers correctly skip them, instead of tagging them with a misleading alt text. File naming also contributes to image SEO: red-leather-sneakers-aurora.webp gives Google more context than IMG_20260304_0091.webp. In Magento, alt text can be maintained per product image in the media gallery and should be consistently populated via import script or required-field validation, rather than left blank.

{
  "@context": "https://schema.org",
  "@type": "ImageObject",
  "contentUrl": "https://mironsoft.de/media/catalog/product/red-leather-sneakers-aurora.webp",
  "name": "Red leather sneakers, Aurora model, side view",
  "description": "Product photo of the Aurora sneaker model in red leather, side view on a white background.",
  "width": 1200,
  "height": 1200,
  "license": "https://mironsoft.de/image-license",
  "acquireLicensePage": "https://mironsoft.de/image-license",
  "creditText": "Mironsoft",
  "creator": { "@type": "Organization", "name": "Mironsoft" }
}

8. Image sitemaps and visibility in Google Images

Magento's standard XML sitemap lists only page URLs, not image URLs. The image sitemap extension adds <image:image> tags per <url> entry with the image URL and optionally a title and caption, which points Google directly at images that would otherwise only be discovered during regular page crawling. For categories with many product images, this noticeably speeds up indexing in Google Images.

Magento doesn't ship image sitemap support out of the box; it requires extending the sitemap module or using a dedicated third-party module. Structured ImageObject schema on product pages helps as well, making license information, caption, and creator machine-readable. Google Search Console's index coverage report shows how many image URLs were actually indexed, and reliably surfaces cases where images stay invisible due to robots.txt rules or missing sitemap entries.

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
        xmlns:image="http://www.google.com/schemas/sitemap-image/1.1">
  <url>
    <loc>https://mironsoft.de/red-leather-sneakers-aurora.html</loc>
    <image:image>
      <image:loc>https://mironsoft.de/media/catalog/product/red-leather-sneakers-aurora.webp</image:loc>
      <image:title>Red leather sneakers, Aurora model</image:title>
      <image:caption>Side view of the Aurora sneaker model in red</image:caption>
    </image:image>
    <image:image>
      <image:loc>https://mironsoft.de/media/catalog/product/red-leather-sneakers-aurora-detail.webp</image:loc>
      <image:title>Red leather sneakers, Aurora model, detail view</image:title>
    </image:image>
  </url>
</urlset>

9. Magento media gallery: pipeline, bulk optimization, and cleanup

Magento's built-in image resizer automatically generates the theme-defined image sizes from the original in pub/media/catalog/product, either during product import or via bin/magento catalog:images:resize. Since Magento 2.4.6, the resizer natively supports WebP as an output format, but it has to be explicitly enabled in the catalog settings; otherwise all generated variants still fall back to JPEG, even if the browser requests WebP.

A commonly overlooked issue: pub/media/catalog/product/cache grows uncontrollably over the years, because old image variants aren't automatically cleaned up after theme changes or product edits. bin/magento catalog:images:resize --regenerate together with a regular cache-cleanup cron job keeps media storage lean. For AVIF support, which Magento core still doesn't cover natively, modules like Magefan Image Optimizer or a custom pub/sub pipeline with Sharp offer a practical addition that hooks into the regular import workflow.

#!/usr/bin/env bash
# Bulk-convert Magento media gallery images to WebP and AVIF
set -euo pipefail

SOURCE_DIR="pub/media/catalog/product"
CACHE_DIR="pub/media/catalog/product/cache"

# Regenerate configured image sizes from the originals first
bin/magento catalog:images:resize

# Convert every generated JPEG/PNG variant to WebP (quality 80) and AVIF
find "$CACHE_DIR" -type f \( -iname "*.jpg" -o -iname "*.png" \) | while read -r file; do
  cwebp -q 80 "$file" -o "${file%.*}.webp"
  avifenc --min 20 --max 35 "$file" "${file%.*}.avif"
done

echo "Conversion done. Remember to purge stale CDN cache entries."

The table below compares the most common image formats side by side, as a decision aid for the format strategy in your store.

In practice, format choice, compression, and delivery all work together: a perfectly compressed AVIF image doesn't help much if it's delivered at full resolution to mobile devices without srcset, and a clean responsive setup doesn't help much if the origin server never generates modern formats in the first place. Implementing the table as a format cascade inside the <picture> element and automating the pipeline covers the majority of the available optimization potential.

10. Summary

Image optimization for SEO isn't a single switch, it's a chain of decisions: the right format (AVIF and WebP with a JPEG fallback), the right compression quality per image type, responsive delivery via srcset and sizes, targeted lazy loading below the fold, and a CDN strategy that automates format negotiation and caching. Each individual measure only saves a few percent, but combined they typically add up to 60 to 80 percent less image data volume compared to an unoptimized default Magento setup.

Just as important as technical delivery are the textual image SEO signals: precise alt text, descriptive file names, structured ImageObject data, and a complete image sitemap. Only the combination of fast delivery and strong discoverability in Google Images turns product images into a real growth lever instead of just a performance drag.

11. FAQ: Image Optimization for SEO