WooCommerce CRO Technique

How to optimise WooCommerce product pages with WebP and smart lazy-loading

This technique reduces image byte weight on WooCommerce product and category templates by converting and compressing images into WebP as the default baseline, serving right-sized variants, and lazy-loading only below-the-fold media. It helps most when images dominate page weight and mobile field LCP is slow, especially on image-heavy product galleries and category grids.

Summary

Bottom Line: Compress WooCommerce images to WebP as a safe baseline, serve the right size for the template, and lazy-load only images below the fold. Never lazy-load the hero or actual LCP image on a product or category page; if that image is discovered late, give it fetchpriority="high" or p

  • WebP usually cuts image size materially without changing the page design; Google reports lossy WebP is about 25–34% smaller than comparable JPEG at equivalent SSIM quality, while vendor claims of 40–60% savings should be treated as directional and image-dependent.
  • WordPress has supported native image lazy-loading since 5.5, but web.dev is explicit that the LCP image should never be lazy-loaded because it adds resource-load delay and harms LCP.
  • On WooCommerce, image sizing is template-specific: woocommerce_single is used on single-product pages, woocommerce_thumbnail in product grids, and woocommerce_gallery_thumbnail below the main gallery image on classic themes.
  • Product imagery is conversion-sensitive, so do not chase the most aggressive compression on zoomable product shots. Baymard found 56% of users’ first actions on product pages were to explore product images, and 25% of sites lacked sufficient image resolution or zoom.
  • Measurement should prioritise field LCP on product and category templates, not homepage scores. Google’s own guidance says field data is the better guide to what real users experience, while lab data is for debugging. ## Effort and Impact

