WooCommerce speed optimization, from free audit to measured fixes

The audit and the first week work through six layers in a fixed order, because each one can hide the next. Hosting and TTFB come first, measured uncached on a product page and a cart page against Google's 0.8-second guidance, along with the PHP version and whether a persistent object cache such as Redis is running (what a Redis object cache changes for WooCommerce). Images are second: the LCP element, its dimensions and format, and whether anything lazy-loads it. Plugins are third, audited on staging with Query Monitor. Then the database, where an autoloaded options table past the 800 KB mark that WordPress Site Health warns about slows every uncached request, and a backlog of past-due Action Scheduler jobs keeps adding rows. The theme's own assets and the third-party tags close the list. Where the server turns out to be the ceiling, the fix is a hosting change you make with your provider, and the report spells out what to ask for. Owners who want to check these causes on their own will find all six in why WooCommerce is slow.

A page cache and a CDN belong in the first week, configured with cart, checkout and my-account excluded, and on some stores they finish the job. They speed up anonymous catalog views. They do nothing for the JavaScript a heavy theme sends to every phone, and many host-level caches stop serving cached HTML once a shopper has something in the cart, so the visitor closest to paying gets pages built by PHP. When WP Rocket is not enough covers those cases and how to tell that caching has reached its ceiling.

Stores lose speed on the pages caching helps least, and those are the pages that cost sales. Phones get the worst of it, and the phone-specific work, from tap targets to image sizes and filter drawers, is laid out on mobile WooCommerce optimization. Cart and checkout are excluded from page cache by design, so every request there runs PHP:

• Category pages: heavy grids, layout shift, slow filters
• Product pages: bloated galleries and variation scripts
• Cart and checkout: the highest-intent, most script-heavy pages
• Mobile: where most traffic is and where themes perform worst

Cheapest first, because jumping straight to a rebuild skips savings you could have had for free. Field Core Web Vitals come before any change: they are the scores Chrome collects from real visitors, and they are what shoppers actually experience. TTFB is the wait before the server sends its first byte. Above Google's 0.8-second guidance, frontend work cannot hide it. Correctly sized, compressed images are often the single biggest win on LCP, the time until the main image or heading appears. Only if mobile still fails after the theme cleanup is the theme itself the ceiling. That order is how you avoid paying for a migration a caching plugin would have solved.

• Measure field Core Web Vitals before changing anything
• Fix hosting/TTFB, then images, then caching and a CDN
• Clean up the theme: unused modules, deferred scripts, no decorative sliders
• Rebuild the frontend only if mobile still fails after all of that

Day one is measurement, not changes: field data per template, a waterfall (the request-by-request loading timeline) on category and product pages, the plugin inventory and the database size. Day two is the cheap wins that carry no risk, such as image formats and dimensions, the LCP element loading eagerly, and obviously unused assets scoped to the templates that need them. The rest of the week is the plugin audit on staging, one deactivation at a time with a measurement after each. By Friday you have a ranked list of what each item is worth, and that list is what a sensible budget is built from, against published package prices.

• Baseline first: field data, waterfall, plugin list, database size
• Zero-risk fixes before anything structural
• Plugin audit on staging, one change at a time
• A ranked list of what each fix is worth

Four findings turn up often enough to check first. The main product image is lazy-loaded when it should load eagerly, which delays LCP. A slider or gallery library loads site-wide for one homepage carousel. A filter plugin ships its entire JavaScript stack onto product pages that have no filters. And the options table carries years of expired transients, temporary values WordPress stores in the database and nobody has pruned. None of these require a rebuild. Together they often account for most of the gap between where a store is and where it needs to be.

A Next.js storefront is faster because each page is built before the visitor asks for it: pre-rendered HTML from a global CDN, optimized images, locally hosted fonts and minimal JavaScript, designed to pass Core Web Vitals from the start. Product data comes live from WooCommerce over its API, so prices and stock stay accurate while the pages stay light. Your WordPress admin doesn't change. What the rebuild does not touch is a slow server behind that API, which is why hosting and TTFB come earlier in the order. A rebuild is a Launch Setup from $1,999 or a Growth Customization from $4,500, and how each metric gets designed in is on fixing WooCommerce Core Web Vitals at the storefront.

You get before-and-after numbers per template from field data, never a single lab score, plus the list of changes made and the items we recommended against, with the reason. You will not get a promised Lighthouse number. Scores move with the device, the network and the third-party scripts your marketing team adds next month. We commit to measurement and to explaining what each change bought, and if the honest answer is that the remaining gap needs the storefront layer replaced, you hear that instead of receiving a longer invoice.

This service is not for every slow store, and the free audit says so when it isn't. If the problem is server response time or unoptimized images, a caching plugin or a CDN fixes it cheaply, and we will tell you exactly that. If field data already passes on the category and product templates, the work is not worth buying, whatever a lab score says. A new frontend gets recommended only when the theme is the real ceiling. Still deciding whether a slow store is a hosting ticket or a developer's job? Match the symptom to who fixes it before you contact anyone.