WooCommerce Image and Variation Optimisation

WooCommerce Image and Variation Optimisation is not a theory problem. It starts with a URL, a visible symptom and a decision about which layer to test first. The useful answer is the one that changes the measured behaviour without breaking another part of WordPress.

The useful evidence usually comes from several places: a lab test, a waterfall, a browser trace, a WordPress admin screen and the cache or CDN headers returned to a logged-out visitor.

Treat every change as something another person may need to reverse. Name the original symptom, keep the old value, export settings where possible and avoid changes that cannot be tied back to the test result.

Split the store into page types

A WooCommerce problem around WooCommerce image optimisation must separate cached catalogue browsing from dynamic purchasing. Product pages, baskets, checkout and accounts are not the same workload.

• category pages are fast but checkout waits
• cart fragments run on pages that do not need them
• variation data inflates product page HTML
• scheduled actions or sessions grow quickly

For WooCommerce, do not use one test page as proof. Product browsing, basket updates, checkout, account pages and order emails exercise different code paths and different cache rules.

Catalogue speed versus checkout speed

The order matters: prove the symptom first, then move to the layer most likely to own it.

• WooCommerce Status screen
• GTmetrix waterfall for product and checkout pages
• LiteSpeed Cache exclusions
• Query Monitor
• test order flow

Where scripts and fragments appear

• 1. exclude cart, checkout, account and order-pay from shared cache
• 2. measure product, category and checkout pages separately
• 3. review payment, shipping and recommendation scripts
• 4. optimise product images before CDN delivery

A store needs two test plans: one for catalogue browsing and another for buying. Category and product pages can usually benefit from shared cache; basket, checkout, account and order-pay pages must remain dynamic and customer-specific.

Decision point for WooCommerce image optimisation

For WooCommerce image optimisation, decide whether the page is catalogue, basket, checkout, account or admin. Catalogue pages can often be cached and delivered efficiently. Checkout and account pages must stay dynamic. Cart fragments, payment scripts, shipping APIs and scheduled actions need their own test path.

When the evidence is split, prefer the lowest-risk reversible change first. Excluding one script from JS Delay is safer than disabling all optimisation. Purging one CDN URL is safer than clearing a whole zone during trading hours.

Artefacts to keep for WooCommerce image optimisation

A good support note links the symptom to one layer. The artefacts should show whether that layer was WordPress, LiteSpeed Cache, BunnyCDN, DNS, SSL, WooCommerce or the browser.

• WooCommerce Status screenshot and active payment/shipping plugins.
• Network trace for product, basket and checkout pages tested separately.
• LiteSpeed exclusions for cart, checkout, account and order-pay URLs.

Store speed mistakes

• caching customer-specific pages
• testing only as an administrator
• adding product widgets without checking INP

Keep the evidence small and useful. One annotated waterfall, one settings screenshot and one retest result are usually better than a folder full of unrelated screenshots.

Close-out checks

• Run product, basket, checkout and account tests separately.
• Confirm cart and checkout pages are excluded from shared cache.
• Place a test order after payment, shipping or cache changes.

WooCommerce questions

What makes WooCommerce image optimisation different on WooCommerce?

WooCommerce image optimisation should be checked against the failing URL, not a generic checklist. Use the symptom, the tool output and the WordPress layer involved to decide the next action.

Can checkout be cached?

Shared cache should not serve customer-specific WooCommerce pages. Cart, checkout, account and order-pay URLs need exclusions, then a real test order should confirm totals, shipping, payment and emails.

Which page should be tested first?

WooCommerce image optimisation should be checked against the failing URL, not a generic checklist. Use the symptom, the tool output and the WordPress layer involved to decide the next action.

Document the cache purge used for the final test. Without that note, a later stale page can look like a new fault when it is really an old cache object.

For WooCommerce, add the customer state. Logged-out browsing, customer with basket, logged-in account user and administrator are different tests. Cache headers that are correct for a category page may be dangerous on checkout.

If the store has many orders, check scheduled actions and sessions before blaming the theme. Checkout delays often come from dynamic work that never appears on a cached product page.

Also check ownership of checkout scripts. Payment, finance, shipping, reviews and analytics scripts should all have a reason to run during purchase. Remove anything that does not support the transaction.

Retest the exact page that triggered the work, not a cleaner page from the same site.

If the tool output does not explain the next action, collect a better trace or screenshot.

Rollback planning is engineering hygiene, not pessimism. Keep it visible.

When the issue involves Core Web Vitals, record which metric you are trying to move before changing settings. LCP, INP and CLS often need different fixes, so one combined score is not enough evidence.

Retest once more after clearing only the relevant cache layer.

Save the note with the test result so the next fix starts from evidence, not memory.

Summary

WooCommerce image optimisation is solved by narrowing the problem until one layer owns the next action. The most useful article, ticket or audit note names the URL, the symptom, the measurement, the change and the retest result.