WooCommerce Image Optimisation: The Complete Guide

The image weight problem in WooCommerce

Images are the dominant performance factor in any WooCommerce store. A typical product page with 5 gallery images, 4 related product thumbnails, and a category banner transfers 3–6MB of image data — often more than all HTML, CSS, and JavaScript combined. On category pages showing 24 products, each with a thumbnail image, the total image weight can reach 2–4MB even with compressed JPEGs.

The reason images matter more for WooCommerce than for a standard WordPress blog is volume. A blog post might have 2–3 images. A product page has 5–10. A category page has 20–48. A homepage with featured products, sale banners, and category grids can load 30+ images. This is the foundation of WooCommerce speed optimisation — you cannot have a fast store with unoptimised images, regardless of how well everything else is configured.

The good news is that image optimisation offers the highest return on effort of any WooCommerce performance fix. A 50% reduction in image weight (achievable with format conversion alone) translates directly to faster page loads, lower bandwidth costs, and better Core Web Vitals scores.

WooCommerce thumbnail size audit

Every image uploaded to WooCommerce triggers WordPress to generate multiple thumbnail sizes. The default WordPress installation creates 4 sizes (thumbnail, medium, medium_large, large). WooCommerce adds 3 more (shop catalogue, single product, gallery thumbnail). Your theme likely adds 2–4 additional sizes. Popular plugins (Jetpack, social sharing plugins) may add more. It’s common to find 15–21 registered image sizes, meaning each product image upload creates 15–21 additional files on your server.

Most of these thumbnails are never displayed. Check which sizes your theme actually uses:

// List all registered image sizes (run temporarily, then remove)
add_action('admin_init', function() {
    if (current_user_can('manage_options') && isset($_GET['vp_show_sizes'])) {
        global $_wp_additional_image_sizes;
        echo '<pre>';
        print_r(get_intermediate_image_sizes());
        print_r($_wp_additional_image_sizes);
        echo '</pre>';
        die();
    }
});

Once you’ve identified unused sizes, remove them:

add_filter('intermediate_image_sizes_advanced', function($sizes) {
    unset($sizes['medium_large']);  // 768px — rarely used in themes
    unset($sizes['1536x1536']);     // 2x medium_large
    unset($sizes['2048x2048']);     // 2x large
    // Remove theme sizes you've confirmed aren't used
    return $sizes;
});

For existing images that already have unnecessary thumbnails, use WP-CLI to regenerate only the sizes you need:

# Regenerate thumbnails for all images (only creates currently registered sizes)
wp media regenerate --yes

On a store with 500 products and 3 images each, removing 5 unnecessary thumbnail sizes eliminates 7,500 files from your server. This reduces storage usage, speeds up backups, and eliminates the processing time for generating those thumbnails on upload.

Modern image formats: WebP and AVIF

JPEG has been the default product image format for 25 years. WebP and AVIF are modern alternatives that deliver dramatically smaller file sizes at equivalent visual quality.

WebP offers 25–35% smaller files than JPEG. It’s supported by every modern browser (Chrome, Firefox, Safari 14+, Edge) — over 97% of users globally. WebP supports both lossy and lossless compression, transparency (unlike JPEG), and animation (unlike PNG). For WooCommerce stores, WebP should be the minimum standard format for all product images.

AVIF pushes compression even further — 40–50% smaller than JPEG at equivalent quality. However, browser support is lower (about 92% globally — Safari 16+ and Chrome 85+), and encoding is significantly slower. AVIF makes sense as a progressive enhancement served alongside WebP fallbacks, but it’s not yet suitable as your only format.

There are three approaches to serving modern formats in WooCommerce:

1. Server-side conversion on upload. Plugins like ShortPixel, Imagify, or Smush convert images to WebP when they’re uploaded. The original file is kept as fallback. The <picture> element or .htaccess rewrite rules serve WebP to supporting browsers:

# .htaccess WebP rewrite (Apache)
<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteCond %{HTTP_ACCEPT} image/webp
    RewriteCond %{REQUEST_FILENAME} (.+)\.(jpe?g|png)$
    RewriteCond %{REQUEST_FILENAME}.webp -f
    RewriteRule (.+)\.(jpe?g|png)$ $1.$2.webp [T=image/webp,E=REQUEST_image,L]