How To Implement

  • Benchmark the current state before touching anything

    Measure product-page and category-page field LCP in Search Console’s Core Web Vitals report or PageSpeed Insights/CrUX, then capture a like-for-like lab baseline for the same URLs so you can compare total byte weight and the LCP element after the change. Google recommends field data for prioritisation because it reflects real users, while PSI combines field and lab data for diagnosis. Put the measurement note here: benchmark mobile and desktop separately, because LCP behaviour often differs by device and template.

  • Set the right image sizes for WooCommerce before bulk conversion

    On classic themes, review Appearance → Customize → WooCommerce → Product Images and choose thumbnail crop behaviour deliberately rather than leaving mismatched aspect ratios to the browser. WooCommerce’s classic image surfaces are woocommerce_single, woocommerce_thumbnail, and woocommerce_gallery_thumbnail, so your chosen sizes need to reflect how those templates actually render. WordPress responsive images then use generated sizes plus srcset/sizes to let the browser choose the best variant.

  • If you use a block theme, set image behaviour in the template, not the Customizer

    WooCommerce blocks are managed in the Site Editor and templates, and the Product Gallery block lets you set the image aspect ratio for the single-product template. In practice that means reviewing Appearance → Editor for the relevant WooCommerce template, then checking the Product Gallery block settings so the gallery ratio matches your product imagery instead of forcing awkward crops or inconsistent heights.

  • Choose one image-conversion route and keep it simple

    If you want local conversion with a familiar workflow, Imagify can auto-optimise on upload, bulk-optimise existing media from Media Library → Bulk Optimization, resize large originals from Settings → Imagify, and generate/display WebP or AVIF. Imagify also recommends backing up originals because they are needed to generate new thumbnail sizes later, restore originals, or create next-gen formats.

  • Use ShortPixel if you want strong bulk control, and SPAI only if you also want viewport-responsive delivery

    With ShortPixel Image Optimizer, enable WebP or AVIF under Settings → ShortPixel → WebP/AVIF & CDN, then run Media → Bulk ShortPixel so existing WooCommerce media gets next-gen output too. If your bigger issue is over-sized images per breakpoint, ShortPixel Adaptive Images can serve appropriately sized images based on the visitor’s viewport and can also deliver WebP/AVIF, but do not stack it with another image-delivery or lazy-load layer.

  • Use Smush if you want one plugin for compression, next-gen output, and lazy-load controls

    Smush can auto-compress all WordPress-generated copies on upload, bulk-process the Media Library, and create local WebP or AVIF output. Its WebP direct conversion requires no CDN or server setup, and you can verify delivery in DevTools by checking for content-type: image/webp or image/avif.

  • Lazy-load only below-the-fold media

    WordPress core can add loading="lazy" automatically, and plugins such as WP Rocket, LiteSpeed Cache, Smush, or ShortPixel Adaptive Images let you refine exclusions. The key change is simple: exclude the real single-product hero image, the actual category-page banner if you use one, and any first in-viewport image that is the real LCP element. On category grids, do not mark lots of first-row tiles as high priority; web.dev warns that putting fetchpriority="high" on more than one or two images becomes counterproductive.

  • Use the plugin’s exclusion controls instead of blanket code where possible

    In WP Rocket, use the Excluded images or iframes field to exclude the hero/LCP image by filename, image class, attribute, or container class for background images. In LiteSpeed Cache, use Page Optimization → Media Excludes and add the image URL, class, or parent class to the exclusion fields; LiteSpeed also supports Viewport Images processing. In Smush, you can exclude post types, specific pages, and image keywords/attributes from lazy-load behaviour.

  • If the hero image is discovered late, fix discovery before chasing more compression

    web.dev is clear that the LCP resource should be discoverable in the initial HTML response. If your theme or builder hides the hero in CSS, inserts it with JavaScript, or turns it into a CSS background image, compression alone may not fix LCP. In those cases, either output a real in HTML, add fetchpriority="high" to the true hero image, or preload it if it is only referenced later. WordPress core’s loading-optimisation system already understands loading, fetchpriority, and decoding, and explicitly warns not to combine loading="lazy" with fetchpriority="high" on the same element.

  • For classic-theme edge cases, use a hook rather than hard-coding markup everywhere

    If your theme is pulling the wrong image size or mis-setting attributes on the main product image, route the fix through WordPress image filters. wp_get_attachment_image_attributes can modify loading, fetchpriority, srcset, and sizes, and wp_get_attachment_image() is more efficient with registered image sizes than ad-hoc width/height arrays. On classic WooCommerce themes, the main product image template can also be overridden via yourtheme/woocommerce/single-product/product-image.php, but that is heavier maintenance and should be reserved for cases where filters are insufficient.

  • Regenerate thumbnails after changing sizes, then purge cache and CDN

    WooCommerce queues background regeneration when you publish Product Image setting changes in the Customizer or switch themes, and you can review the wc-background-regeneration log under WooCommerce → Status → Logs. If you change image sizes in code or through a theme/plugin setup that does not trigger the automatic queue, regenerate thumbnails before judging the result, then purge all caches so old image variants and stale HTML do not mask the outcome.

  • Validate the result in the browser, not just in plugin dashboards

    Inspect the actual product-page image markup and network requests. Check that the hero/LCP image is not lazy-loaded, confirm that one true hero image gets fetchpriority="high" at most, verify the served MIME type for WebP or AVIF, and confirm srcset/sizes are choosing smaller files on mobile. This is the fastest way to catch duplicate lazy-load layers, stale caches, and false positives from plugin status screens.

    HPOS caveat — No special HPOS caveat usually applies here, because HPOS is WooCommerce’s order-storage system rather than a media or template-image system.

How To Measure

The primary KPI is field LCP on product and category templates, read separately for mobile and desktop. Google’s guidance remains the same: aim for LCP within 2.5 seconds, INP under 200 ms, and CLS under 0.1 for a good user experience. Read this first in Search Console Core Web Vitals or PageSpeed Insights/CrUX for real-user performance, because those tools show field data rather than just lab simulation.

The supporting technical KPI is total page weight before vs after on a fixed set of representative product and category URLs. Use the same templates, the same products, the same device profile, and the same cache state when comparing, otherwise byte-weight comparisons are noisy. Lighthouse’s network payload audit is a sensible check here because large payloads correlate strongly with long load times.

The commercial KPI is purchase conversion rate by device, with RPV and AOV as supporting commercial reads. In GA4, make sure ecommerce tracking is working for view_item, add_to_cart, and purchase, then compare the purchase funnel by device category. GA4’s predefined reporting includes a Purchase journey view, and device category is collected automatically as desktop, mobile, or tablet.

If you want template-level speed data inside GA4 rather than only waiting for CrUX, instrument Web Vitals into GA4 and BigQuery. Google’s guidance is that CrUX-based tools are useful but delayed and only segment on limited dimensions, while GA4-based Web Vitals measurement lets you analyse performance against your own business segments.

What success looks like — Lower p75 field LCP on product and category URL groups, lower total image bytes on representative pages, and stable or improved mobile conversion rate and RPV after rollout.

Guardrail metrics — CLS must not worsen from layout changes, INP must not deteriorate from extra image scripts, conversion rate by device must not fall, and AOV should remain stable so you do not “win” speed by damaging product presentation quality.

