WooCommerce image optimization with ShortPixel is a different job from compressing a blog’s media library. A store serves the same product photograph at three separately registered sizes, repeats that work behind every variation of every variable product, and shows the result on pages where a shopper is deciding whether to spend money. ShortPixel can reduce those files and create next-generation copies, but it cannot correct the wrong dimensions or an unsuitable crop. Set the catalog structure first, then configure the optimizer around it.
The three sizes a store actually serves
WooCommerce registers its own image sizes instead of relying only on the WordPress defaults. According to the WooCommerce theme image sizing documentation, three of them carry the catalog:
- woocommerce_thumbnail — the tile used in product grids such as the shop page. It defaults to 300px wide and is square cropped so grids line up.
- woocommerce_single — the main image on an individual product page. It shows the product image as uploaded, so it is uncropped by default, and defaults to 600px wide.
- woocommerce_gallery_thumbnail — the small strip below the main image used to switch the gallery. It is always square cropped and defaults to 100 × 100 pixels.
Two things follow. One photograph already exists as several stored files before any optimization plugin is installed. And the registered width is not necessarily the displayed width: the same documentation notes that a theme can change the displayed size with CSS, and that a product grid’s column width may constrain it further. Judge the result from what the browser downloads on a real product page, not from the number in a settings field.
Themes can also fix those widths themselves. Since WooCommerce 3.3.0, a theme may declare thumbnail_image_width, single_image_width, and gallery_thumbnail_image_width when it declares WooCommerce support, and where a theme defines them the store owner cannot change them from the Customizer. Check the active theme before concluding that a control is missing or broken.
Settle sizing and cropping before you compress
Classic themes expose catalog and thumbnail sizing at Appearance > Customize > WooCommerce > Product Images, with three cropping choices: 1:1 squares, a custom ratio, or uncropped. The main single-product image is deliberately outside that setting and stays uncropped. Block themes built for full site editing do not use the Customizer, so the same decisions are reached elsewhere in those themes.
Changing a dimension does not finish the job. Existing derivatives keep their old measurements until they are rebuilt, and WooCommerce provides a Regenerate Shop Thumbnails action at WooCommerce > Status > Tools for that purpose. Sequence matters here more than in an ordinary blog: compress first and regenerate afterwards, and the optimized derivatives are simply replaced by fresh unoptimized ones. Resize, regenerate, then optimize.
Source resolution matters in the opposite direction too. WooCommerce’s product image documentation recommends a minimum of 800 × 800 pixels for product photographs, while WordPress core scales large photographic uploads down when the width or height exceeds 2560 pixels, then treats the scaled copy as the full size. A 6000-pixel camera export is therefore neither preserved at 6000 pixels by default nor a sensible source for a 300-pixel grid tile.
Variation images multiply the work
This is where a store’s arithmetic stops resembling a blog’s. In WooCommerce variable products, each variation can carry its own primary image, and the core Variation Gallery feature lets a variation hold several images rather than one. When a shopper selects a variation, WooCommerce swaps the product gallery over to that variation’s images; clearing the selection brings the parent gallery back.
Every one of those images is a new upload, and every upload generates the full set of registered sizes again. A hoodie sold in six colours is not one product photograph with six labels — it can be six galleries, each producing its own grid tile, single image, and gallery thumbnails. Before estimating cost or runtime for a catalog, count variation images, not products.
The same feature creates a quality trap. Shoppers use variation images to compare colours side by side, so a compression setting that is invisible on a landscape photograph can become obvious when two shades of the same garment are viewed one after another. Test a variation swap, not just a single hero shot.
Configure ShortPixel for a WooCommerce catalog
Start with one difficult product rather than the whole Media Library. Use a variation with fine texture, a dark colour, small packaging details, and a zoomable image. Compare ShortPixel’s Lossy, Glossy, and Lossless results at the grid, single-product, gallery, variation-swap, and zoom sizes. Lossy prioritises reduction, Lossless prioritises preservation, and Glossy sits between them; the correct choice is the least costly setting that still preserves the details customers need to judge the product.
Keep the original-image backup enabled until the representative test and restoration check have passed. A backup consumes disk space, but deleting it before the catalog has been inspected removes the straightforward rollback path. Confirm free storage before a bulk run and restore one test image before relying on the backup for the full catalog.
If ShortPixel creates WebP or AVIF copies, choose one delivery path and verify it in the browser’s network panel. ShortPixel can deliver next-generation images through its own CDN or serve locally generated files, while caching plugins can also perform replacement. Do not leave two delivery systems competing for the same image URLs. Check the shop grid, product page, cart, related-products block, and variation swap in a private window after clearing caches.
Thumbnail selection is the WooCommerce-specific cost control. Enable optimization for the catalog sizes that real pages request, then exclude a registered size only after confirming that the active theme, cart, widgets, and product blocks do not use it. Excluding an apparently unused derivative without observing the storefront can trade a small credit saving for a missing or oversized image.
Budget ShortPixel credits by file, not by product
ShortPixel’s credit documentation explains that ShortPixel deducts a credit when an original image or thumbnail is reduced by at least five percent; no credit is deducted when that threshold is not reached. Each thumbnail is counted separately, and each generated WebP or AVIF counterpart requires an additional credit. For a store, the practical billing unit is therefore the derivative file, not the product listing.
Estimate the workload before starting: count images across products and variations, multiply by the number of registered sizes the live store genuinely serves, and account for each next-generation counterpart you choose to create. A catalog that looks like a few hundred products in the admin can produce several thousand optimization events. Run a small representative batch first and compare the actual credit change with the estimate before committing the entire library.
Which image on a store page is worth the effort
On a product page, the main image is usually the largest visible element and the one a shopper waits for. It should not be lazy-loaded, and it should not be a 2560-pixel file squeezed into a 600-pixel slot. Compression cannot repair a dimension mismatch; it only makes an oversized file a slightly smaller oversized file.
Shop and category archives fail differently. No single image is large, but a grid may request dozens of tiles at once, so the cost is the total count rather than one heavy download. The effective fixes there are fewer products per view, correctly sized tiles, and proper responsive markup — not a more aggressive compression level applied to everything.
Zoom is the third case and the easiest to forget. The gallery’s zoom and full-size view use the WordPress full size, which is the image a shopper inspects most closely before buying. Whatever compression the catalog uses, check that file specifically.
Where stores cannot afford aggressive compression
Some categories tolerate heavy compression and some do not. Fabric weave, jewellery engraving, fine print on packaging, and cosmetic shade accuracy all degrade in ways that a landscape photograph hides. For those products the risk is commercial rather than cosmetic: a colour that shifts between the grid tile and the product page can become a returns problem and a support ticket, not just a design complaint.
Choose test images accordingly. Comparing settings on the best-lit hero product proves very little. Pick the worst case in the catalog — a dark textile, a metallic surface, a product photographed against white, a label with small type — and judge the compression mode on those. If one category genuinely needs gentler treatment than the rest, it is usually better to exclude that category than to weaken the setting for the entire store.
Operational cautions on a live store
- Do not run a bulk job during a promotion. A sale, a launch, or a newsletter send is the wrong moment to add sustained background processing and cache invalidation to a checkout flow.
- Check disk space before enabling local backups. Keeping originals for a large catalog is a real hosting cost, and running out of space mid-run is worse than not having backups planned at all.
- Test on staging when the gallery is customised. WooCommerce’s own guidance is to try variation gallery changes on a staging site first if the store already uses a variation gallery extension or custom product-gallery code.
- Never point two optimizers at one media library. Overlapping tools waste credits, complicate restoration, and make it far harder to attribute a visual regression to its cause.
- Re-run after a theme change. New registered widths mean regenerated derivatives, and regenerated derivatives are new files that need optimizing again. Budget for it rather than being surprised by it.
- Watch product imports. A CSV or supplier feed can add hundreds of images in minutes, which is an easy way for a store to exhaust a monthly allowance before anyone notices.
The mechanics of running the job itself — queue behaviour, backups, restarts, and what to verify afterwards — are the same as for any large WordPress library, and are covered in the guide to WordPress bulk media optimization. What changes for a store is the ordering and the stakes, not the mechanism.
A pre-run checklist for a WooCommerce catalog
- Confirm whether the active theme fixes the image widths or leaves them to the store owner.
- Decide the cropping ratio and the catalog width, and publish those settings.
- Regenerate shop thumbnails so the derivatives match the new dimensions.
- Open representative pages — shop grid, product page, gallery switch, variation swap, cart — and record which image sizes are actually requested.
- Exclude the registered sizes that no live page requests.
- Count images across products and variations, multiply by the surviving sizes, and multiply again for next-generation copies.
- Verify a restoration path and the free disk space it needs.
- Process one difficult product first and inspect it at grid, single, gallery, and zoom scale.
- Only then run the full catalog, and clear page, object, and CDN caches afterwards.
- Re-check the same representative pages as a shopper would see them, not from the plugin dashboard.
Frequently asked questions
Should product images be compressed before uploading to WooCommerce?
Resizing before upload is usually worthwhile; heavy compression before upload usually is not. Sending a sensibly sized original avoids wasted storage and stops the 2560-pixel core threshold from deciding the dimensions for you. Compressing twice, however, stacks quality loss without a matching saving.
Does optimizing images change WooCommerce image sizes?
No. An optimization plugin processes the files that WordPress and WooCommerce have already generated. Which sizes exist, how they are cropped, and how wide they are remain decisions made in the theme and the product image settings.
Do variation images need to be handled separately?
They are ordinary media library uploads, so a bulk run will normally include them. They matter separately for planning, because they can dominate the file count in a catalog, and for review, because the variation swap is where compression differences between similar colours become visible.
Will WooCommerce image optimization increase sales?
It can reduce page weight and load time, which is a measurable result. Conversion depends on pricing, product range, trust, shipping terms, checkout friction, and much else besides, so no image plugin can promise a revenue outcome. Measure the file savings and the visual quality; treat anything beyond that as untested.
What should be checked immediately after a bulk run?
Look at the shop grid, one product page, the gallery switch, a variation swap, and the zoom view, using a private browsing window with caches cleared. Confirm which format the browser received, confirm the visible quality on the hardest product in the catalog, and confirm that nothing in the cart or a widget lost an image size that was excluded.