WooCommerce is not a simple page-based website. Prices, stock, filters, carts, customer accounts and payments make every visitor partly unique. A generic “cache everything” approach is therefore unsafe. A fast shop aggressively accelerates static pages while correctly excluding dynamic journeys.
Measure each customer journey first
Do not test only the home page. Measure a category, a variable product, search, cart, checkout and My Account. Test mobile, warm and cold cache, anonymous and logged-in sessions. Record TTFB, LCP, INP, request count, PHP time and slow queries. A fast home page should never hide a slow checkout.
Cache what is safe and exclude dynamic pages precisely
Product and category pages are often suitable for page cache. Cart, checkout and account pages should remain visitor-specific. Also inspect cookies and currency, language or dynamic-pricing extensions. Incorrect caching can expose another cart or serve stale inventory.
- Use server-level page cache through LiteSpeed Cache.
- Keep standard WooCommerce exclusions and test every custom flow.
- Avoid purging the entire cache for every minor event.
- Warm important category and product pages carefully.
Redis object caching: repeat less database work
A persistent object cache retains expensive query results between requests. It can help with product objects, options, menus and repeated calculations. Redis does not replace an efficient database or page cache; it adds another layer. Isolate accounts safely, monitor memory and verify that extensions invalidate cached objects correctly.
Database: orders, sessions and autoload
A growing store collects revisions, expired transients, sessions, logs and background jobs. Identify which tables grow before deleting anything. WooCommerce High-Performance Order Storage (HPOS) places orders in dedicated tables and can make administrative and order queries more scalable, provided all critical extensions are compatible.
Review autoloaded data in wp_options. Large autoloaded options slow every WordPress request, even where the responsible plugin is not otherwise needed. Take a recoverable backup before maintenance.
PHP workers, cron and background jobs
A request requiring PHP temporarily occupies a worker. During peaks, checkout, API calls and webhooks can form queues. More workers only help when CPU, memory and the database can support them. Replace visitor-triggered WP-Cron with a real scheduled task, review Action Scheduler and resolve failed or stuck actions. Payment webhooks and stock updates must remain fast and reliable.
Images, scripts and external services
- Serve product photography in WebP or AVIF and suitable dimensions.
- Lazy-load below-the-fold images, not the main product image.
- Load filters, sliders and tracking code only where required.
- Avoid variation tools that generate thousands of DOM elements or queries.
- Measure chat, reviews, advertising and payment widgets independently.
- Use HTTP/3 and a CDN for static assets where geography provides a benefit.
Optimise without breaking checkout
- Create a full backup and work in staging.
- Record a baseline and the critical customer journeys.
- Change one layer at a time: hosting, cache, database, frontend or plugins.
- Test guest and customer orders, coupons, shipping, tax, payment and email.
- Release a limited production change and monitor errors and conversion.
Frequently asked questions
Can checkout use page cache?
Normally no. It is session- and customer-specific. Incorrect caching creates functional and privacy problems.
Does Redis accelerate every store?
Not automatically. Benefits depend on queries, object use and extension compatibility. Measure before and after.
How many plugins are too many?
Quality and behaviour matter more than the count. One poorly written extension can be heavier than twenty small, efficient ones.
Do you need a shop that stays responsive during campaigns? Explore our WordPress hosting or ask Gigatech for a WooCommerce performance review.
Sources: WooCommerce performance guide and WooCommerce performance documentation.
