WooCommerce is slower than a content site for a structural reason: cart, checkout and account pages cannot be cached. They are different for every visitor, so page caching. The single biggest optimisation available to a WordPress site, deliberately skips exactly the pages where a sale is won or lost.
That is why store owners so often report that caching "did nothing". The homepage got much faster and the pages that matter did not change at all.
Cache what you can, then work on the rest
Enable server-level page caching anyway. Product listings, category pages and the homepage are cacheable and they are how most people arrive.
Ahosting runs LiteSpeed, so the cache lives in the web server rather than in PHP: a cached page never starts WordPress at all. Confirm a cache hit in the response headers rather than assuming, and confirm cart and checkout are correctly excluded, because a cached cart served to the wrong shopper is far worse than a slow one.
Optimizing WordPress performance goes over the general setup. What follows is the part specific to a store.
Cart fragments are the usual culprit
WooCommerce keeps the cart total in the header current with an AJAX request that runs on every page load, including pages with no cart on them.
That request cannot be cached and it starts PHP each time, so on a busy store it consumes a large share of the PHP processes your plan allows, which is the resource that actually limits a site under traffic.
If your header does not show a live cart count, disabling cart fragments removes the request entirely and is frequently the single largest improvement available to a WooCommerce store. Test the cart still works afterwards.
Object caching for the pages you cannot page-cache
Page caching stores finished HTML. Object caching stores the results of database queries, which helps precisely on the uncacheable pages: cart and checkout still have to run, but they run with fewer queries.
This is the optimisation that improves checkout, and it is the one most stores skip because page caching gets all the attention.
The database grows differently on a store
A content site accumulates posts. A store accumulates orders, and every order writes many rows of metadata.
Two things follow. Old completed orders make queries slower over time, so archiving orders beyond your legal retention period is real maintenance rather than tidiness. And expired sessions and transients accumulate faster than on a content site.
Take a backup before any database cleanup; it is one of the few optimisations that can destroy data.
Product images
Usually the largest thing on a store page, and usually oversized. A photograph uploaded at camera resolution and displayed in a 300-pixel grid costs bandwidth on every listing view.
Resize before uploading, use a modern format, and check what the product grid actually loads: some themes serve the full-size image and scale it in the browser, which defeats every thumbnail WordPress generated.
Fewer plugins on checkout
Every plugin that runs on checkout adds to the one page you cannot cache. Audit what actually executes there with a query monitoring plugin, on the checkout page specifically in place of the homepage.
Analytics, chat widgets and marketing scripts frequently load on checkout when they do not need to, and they compete with the transaction for the same PHP processes.
When it is the plan, not the store
If the store is fast at night and slow during a sale, you are hitting the ceiling on concurrent PHP requests. Caching helps because it removes the cacheable pages from that queue, but checkout still needs a process each.
A store that is consistently at the ceiling with caching working has outgrown shared hosting, and VPS hosting with dedicated resources is the honest answer rather than more tuning.
Speed is one half of a product page; the other is whether it answers the questions that stop a purchase. How to Improve WooCommerce Product Pages has the detail.
Caching is where most of the speed comes from and also where the most alarming store bug comes from. Why WooCommerce Carts and Sessions Break with Caching walks through keeping both.
The admin is a separate performance problem
Everything above is about what visitors experience. A store's admin can be slow while the shop front is fast, and none of the page caching helps: admin pages are never cached, by design.
The usual cause is the order list, which on older stores joins across metadata rows for every order displayed. Newer WooCommerce versions store orders in dedicated tables instead, and moving to that is the single largest improvement available for admin speed.
It is a migration instead of a setting, so take a backup and test on a copy first: running a staging store walks through making that copy safely, and speeding up a slow WordPress admin walks through the non-store causes.
Scheduled work runs during visits
WordPress triggers background jobs when someone visits the site, so on a store with many queued actions: emails, stock updates, subscription renewals: some visitors are paying for that work in their page load.
Moving scheduled work to a real system cron removes it from the visitor path entirely, and it also makes the jobs run on time rather than when traffic happens to arrive.
On a store this matters twice over, because a stalled queue also means webhooks not delivered and emails not sent, why scheduled tasks do not run explains the change, and webhooks and integrations deals with what fails silently when it stalls.
Measure the checkout separately
Speed testing tools measure the homepage, and the homepage is cached. The pages that decide whether an order completes are the ones that cannot be.
curl -o /dev/null -s -w 'ttfb %{time_starttransfer}\n' https://example.com/
curl -o /dev/null -s -w 'ttfb %{time_starttransfer}\n' https://example.com/cart/
A large difference between those two figures is the real state of the store: cached pages fast, uncached pages slow, and every customer meets the second set on the way to paying.
That is the number worth improving, and it is improved by object caching and by reducing what runs on those pages rather than by anything to do with page caching. Measuring page speed properly walks through judging the results.
Search is the expensive page nobody tests
Product search and filtered category pages cannot be cached usefully, because every combination is a different result, and each one runs a database query.
On a store with a large catalogue this is frequently the slowest thing the site does and the most attractive target for automated traffic, scrapers enumerate a catalogue through exactly those pages.
Two responses: make the queries cheaper with a proper search index, and stop crawlers from walking every filter combination, improving WooCommerce search and filters goes over the first, stopping bots and scrapers the second.