Rule zero: measure before touching anything
Install nothing yet. Capture the current state: page-load timelines on the home page, a category page, a product page and — most importantly — the cart and checkout. Note the Core Web Vitals numbers as your baseline. Every fix that follows gets judged against this baseline; without it, you cannot tell the fixes that worked from the ones that merely moved the numbers.
Also record where the time goes. A store that takes four seconds to first render and a store that renders fast but takes four seconds to become interactive have different diseases and different cures.
Fix the hosting reality first
WooCommerce is a database-backed application; it outgrows shared hosting quietly. Symptoms: load spikes during promotions, admin screens lagging, slow cart updates even with caching enabled. The honest fix is infrastructure: adequate PHP workers, current PHP version, enough memory, and a database that is not sharing a machine with two hundred unrelated neighbors. Caching cannot fully compensate for a host that cannot serve dynamic requests — and WooCommerce requests are dynamic by nature.
Cache in layers — and know what must NOT be cached
Effective store caching is layered: page cache for anonymous browsing of products and categories, object cache for repeated database reads, CDN for media and static assets. The discipline is in the exclusions: cart, checkout and account pages must never be page-cached, or customers see each other's data. Most "my store shows the wrong cart" incidents are a caching plugin configured by someone who did not know that rule.
Images: the cheapest large win
Product photography is usually the heaviest payload on a store. Serve responsive sizes so phones do not download desktop images, use modern formats, lazy-load below-the-fold media, and define dimensions so pages stop jumping while loading. This is an afternoon of work that typically outweighs every speed plugin combined.
Cart and checkout: the requests that matter most
Two WooCommerce-specific patterns explain most remaining slowness:
- Cart fragments. The classic AJAX cart widget forces a dynamic request on every page for every visitor. If your theme loads it globally, your whole catalog pays for it. Either scope the fragment to pages that need it or replace the pattern.
- Checkout weight. Checkout runs uncachable queries, payment scripts and tracking tags. Every field, upsell and script you add there lands directly on the conversion moment. Audit checkout scripts with the same aggression you would apply to a landing page — because it is one.
Database health and HPOS
Years of orders, sessions and transients leave a store database bloated; expired session rows and orphaned meta are common. Clean them deliberately, with backups, on a schedule — not by installing a "database cleaner" that deletes things it does not understand.
If you are on modern WooCommerce, you should also be on (or migrating to) High-Performance Order Storage (HPOS): order data in dedicated tables, queries that stay fast as order volume grows. If you run extensions on top of WooCommerce — especially anything touching the account area — verify those extensions are HPOS-aware. An extension that queries order tables directly will age badly on HPOS stores; HPOS-native tooling stays correct across WooCommerce updates. This distinction is exactly why we build our WooCommerce product the way we do: it reads through the public WooCommerce APIs and never queries HPOS tables directly.
Plugins: subtract before you add
Every plugin is code loaded on requests where you do not need it. The audit is simple and brutal: list everything active, identify what each one does for revenue, and remove or replace the ones earning nothing. Replace broad general-purpose plugins with one engineered solution when a plugin exists but taxes every page to serve one page. Fewer moving parts also means fewer security surfaces and fewer update-night surprises.
Verify like an engineer
- [ ] Baseline captured before changes (home, category, product, cart, checkout)
- [ ] Hosting: PHP version, workers, memory confirmed adequate
- [ ] Page cache excludes cart/checkout/account; object cache active
- [ ] Images responsive, modern format, lazy-loaded, dimensioned
- [ ] Cart fragments scoped; checkout scripts audited
- [ ] Database cleanup scheduled with backups; HPOS status known
- [ ] Plugin list reduced to what earns its load
- [ ] Re-measure and compare against baseline — keep the wins, revert the noise
Performance work is not a one-time project; it is a budget the store either pays deliberately or pays invisibly in conversion. If you would rather have the audit done for you — measurement, findings, fixes, re-verification — that is a standard engagement on our side.