Start WooCommerce image optimization with the image your visitor is waiting for, the size the browser actually downloads and the product detail the shopper needs. A late image request or broken product crop needs its own fix before a library-wide compression job.
These 11 tasks cover product pages, catalog grids and galleries. Choose the first task from the symptom you can reproduce:
| What you see | Start here |
|---|---|
| Main product image appears late | Check its loading path and selected resource: tasks 1–2 |
| A small card downloads a very large photo | Check responsive selection, requested sizes and compression: tasks 2–6 |
| Price or buttons jump as images appear | Reserve the right image space: task 7 |
| Zoom, crops or variation photos are wrong | Check theme sizes and gallery behavior: tasks 3 and 9 |
| Replaced photos stay old or differ between visitors | Trace the actual delivery path: task 10 |
Use a representative category page, a simple product and a variable product. Record the installed WordPress, WooCommerce, theme and gallery implementation before changing settings. This is a documentation-based workflow with illustrative examples, not a report of tests on a merchant's store.
1. Remove loading delays from the main product image
Identify the actual Largest Contentful Paint (LCP) element on the page you are investigating. It may be the main product photo, but do not assume that from the page type alone.
If the image request starts late, reducing the file by a few kilobytes may leave the main delay untouched. Check whether the image URL is available in the initial HTML, whether a gallery script inserts it later and whether an optimization layer has added loading="lazy".
Google's LCP optimization guide advises against lazy-loading the LCP image. A selective fetchpriority="high" hint can help an important image, but assigning high priority to every gallery slide defeats that prioritization.
WordPress already has loading-optimization logic. Inspect the final attributes before adding another override. In particular, a lazy-loading instruction and high fetch priority are conflicting choices for the same image.
Make the change through the theme or gallery component that owns the output. Confirm that the intended photo starts loading earlier without forcing all secondary photos into the initial request burst. If the request finishes early but the image remains hidden, investigate the gallery's rendering delay rather than compressing it repeatedly.
2. Serve the responsive image the layout needs
A product card can look small while downloading the original photograph. CSS that reduces its displayed width does not make that download smaller.
Inspect one affected image in the browser's developer tools. Record its displayed dimensions, selected URL (currentSrc), available srcset candidates and sizes value. Compare the requested file with the slot the shopper actually sees.
For an illustrative 480 CSS-pixel-wide image on a display with a device-pixel ratio of 2, a roughly 960-pixel-wide candidate is a useful starting comparison. That is not a rule that the browser must always choose exactly 960 pixels: available candidates and browser conditions affect selection.
WordPress's responsive image documentation explains how candidate information lets the browser select a resource. Themes and custom image widgets can still supply an inaccurate layout size or omit useful candidates.
Fix the markup or widget setting that causes the wrong selection before reducing every source image. A catalog card and a zoomable product viewer should not automatically use the same resource.
When comparing results, keep device, viewport and test conditions consistent. Screpy's PageSpeed Insights metrics guide helps distinguish a controlled diagnostic run from real-user performance data.
3. Match WooCommerce sizes and crops to the theme
Separate the original upload, the generated image size and the visible layout. Changing one does not necessarily change the other two.
WooCommerce's product image documentation distinguishes the main product image, catalog images and smaller thumbnails. It suggests originals of at least 800 × 800 pixels as a starting point, while noting that fine-detail products can need larger images. That is not a universal instruction to serve every card at 800 pixels.
Check Appearance → Customize → WooCommerce → Product Images where those controls are available. A theme can declare widths that hide the corresponding controls. With block themes, also inspect the product template and its gallery block in Appearance → Editor.
WooCommerce's theme-width guidance makes an important distinction: requested image widths do not change the theme's CSS layout width.
Choose a crop that keeps the whole important product area visible. A square catalog crop that cuts off a lamp's shade or a shoe's heel is not a successful optimization. Preserve a sufficiently detailed original for zoom and full-screen viewing; a larger requested size cannot recreate detail missing from a small upload.
Use a new sample upload to check the settings before applying them across the existing catalog.
4. Compress photos without hiding product details
Once the dimensions are appropriate, compare compression settings on a small, varied sample. Include a plain-background product, a textured material, small printed text and an image with transparency if your catalog uses it.
Keep an untouched master. Export a candidate, then inspect it at the sizes shoppers use, including the zoom or full-screen view. Look for blurred stitching, unreadable labels, halos around edges, banding and color changes.
There is no single quality setting or kilobyte limit that fits every WooCommerce image. A gallery detail photo and a small cart thumbnail have different jobs. Choose the smallest result that preserves the information required for that job.
Also check which file your optimization process changed. Improving the original while leaving an oversized derivative in use will not fix that derivative's transfer cost. Conversely, repeatedly recompressing an already degraded file can remove detail that the original still contains.
Use the same sample to approve settings before a bulk job. Keep the prior files and attachment associations recoverable, and record the output you accepted. A smaller file is useful evidence; it is not proof of a particular LCP improvement, conversion increase or ranking gain.
5. Check format support across the upload path
Compare formats your store can actually generate and serve, such as JPEG, WebP and AVIF. Evaluate the output at comparable visual quality, including transparency and fine detail. Do not assume that changing a filename extension converts the image.
Run a sample through the same path your catalog uses: manual upload, product import or an existing image service. Confirm that the required thumbnail sizes are created and that the public page receives the intended format. Inspect the response's Content-Type, not just the source filename.
Version and upload path matter. For example, WordPress 7.1's media-processing documentation describes browser-side processing on supported paths and browsers, including AVIF handling without server-side AVIF support. Unsupported browser paths can use server-side processing instead. Older server-library requirements therefore should not be presented as a universal rule for every current upload.
That also does not establish that a WooCommerce import or a third-party uploader follows the same browser path. Check your installed setup.
Keep a working delivery path for the browsers and integrations you support. Approve the format change only after product pages, catalog cards and zoom views all display the right images.
6. Regenerate outdated image sizes before bulk cleanup
If new uploads look correct but older product images do not, inspect the generated sizes. The setting can be right while the stored derivatives still reflect a previous theme or layout.
After taking a recoverable backup, use your site's supported thumbnail-regeneration process on a small sample. Confirm that it produces the sizes the current theme requests. Check job completion and missing-image errors before extending the work to a large library.
Then clear the relevant image and page caches and inspect the selected URLs again. Distinguish an outdated file from a cached old response: generating a replacement and delivering that replacement are separate steps.
Do not delete every unfamiliar image size to reduce storage. A candidate that looks unused on your desktop may be needed for another viewport, a product grid, a gallery or another template. Check usage and responsive candidates before removing it.
Keep the originals needed to regenerate images. If an image has lost detail because its only remaining source is too small or overcompressed, regeneration cannot restore that detail. Recover a suitable master rather than repeatedly regenerating the same inadequate source.
Finish with the same product and category examples used to choose the dimensions.
7. Reserve image space before it loads
A fast image can still cause a poor experience if the price, description or Add to Cart button moves when it appears.
Check that the page reserves space using correct image dimensions and appropriate aspect-ratio handling. Google's layout-shift guidance identifies images without dimensions as a common cause of instability. The reserved shape must still match the displayed image; arbitrary width and height values can create another mismatch.
Inspect a narrow product page, the category grid and a product whose gallery contains different shapes. Check the initial placeholder as well as the loaded image. A fixed-ratio container may be useful, but choose whether it should contain or crop the photo according to the product, not just visual uniformity.
Test what happens when selecting another gallery item or variation. A layout that is stable for the first image can jump when a portrait detail shot replaces a landscape view.
Keep this task separate from compression: fewer bytes do not establish the correct geometry. Correcting image space can address an image-related shift, while fonts, banners and other elements may still require their own diagnosis.
8. Defer images shoppers cannot see yet
Reduce initial image work where it does not help the first screen: offscreen related-product cards, lower-page content and gallery items that are not yet visible.
Do not apply the rule “lazy-load everything except the first image” without inspecting the layout. More than one useful image may be visible immediately, and the first image in the markup is not necessarily the LCP element.
Check whether WordPress, the theme, the gallery and an optimization plugin are all adding loading behavior. Use the component that owns the image output to establish a consistent policy. Multiple lazy-loading layers can produce placeholders or delayed requests that are difficult to diagnose.
Keep meaningful image URLs and alternative text available in the output. An implementation that exposes important product images only after an extra interaction can create discovery problems.
Compare the initial request list with what loads when scrolling or selecting a gallery item. Hidden carousel images may need explicit gallery handling; native lazy loading alone is not proof that every hidden resource is deferred.
The successful result is less unnecessary competition during the first screen, followed by working images when shoppers reach them. It is not a smaller initial request count at the cost of broken product information.
9. Simplify galleries without breaking product choices
Keep images that answer different buying questions: overall shape, materials, scale, included items and meaningful details. Remove accidental duplicates and near-identical views that add requests without adding information.
There is no universal maximum gallery length. A simple accessory and a configurable machine need different amounts of visual explanation. Preserve the detail that a shopper would otherwise need to ask about.
Check variation behavior before and after the change. Selecting a blue option should not leave a red product photo in the main viewer. Verify the selected product state, image order, zoom and full-screen view on the gallery your template actually uses.
The current WooCommerce Product Gallery block documentation distinguishes the newer Product Gallery block from the older Product Image Gallery block. In particular, it documents a compatibility difference when used with Add to Cart + Options: the newer gallery supports its variation-image updates. Confirm installed versions and template settings before treating a gallery swap as an image-file problem.
Optimize the gallery that serves your product correctly. Removing essential variation views or disabling useful zoom solely to improve a score can make the page less useful even if it downloads less.
10. Fix stale delivery and overlapping image processors
Trace one image from its attachment through the generated file, any transformation service and the final response. Write down which component owns resizing, compression, format conversion and delivery.
Several components can legitimately take part. The problem is overlapping responsibility: two systems rewriting the same URL, recompressing the same file or applying inconsistent format rules.
Inspect the final request URL, response type, transferred bytes and relevant cache headers. Compare the first request with a repeat request, noting browser-cache behavior. No single cache-header name or result applies to every setup.
If a replacement image remains old, check the actual URL and cache key. Confirm that the page points to the intended version and that the appropriate image and page caches have refreshed. Re-uploading the file repeatedly may create more attachments without resolving stale delivery.
Use a CDN or image service to solve an observed delivery problem, not as a substitute for correct dimensions and loading priority. Keep any configuration changes scoped to the image path; this task is not a recommendation to change caching for WooCommerce carts, checkout or customer pages.
Assign one owner to each stage, then repeat the product, category and variation checks after the output changes.
11. Preserve image meaning and search discovery
Keep the optimized image understandable to both shoppers and search systems. For a meaningful product photo, write concise alt text that describes what that view shows.
For example, “Navy canvas backpack, rear view showing padded straps” is more useful than “product image” or a repeated list of backpack keywords. Do not add details the image does not show, and do not treat a particular character count as a requirement.
Google's image guidance recommends standard image elements and explains that Google can discover an image through its img element's src attribute. Keep a valid source in responsive markup and confirm that the actual image URL remains accessible after a delivery change.
Use descriptive filenames for new uploads where practical. Avoid mass-renaming established URLs without preserving references and planning the migration. Alt text and filenames do not reduce transfer size or guarantee indexing, rankings or AI citations.
Maintain one repair record so these tasks produce specific changes. This CSV contains illustrative issues and example URLs, not observations from a real store. Replace them and fill in the selected image URLs from your own inspection:
page_url,image_role,observed_issue,selected_image_url,change,owner,acceptance
https://example.com/product/sample/,main,late_request,,review_loading_priority,theme_owner,correct_main_image_starts_promptly
https://example.com/product-category/sample/,card,oversized_resource,,correct_responsive_selection,theme_owner,appropriate_candidate_and_sharp_card
https://example.com/product/sample/,gallery,wrong_variant_photo,,review_gallery_compatibility,store_owner,selected_option_matches_photo
https://example.com/product/sample/,detail,generic_alt,,describe_visible_detail,content_owner,accurate_contextual_alt
Screpy's guide to image audit tools with MCP support covers collecting image findings and tracing them to source pages. Keep those findings separate from completed repairs.
Before a catalog-wide change, approve a sample and retain a recovery path for files, attachment references and settings. Repeat the same public-page checks afterward with consistent device and viewport conditions. Confirm image detail, crops, variation selection, loading and delivery as well as any performance result. Expand the change when the intended problem is fixed and the shopping experience still works.