</IfModule>

2. CDN-based transformation. Services like Cloudflare Polish, BunnyCDN Optimizer, or Imgix convert images on the fly at the edge. No server-side processing needed — the CDN detects browser support and serves the optimal format automatically. This is the lowest-effort approach and handles responsive sizing too.

3. WordPress core WebP support. WordPress 5.8+ can generate WebP thumbnails natively if the server has libwebp installed. However, it doesn’t convert existing images or serve WebP to browsers automatically — you still need a plugin or server configuration for content negotiation.

Our recommendation: use CDN-based transformation if your budget allows (£5–20/month depending on traffic). It handles format conversion, responsive sizing, quality optimisation, and delivery in one step. For stores on tighter budgets, ShortPixel’s WordPress plugin at £4/month handles conversion well. Check our WordPress image optimisation guide for detailed comparisons.

Responsive images for WooCommerce

Responsive images ensure that mobile visitors download appropriately sized files instead of desktop-resolution images. A product image displayed at 375px wide on a mobile screen should not transfer a 1200×1200 source file — that wastes 70%+ of the downloaded data.

WordPress generates srcset and sizes attributes automatically, but WooCommerce themes often override these with incorrect values. The sizes attribute tells the browser how wide the image will be rendered at different viewport widths, so it can choose the right source from srcset.

Verify your product images have correct responsive markup:

// Customise WooCommerce product image sizes for responsive delivery
add_filter('woocommerce_get_image_size_single', function() {
    return array(
        'width'  => 800,  // Max display width
        'height' => 800,
        'crop'   => 0,
    );
});

add_filter('woocommerce_get_image_size_gallery_thumbnail', function() {
    return array(
        'width'  => 150,
        'height' => 150,
        'crop'   => 1,
    );
});

add_filter('woocommerce_get_image_size_thumbnail', function() {
    return array(
        'width'  => 400,  // Category/shop page thumbnails
        'height' => 400,
        'crop'   => 1,
    );
});

The critical mistake is setting single product image width to 1200 or higher. Unless your theme displays product images at that width (most don’t — the product image column is typically 50–60% of the page width), you’re forcing browsers to download larger files than needed. Check the actual rendered width of product images in your theme using Chrome DevTools and set the image size accordingly.

Lazy loading strategy for WooCommerce

Lazy loading defers image downloads until the image is about to enter the viewport. This dramatically reduces initial page weight and speeds up above-the-fold rendering. WordPress 5.5+ adds native lazy loading (loading="lazy") to all images automatically.

The critical exception: never lazy-load the main product image. On single product pages, the main product image is almost always the LCP (Largest Contentful Paint) element. Lazy loading it delays its render by 200–500ms because the browser won’t start downloading until JavaScript confirms the image is near the viewport. Instead, give the main product image high priority:

add_filter('wp_get_attachment_image_attributes', function($attr, $attachment, $size) {
    if (is_product()) {
        global $product;
        if ($product && $attachment->ID === $product->get_image_id()) {
            unset($attr['loading']);
            $attr['fetchpriority'] = 'high';
            $attr['decoding'] = 'async';
        }
    }
    return $attr;
}, 10, 3);

On category pages, the first row of product thumbnails (typically 3–4 products) should also not be lazy loaded — they’re above the fold and visible on initial load. Lazy-load everything from the second row onwards.

For product gallery images (the thumbnails below the main product image), lazy loading is safe and beneficial. These images are typically below the fold or hidden behind a slider, so delaying their download has no visual impact but saves significant bandwidth. The impact on LCP performance is substantial — loading only the primary image eagerly while deferring 4–5 gallery images can reduce initial page weight by 500KB–2MB.

CDN configuration for WooCommerce images

A Content Delivery Network serves images from edge servers geographically close to the visitor, reducing latency from 200–500ms to 20–50ms per image request. For image-heavy WooCommerce stores, a CDN is not optional — it’s essential.

The performance gain from a CDN is most dramatic for international stores. A UK-hosted store serving Australian customers adds 300–400ms of latency per image request without a CDN. With 20 images on a category page, that’s seconds of accumulated latency.