Pitfalls

  • A common myth is that lazy-loading every image is always good for speed. It is not. web.dev explicitly warns that lazy-loading the LCP image always adds unnecessary resource-load delay and harms LCP.
  • Another common mistake is compressing product imagery until it looks “acceptable” in the plugin preview, without testing zoomed product detail on the live page. WooCommerce recommends at least 800 × 800 product images, and Baymard’s testing shows users rely heavily on high-resolution product imagery and zoom to evaluate products. For detailed or premium products, overly aggressive compression can make the product look cheap or unclear even if the page is technically lighter.
  • A third mistake is fixing byte size but missing resource discovery. If the real hero image is injected by JavaScript or only referenced from CSS, the browser cannot discover it early enough from the initial HTML, so LCP can stay slow even after converting to WebP. In those cases, preload or high fetch priority often matters more than another round of compression.
  • A fourth mistake is running more than one image-delivery or lazy-load system at the same time. ShortPixel specifically warns against combining SPAI with another WebP-delivery or image lazy-load method, and LiteSpeed documents conflicts when multiple lazy-load systems are active. Duplicate layers create broken exclusions, placeholder issues, and hard-to-debug markup.
  • A fifth mistake is using a server-rule delivery method without checking edge cases. ShortPixel’s .htaccess WebP/AVIF delivery has caveats and does not work on Cloudflare’s free plan because of header limitations, so “it’s enabled in the plugin” is not the same as “it’s being served correctly to shoppers”.
  • A final edge case is assuming WordPress updates cannot affect image behaviour. WordPress 6.7 introduced auto-sizes for lazy-loaded images as a progressive enhancement; that is generally positive, but brittle theme or builder CSS can expose sizing issues after updates, so image-heavy templates should always be regression-tested on staging.

Examples

FAQs

Sources & Further Reading

  • Optimize Largest Contentful Paint – Date: Last updated 31 March 2025 Note: Primary guidance on LCP sub-parts, resource discovery, why not to lazy-load the LCP image, and when to use preload or fetchpriority.
  • An image format for the Web – Date: Date not stated on page Note: Google’s primary WebP efficiency figures, including lossy WebP vs JPEG and lossless WebP vs PNG.
  • Serve images in modern formats – Date: Date not stated on page Note: Chrome Lighthouse guidance that AVIF and WebP have better compression/quality characteristics than JPEG and PNG.
  • Deploying AVIF for more responsive websites – Date: 2023 Note: Useful context on AVIF adoption and a vendor-reported savings benchmark; cited here as directional rather than independent evidence.
  • Adding Product Images and Galleries – Date: Date not stated on page Note: Official WooCommerce documentation on product-image types, where product images are managed, and recommended minimum image size.
  • Image sizing for theme developers – Date: Date not stated on page Note: Official WooCommerce developer docs for classic-theme image-size handles such as woocommerce_single and woocommerce_thumbnail.
  • Thumbnail image regeneration – Date: Date not stated on page Note: Official WooCommerce guidance on background regeneration when image settings change.
  • Image loading optimisation enhancements in 6.4 – Date: 18 October 2023 Note: Official WordPress Core note on loading attributes such as loading="lazy" and fetchpriority="high".
  • Auto Sizes for Lazy Loaded Images in WordPress 6.7 – Date: 18 October 2024 Note: WordPress Core note on the sizes="auto" enhancement for lazy-loaded images.
  • wp_get_loading_optimization_attributes – Date: Date not stated on page Note: Official function reference showing WordPress can emit loading, fetchpriority, and decoding, and should not combine lazy-loading with high fetch priority on one element.
  • Optimize critical images – Date: Date not stated on page Note: WP Rocket documentation showing automatic detection/preload of the LCP image and exclusion of above-the-fold images from lazy-load. Vendor documentation.
  • Page Optimization and Media Troubleshooting – and https://docs.litespeedtech.com/lscache/lscwp/ts-media/ Date: Troubleshooting page dated 9 February 2026; page-optimisation page date not stated Note: LiteSpeed documentation for excluding specific images/classes/parents from lazy-load and for Viewport Images behaviour. Vendor documentation.

Want us to implement this for you?

We run measured CRO consultancy for WooCommerce. If you want help prioritising, testing & implementing these improvements, tell us about your store.

Book Pilot

About This Page

  • Written By: Eliot Webb – Founder & WooCommerce CRO Consultant
  • Last Reviewed: 18 Jun 2026
  • Last Updated: