Image Optimization for WooCommerce: Diagnose Before You Optimize

Measure First: Why Your Images Might Not Be the Problem

Everyone blames the images. A product page feels slow, someone opens PageSpeed Insights, sees a warning about image sizes, and orders a plugin. Sometimes that's right. Often it isn't.

Start with Lighthouse and look specifically at Largest Contentful Paint. Images are the usual suspect on product pages because they're big and visible, but LCP can be dragged down by a slow server response just as easily as a heavy JPEG.

Open Chrome DevTools, go to the Network tab, and actually look at what's loading. Check the real file sizes and load times of your product images. A lot of stores are serving an oversized image not because nobody compressed it, but because the srcset attribute is telling the browser to load the wrong size for the device.

Check your database too. A bloated database with slow queries can delay the whole page render, images included, and no amount of compression fixes that. If you haven't looked at this before, I've written about how to approach it in database cleanup for slow WordPress sites.

And watch for the fix creating the problem. You install a plugin to speed things up and the plugin becomes the bottleneck.

The Real Culprits: Diagnosis Workflow Before You Optimize

Srcset misconfiguration is quiet. It doesn't throw an error. It just quietly serves a 2000px image to a phone and nobody notices unless they check.

According to WooCommerce's product images documentation, WooCommerce generates three default image sizes out of the box: shop_thumbnail, shop_catalog, and shop_single. Plenty of custom themes ignore these defaults entirely, or generate a srcset with sizes that don't match anything the browser actually needs, which forces it to guess and often guess wrong.

Next, check whether your optimization plugin is actually doing its job. Some stores have had one installed for a long time, but caching plugins conflict with it, or the conversion queue silently stalled, and the derivatives never got generated. The plugin looks active in the dashboard but isn't touching new uploads.

Check Time to First Byte. If TTFB is high, your bottleneck is upstream of images entirely, it's your server or your database, and no image work will fix it.

Then run a waterfall in WebPagetest or a similar tool. If images load after your text and buttons render, lazy loading is doing its job. If images are blocking paint, that's a srcset or LCP problem, not a "need more compression" problem.

When WebP and Lazy Loading Actually Work

If your diagnosis says images genuinely are the bottleneck, WebP and lazy loading are worth doing, and they're not complicated.

Per Can I Use's WebP browser support data, WebP now reaches around 96% of global browser traffic as of 2024, and Google's WebP documentation states it typically compresses 25 to 35% smaller than JPEG with no visible quality loss. That's a real, low-risk win once you know images are your LCP problem.

Native lazy loading with the loading="lazy" attribute is standard now. MDN notes it's been widely supported since around 2019. Add it to product images below the fold. Don't add it above the fold, and don't expect it to fix a slow hero image, because lazy loading only delays requests, it doesn't shrink them.

A CDN, whether that's Cloudflare, Bunny, or CloudFront, solves a different problem: distance. It serves images from a location physically closer to the visitor, which helps regardless of format or compression. If your traffic is spread across regions, this often matters more than another round of compression.

Test whatever you pick against your actual traffic mix before trusting it fully. Modern plugins handle WebP fallbacks reasonably well now, but "reasonably well" and "correct for your visitors" aren't always the same thing.

Plugin vs. Manual vs. Custom Code: The Decision Tree

Once you know images are genuinely the problem, the next decision is how to fix them, and this is where most guides stop short. Here's how I'd think about it.

Use a plugin, something like Smush, Imagify, or ShortPixel, if your catalog is small, you can't or don't want to touch code, and you're fine trading some overhead for convenience. It's the right call for a lot of small stores.

Optimize manually if you're under roughly 50 product images and want full control. Download them, compress locally with something like ImageOptim, upload at the exact size WooCommerce actually needs, and skip the plugin entirely. No ongoing overhead, no conversion queue to babysit.

Build custom code, or integrate a headless image service like Imgix or Cloudinary, if you're running hundreds of products or need programmatic control over image generation. It's more work upfront but it scales without the accumulating tax a plugin adds per image, per page load. On a marketplace I built and still maintain, this is closer to the territory where custom handling starts paying for itself, once catalog size gets large enough that plugin overhead compounds across every listing page. If you're weighing this route for your own site, when to build a custom WooCommerce plugin walks through the broader decision.

Before you add anything, audit what's already installed. Some stores are running fifteen-plus plugins before this conversation even starts. One more image tool, even a good one, can still drag things down. I've written a full walkthrough on this in the hidden cost of plugin bloat.

Optimization Checklist: The Tactical Next Step

Once you've picked your path, the execution is fairly mechanical.

Decide which image sizes you actually need and regenerate thumbnails accordingly. WooCommerce's defaults are fine for most stores, but custom themes often need adjusted dimensions.

Force proper srcset and sizes attributes on your product images. A surprising number of templates leave these blank, which means the browser is guessing, and guessing wrong.

Set lazy loading at the plugin or theme level, but only for anything below the fold. Anything above it should load immediately, full stop.

Run Lighthouse before and after each change. These wins are incremental, but they stack.

Then check Google Search Console for real user Core Web Vitals after you deploy. Lighthouse is a lab test on one machine. Search Console shows what your actual visitors experienced, and that's the number that matters.

Before you touch any live settings here, particularly regenerating thumbnails or changing caching and lazy-load config, back up the site and test on a staging copy first. Bulk thumbnail regeneration on a large catalog is not something you want to discover breaks a template in production.

If you want a broader pass beyond images, the website speed checklist I run before launch covers the rest of what typically slows a page down.

When to Call Image Optimization Done

Stop when Lighthouse shows LCP under 2.5 seconds and your real user data in Search Console is green. Chasing a perfect 100 score past that point is mostly ego, not user experience.

If images are already tight and the page is still slow, the bottleneck has moved upstream. Look at database queries, payment gateway calls, or plugin conflicts next, the same diagnosis-first instinct, just aimed somewhere else.

Write down what you did: which plugin, which settings, what the srcset configuration looks like. Whoever touches this next, possibly you in a year, will thank you, and you'll catch a regression fast instead of relearning the whole problem from scratch.

If you've already tried the obvious fixes and your product pages are still slow, that's usually a sign the real bottleneck was never the images to begin with. Happy to take a look, or you can start with e-commerce work or just get in touch.

What's the last thing you optimized on your site that turned out not to be the actual problem?

FAQ

Does WebP actually matter if my images are already huge files?

No. If your source images are 2MB before compression, WebP saves 500KB, good but not transformative. Reduce source size first (shoot at 1920px wide for product photos). Then apply WebP. Format matters less than resolution.

Should I lazy load images above the fold?

No. Lazy load only images below the fold. Images in the hero or primary product area should load immediately. Lazy loading above the fold actually hurts LCP.

Can image optimization plugins and CDNs conflict?

Sometimes. If your plugin generates WebP derivatives and your CDN also converts to WebP, you're doing the work twice. Pick one approach: plugin-based or CDN-based, not both.

How do I know if a srcset is misconfigured?

Open DevTools Network tab, find product images, and check what the browser actually loaded. If it loaded a 2000px image on mobile, your srcset is broken. A correct srcset loads smaller images on small screens.