CDN configuration for WooCommerce needs to handle two concerns: caching product images aggressively, and invalidating cache when products are updated.

# Nginx: Set long cache headers for product images
location ~* /wp-content/uploads/.*\.(jpg|jpeg|png|gif|webp|avif|svg)$ {
    expires 365d;
    add_header Cache-Control "public, immutable";
    add_header Vary Accept;  # For WebP content negotiation
}

When a product image is replaced (not just added but replaced — same filename, different content), you need to invalidate the CDN cache for that URL. Most CDN providers offer API-based purging that can be triggered from WordPress:

// Purge CDN when a product image is updated
add_action('edit_attachment', function($attachment_id) {
    $url = wp_get_attachment_url($attachment_id);
    // Call your CDN's purge API for this URL
    vp_purge_cdn_url($url);
});

For WooCommerce stores using Cloudflare, enable Polish (automatic image optimisation) and Mirage (responsive image loading). These two features handle format conversion, quality optimisation, and responsive delivery automatically. The combination of Cloudflare’s free CDN tier plus Polish (Pro plan, £16/month) is the most cost-effective image delivery solution for most WooCommerce stores.

Bulk image optimisation for existing stores

New stores can implement image optimisation from day one, but existing stores with thousands of unoptimised product images need a bulk conversion strategy.

The process involves three steps: audit existing images to quantify the problem, bulk convert to modern formats, and set up automated optimisation for future uploads.

Start by assessing the current situation:

# Count total images and estimate savings (via WP-CLI)
wp db query "SELECT COUNT(*) as total_images,
    ROUND(SUM(meta_value)/1024/1024, 2) as total_mb
FROM wp_postmeta
WHERE meta_key = '_wp_attached_file'
AND meta_value LIKE '%.jpg'
OR meta_value LIKE '%.png'"

For bulk conversion, use a plugin with a bulk optimiser (ShortPixel, Imagify, or Smush Pro). These process images in batches to avoid overloading the server. ShortPixel and Imagify process images on their own servers, so your hosting resources aren’t consumed during optimisation.

Critical considerations for bulk optimisation:

• Run the bulk process during low-traffic hours — image processing is CPU-intensive
• Keep original files as backup until you’ve verified the conversions
• Process 50–100 images per batch with 5-second delays between batches to avoid hitting server resource limits
• After conversion, regenerate thumbnails to create WebP versions of all sizes
• Clear your CDN cache after bulk conversion so visitors get the new formats

For stores with 10,000+ images, consider using a CDN-based approach instead of server-side conversion. Cloudflare Polish or BunnyCDN Optimizer converts images on the fly when they’re first requested — no bulk processing needed, no server load, and the conversion happens transparently over time as pages are visited. This works well with the Core Web Vitals optimisation approach of measuring real user experience rather than synthetic test scores.

Image upload workflow for store managers

Even with automated optimisation, the images uploaded to WooCommerce need to be properly prepared. Store managers uploading 5MB product photos straight from a DSLR camera create unnecessary processing load and risk timeout errors during upload.

Establish an upload workflow:

• Maximum upload dimensions: 1200×1200 for product images, 800×800 for category thumbnails. No product image needs to be larger than this for web display
• File format: JPEG at 80–85% quality for product photos. PNG only for images requiring transparency (logos, icons). Never upload BMP or TIFF files
• File naming: Descriptive filenames improve SEO. Use blue-cotton-tshirt-front.jpg instead of IMG_4592.jpg
• Pre-upload compression: Run images through TinyPNG or Squoosh before uploading. This reduces the load on server-side optimisation plugins

Set WordPress upload limits to prevent oversized files:

// Limit maximum upload image dimensions
add_filter('wp_handle_upload', function($file) {
    $image = getimagesize($file['file']);
    if ($image) {
        $max_width = 2400;
        $max_height = 2400;
        if ($image[0] > $max_width || $image[1] > $max_height) {
            $file['error'] = sprintf(
                'Image dimensions (%dx%d) exceed the maximum allowed (%dx%d). Please resize before uploading.',
                $image[0], $image[1], $max_width, $max_height
            );
        }
    }
    return $file;
});