Most WordPress speed advice assumes a page that looks the same for every visitor. A store is not that. Half of what matters on a WooCommerce site happens on pages a cache is not allowed to touch, which is why a store can score well on a homepage speed test and still feel slow to somebody actually buying something.
This is the store-specific half. For the general work, our non-technical guide to speeding up WordPress covers caching, images and hosting without assuming you can edit code, and all of it still applies here. What follows is what it does not cover, because none of it exists on a normal site.
Why a store behaves differently
Three things separate WooCommerce from a brochure site, and all three work against you.
It writes constantly. Sessions, carts, stock levels, order status. A blog reads from the database and serves the same HTML to everyone. A store writes on almost every meaningful interaction, and writes cannot be cached.
Its important pages are personal. Cart, checkout and My Account differ per visitor, so full-page caching is deliberately switched off for them. Those are also the pages where money changes hands.
It carries more code. A typical store runs twenty to forty extensions on top of WooCommerce itself, and a good proportion of them load their scripts on every page rather than the one page they are needed on.
The practical consequence: your product pages are usually a caching problem, and your checkout is almost always a hosting problem. Fixing one does nothing for the other, which is why stores so often install a caching plugin, watch the homepage score jump, and notice no difference in how the site feels.
Measure the right thing before changing anything
Testing your homepage tells you almost nothing about your store. Three measurements are worth having, and only one of them comes from a page-speed tool.
1. Time to first byte on an uncached page
Load your cart page, not your homepage, and look at how long the server takes to respond before anything renders. This is TTFB, and on an uncached store page it is a direct reading of your hosting and your database. Under about 0.6 seconds is healthy. Over 1.5 seconds and no amount of front-end work will save you.
2. The three field metrics, from real visitors
Lab tools simulate one visit on one connection. Core Web Vitals collected from actual traffic tell you what your customers experienced, including the ones on a phone with a poor signal. Google Search Console reports them per URL group, so you can see product pages and checkout separately rather than as one average.
3. A real transaction, timed
Add to cart, go to checkout, place an order, and time it with a stopwatch. It sounds crude and it is the most useful number on this page, because it is the only one that includes your payment gateway, your shipping calculator and your order emails. Do it once a month and you will notice a regression the week it happens rather than the quarter it happens.
Write the three numbers down before you touch anything. Speed work without a baseline is guessing, and stores accumulate changes fast enough that you will not remember what you altered.
WooCommerce hosting with object caching and staging on every plan
Talk To Sales →The pages caching is not allowed to touch
Page caching stores a finished copy of a page and hands it to the next visitor. That is safe for a product page and dangerous for a cart, because serving one customer a cached copy of another basket is a data breach rather than a bug. So every sane caching setup excludes cart, checkout and My Account.
Those excluded pages therefore run the full stack on every request. PHP executes, the database is queried, nothing is reused. Their speed is set by three things, in this order:
- Your server. How much CPU you actually get, and whether it is shared with hundreds of other accounts.
- Your database. How big it is, how well indexed, and whether queries hit memory or disk.
- Your PHP version. Each recent release of PHP has been meaningfully faster than the one before, and stores are routinely left two or three versions behind.
Notice what is absent from that list: plugins. There is no caching plugin that speeds up the checkout, because the thing making checkout slow is the work caching is forbidden from skipping. This is the most common misunderstanding about store performance, and it is why the rest of this article spends more time on infrastructure than on settings.
Object caching, the one that helps
An object cache is different from a page cache. Instead of storing finished pages, it stores the results of individual database queries in memory. The next request needing the same answer gets it from RAM rather than asking the database again.
That matters here because it works on the uncached pages. Checkout still runs its PHP, but the dozens of queries behind it are answered from memory. On a store of any size this is the largest single infrastructure difference between quick and sluggish, and it is the thing cheap shared hosting does not offer.
The usual implementation is Redis, occasionally Memcached. Both have to be available on the server; a plugin alone cannot provide one. If you are weighing up datastores more generally, our comparison of Redis and MongoDB covers what each is actually for.
Two things to check rather than assume. First, that the cache is genuinely connected and not merely installed, which most object cache plugins report on their settings screen. Second, that it has enough memory allocated to hold your working set, because a cache that evicts entries constantly does very little.
Object caching is included on our WooCommerce hosting, and it is worth asking any host about directly rather than reading it off a feature grid.
Cart fragments, a quiet tax on every page
WooCommerce keeps the small cart total in your header accurate using a background request that fires on page load. It is called the cart fragments request, and on an otherwise well cached site it is frequently the only uncached thing happening, which means it sets the pace for the whole page.
The awkward part is that it runs everywhere, including on pages with no cart in sight. A visitor reading a blog post triggers a request whose only job is to confirm their empty basket is still empty.
What to do depends on your theme:
- If your header shows a live cart count, you need the request on pages where somebody might add to cart. Limiting it to shop, product, cart and checkout pages is usually enough.
- If your header does not show a cart count, or shows one that only updates on page load anyway, you can switch it off outside the store pages entirely.
Stores routinely find this is the largest single saving available to them, which is a strange thing to be true of a feature most owners have never heard of. Test it properly afterwards: add a product, check the count updates where you expect it to, and place an order.
How your orders are stored
Historically WooCommerce kept orders in the same database table as posts, pages and revisions. It works, but it means every order query competes with everything else in the site, and the table grows in a way that gets slower rather than just bigger.
New stores now use dedicated order tables by default, which makes order queries dramatically cheaper as volume grows. Older stores may still be on the legacy arrangement, and many owners have no idea which they are on.
Checking takes a minute in the WooCommerce advanced settings. Migrating, if you are on the old one, is a genuine maintenance task with a real payoff, and one worth doing on staging first because it moves data rather than flipping a setting. The WooCommerce documentation on order storage walks through it.
The admin side benefits most. If your shop feels fine but the orders screen crawls, this is usually the reason.
Product images, still the heaviest thing you serve
Product photography is why store pages are large. Three habits fix most of it, and none of them need a developer.
Serve modern formats
WebP and AVIF are dramatically smaller than JPEG at the same visual quality. Most image plugins and most decent hosts will convert and serve them automatically.
Upload at the size you actually display
A 4000 pixel wide photograph shown in a 600 pixel box wastes the difference on every single visitor. Resizing before upload is the least glamorous and most reliable saving on this page.
Do not lazy load the main product image
Lazy loading delays images until they are near the viewport, which is right for everything below the fold and actively harmful for the one image at the top. Deferring it delays the very thing Largest Contentful Paint measures, so the metric gets worse because of an optimisation.
A CDN then puts those images physically nearer your customers, which matters more the further your audience sits from your server.
The plugin audit nobody wants to do
Every extension is code that runs. The question is not how many you have but how many load on pages that do not need them, and the answer is usually most of them.
A wishlist plugin has no business loading its JavaScript on your checkout. A reviews plugin does not need to run on your cart. A page builder used on two landing pages should not be loading its stylesheet on four hundred product pages. None of this is plugin authors being careless. Loading everywhere is simply the safe default when you do not know how a site is built.
Work through it in this order:
- Delete what you do not use. Deactivated plugins are still files on your server and still need updating. If you have not used it in six months, it goes.
- Find what loads on checkout. Your browser developer tools network tab lists every script the page requests. Anything you cannot justify is a candidate.
- Look for overlap. Two plugins doing similar jobs is common after a few years, and one of them is usually redundant.
- Prefer one good extension to three small ones. Each carries its own overhead regardless of how little of it you use.
Do this on staging. Deactivating plugins on a live store is how you discover which one your checkout quietly depended on.
What belongs to your host, not to you
It is worth being clear about the split, because a lot of money gets spent on plugins trying to solve problems that live one layer down.
| What | Whose job | What happens if it is wrong |
|---|---|---|
| Object caching available | Host | Uncached pages stay slow whatever you install |
| PHP version and workers | Host | Checkout queues under concurrent traffic |
| Database performance | Host | Admin and order screens crawl as you grow |
| CDN for static files | Both | Distant customers wait longer than local ones |
| Page caching config | You | Either nothing is cached, or carts leak between visitors |
| Cart fragments scope | You | Every page carries an uncached request it does not need |
| Image sizes and formats | You | Pages are several times heavier than they need to be |
| Plugin load discipline | You | Checkout runs code belonging to unrelated features |
If most of the left column is on your side of the line and things are still slow, the problem is underneath you. Our specification of WooCommerce hosting requirements lists what to hold any host to, hosting for high-traffic WordPress sites covers what to move to, and managed versus shared hosting covers why the cheap option stops working at exactly the point a store starts succeeding.
The order to do it in
Biggest effect for least risk first. Stop when the store is fast enough, because there is always another millisecond and it stops being worth your time well before you run out of things to try.
- Take a backup and open staging. Everything below is reversible only if you can go back.
- Record your three numbers. Uncached TTFB, field metrics, and a timed test order.
- Confirm object caching is on and connected. Largest single win on the pages that matter, and it is a hosting question.
- Limit cart fragments. Often the biggest front-end saving on the site.
- Check your order storage. Migrate on staging if you are on the legacy tables.
- Fix the images. Modern formats, sensible dimensions, and the main product image not lazy loaded.
- Audit the plugins. Delete the unused, then find what loads on checkout.
- Re-measure the same three numbers. If nothing moved, the constraint is your server.
Speed is not a project you finish. It is part of WooCommerce maintenance, alongside updates and backups, and it decays quietly if nobody is looking. The stores that stay fast are the ones where somebody checks the numbers every month, not the ones that had a big optimisation push two years ago.
One caution worth ending on. Several items here involve removing or restricting code, and a thinner checkout is a faster checkout but not automatically a safer one. Read WooCommerce security alongside this, particularly before you start deciding which scripts your checkout can live without.
FAQs
Because they are measured on completely different things. Your homepage is almost certainly served from a page cache, so it never touches PHP or the database. Checkout is deliberately excluded from caching, so it runs the full stack on every request. A fast homepage and a slow checkout is the normal signature of a store whose hosting is the limiting factor.
It will speed up your product and category pages, which is worth having. It will do nothing for cart, checkout or My Account, because those pages are excluded from page caching for safety. For those you need object caching, which has to be available on the server rather than provided by a plugin.
Under about 0.6 seconds on an uncached page such as the cart. Between 0.6 and 1.5 is workable but worth improving. Above 1.5 seconds, front-end optimisation is largely wasted effort, because the browser sits idle waiting for the server before it can start.
Only outside your store pages, and only if your theme does not need a live cart count elsewhere. Switching it off everywhere can leave a header cart total that never updates, which looks broken to a customer mid-shop. Limit it rather than remove it, then add a product and place a test order to confirm nothing regressed.
There is no number. Ten badly behaved plugins that load everywhere are worse than forty well built ones that load only where needed. The useful question is what runs on your checkout, which you can see in your browser developer tools network tab.
It does when the uncached pages are the problem, which for stores is common. Object caching, PHP resources and database performance are all set by the platform, and no plugin substitutes for them. If your cached pages are quick and your checkout is not, moving is usually the fix rather than a last resort.
Hosting That Fixes The Half Plugins Cannot
Object caching, tuned PHP workers and a database that is not sharing a server with a thousand other sites. The uncached half of your store is set by infrastructure, and that is what we sell.
See WooCommerce Hosting