Yuvraj Raulji | WooCommerce optimisation
Page caching makes a WordPress site fast and stops at the cart. Everything WooCommerce adds, cart fragments, session handling, dynamic pricing, the admin order screen, runs outside the cache by design, which is why a store can score well on its homepage and crawl on the pages that take money.
Direct answer
WooCommerce is usually slow in the places page caching cannot reach. Cart, checkout, account and any page with dynamic pricing are excluded from full-page cache by design, so they fall back to PHP and the database on every request. The usual fixes are removing or limiting cart fragments, adding object caching so repeated queries are not recomputed, indexing the postmeta queries a large catalogue generates, and cutting the plugin weight that runs on every page. The storefront pages benefit from ordinary WordPress caching; the commerce pages need this work specifically.
Best suited for
- A fast homepage and a slow cart
- Checkout timing out under campaign traffic
- Admin order screens that hang on a large store
- Core Web Vitals failing on product templates
What this page is not
This page is about the commerce paths: cart, checkout, account, product and the queries behind them. General site speed, page caching, hosting, templates and assets across a whole WordPress install, belongs to the site rather than the store.
The problem
The symptom as the person carrying it would describe it, and the part that shows up in the numbers rather than in the ticket queue.
The homepage is fast and the cart is not
What it costs
Page caching covers everything except the pages that take money. The reported site speed looks healthy while the commercial pages are the slowest on the site.
Cart fragments run on every page
What it costs
An uncached request fires on pages with no cart interaction at all, adding latency site wide to keep a counter accurate. It is one of the most common and most fixable WooCommerce performance costs.
The admin becomes unusable as the store grows
What it costs
Order screens and product lists time out, so operations moves to exports and spreadsheets. The storefront looks fine and the business is being run around the platform.
Plugins run everywhere, including where they do nothing
What it costs
Each loads assets and queries on every request regardless of relevance. The cumulative cost lands hardest on mobile, which is where the conversion is lost.
Approach
In this order, and the order is the opinion. Most of what goes wrong on this kind of engagement is a step taken before the one it depends on.
Measure the commerce paths separately
Field data for cart, checkout and product templates on their own rather than a site average. A blended score hides the exact pages the money moves through.
Deal with the uncached paths first
Cart fragments limited or removed, object caching in place so uncached pages are not recomputing the same queries, and session handling checked. This is where WooCommerce specifically differs from WordPress.
Fix the database work
Postmeta queries, missing indexes, autoloaded options and transients accumulating in the options table. On a store of any age this is usually a larger cost than the front end.
Cut plugin weight per page
Stop plugins loading assets and running queries where they do nothing. Removal beats deferral, and on WooCommerce there is normally something to remove.
Then the experience and the funnel
Images, layout stability and the checkout form itself. Speed raises the ceiling on the commerce pages; the form design is what collects it.
Scope
Uncached paths
Cart fragment controlObject cachingSession handlingDynamic pricing cost
Data layer
Postmeta query tuningIndex reviewAutoloaded optionsTransient hygiene
Front end
Plugin asset controlImage pipelineLayout stabilityCore Web Vitals by template
Conversion
Checkout form designGuest checkout pathPayment UXFunnel instrumentation
Outcome
The pages that take money get measured
Most WooCommerce stores have never seen cart and checkout performance separated from the site average. Simply measuring them properly usually changes what the team works on next.
Less work per request, permanently
Removing cart fragments, unused plugin assets and recomputed queries reduces the work every request does. That is a durable change rather than a tuning setting somebody can undo.
The 60% site speed improvement published on this site came from caching, CDN and database work on a Magento platform and belongs to that page. No WooCommerce build appears on the work record with a published measurement, so no percentage is claimed here.
Questions
- Why is my WooCommerce checkout slow when the rest of the site is fast?
- Because cart, checkout and account are excluded from full-page caching by design, since their content is specific to each visitor. Those pages fall back to PHP and the database on every request, so they need object caching, query work and a lighter plugin load rather than the page caching that made the rest of the site quick.
- Should I disable WooCommerce cart fragments?
- Usually limit rather than disable outright. Fragments keep the cart counter live and fire an uncached request to do it, including on pages with no cart interaction. Restricting them to the pages that genuinely need a live count keeps the behaviour and removes most of the cost.
- Does hosting fix WooCommerce performance?
- Good hosting removes a floor and does not remove the causes. If the store is slow because of cart fragments, unindexed postmeta queries or plugins loading everywhere, faster hardware makes the same work happen more quickly and the cost recurs every month.
- How many plugins can a WooCommerce store carry?
- It depends far more on what they do per request than on the count. A plugin that loads assets and runs queries on every page costs more than five that only act on their own templates. The audit worth running is per-page cost, not a total.
- Is a slow WooCommerce admin a sign we should replatform?
- Not on its own. Admin slowness is usually postmeta queries, missing indexes and an options table nobody has cleaned, all of which are fixable in place. It becomes a platform signal when the commerce logic itself has outgrown what plugins can express.
Next step
Describe what is actually in front of you and we will work out whether this is the right piece of work before anyone scopes it. That conversation is usually shorter than people expect, and it occasionally ends with me saying you do not need the project.