Slow WooCommerce store: which fix, and who should do it

Run the free speed check or PageSpeed Insights on a product page and read TTFB before any score. Use a product page because the homepage is the page most likely to be cached, so it tells you the least. At 0.8 seconds or under, the server is doing its part and the time is going into what the phone downloads and runs. Above it, the page is late before the browser has a single byte to work with, and no amount of theme work or rebuilding will hide that. Repeat the test twice more at a different hour. A number that swings from 0.4 to 2 seconds through the day is a capacity problem, which is still your host's, even though the morning test looked fine.

If TTFB is high, open a ticket before paying anyone else, and ask four questions. Which PHP version is the store on? PHP 8.1 stopped getting security fixes at the end of 2025, so an older version is a reason to upgrade whatever the speed. How many PHP workers does the plan include, and does the store run out of them at peak? Is a persistent object cache such as Redis available, and is it switched on? And what is TTFB on the cart page, which no page cache can serve? A host that cannot answer those has answered you anyway. Moving hosts is the right call when cart-page TTFB stays above the line with the object cache on. It is the wrong one for a store whose HTML already arrives in 300 milliseconds: a bigger server makes nothing in the browser lighter. A store that goes down under load rather than just slowing is a separate problem, covered on a store that keeps going down.

When the server answers quickly and the page still crawls on a phone, the job belongs to a WooCommerce developer, and most of it fits inside the current theme. The usual list is short. An LCP image that is lazy-loaded or several times larger than its slot. A slider library loading site-wide for one homepage carousel. Plugin scripts enqueued on templates that never use them. An autoloaded options table past the 800 KB mark where WordPress Site Health starts warning about it. This is days of work, done on a staging copy with a measurement after every change, not a project. Ask whoever you hire how they will measure before and after. A developer whose first move is installing another optimization plugin is the worse hire: plugins stacked on WP Rocket fight over the same files and tend to break add-to-cart before they save a byte. If the store got slow right after an update, the narrower checklist on slow after an update is faster than a general audit.

A rebuild is the third job, and it only becomes the right one after the first two are finished. Three signs line up. TTFB is under the line, images and plugins are cleaned up, and mobile field data still fails on category and product templates while desktop passes. INP is usually the metric that refuses to move, staying above Google's 200-millisecond threshold because the theme's own JavaScript keeps the phone's main thread busy. WoodMart, Flatsome, Elementor-heavy builds and WPBakery shortcode templates reach this point by different routes; the shared cause is a theme that sends every template the code for every feature. The WoodMart and Flatsome pages go through those routes theme by theme. Replacing the frontend is the worse choice whenever TTFB is the problem, because a new storefront still waits on the same slow server for prices and stock.

Replacing the storefront leaves WooCommerce running the business. Products, prices, stock, coupons, orders, emails, tax rules and the admin stay in WordPress, and checkout can stay native through a hybrid checkout, so payment gateways and sales tax plugins keep working as they do today. NextWoo's Launch Setup starts at $1,999 and goes live in one to two weeks. Growth Customization, with brand design and custom sections, starts at $4,500, and stores with serious search traffic or complex plugins are scoped individually as a Premium Migration. Before any quote, the audit sorts the plugin list into backend-only, frontend-rendering and needs-special-handling.

The first is a larger hosting plan for a store whose HTML already arrives in under half a second. It feels like progress and changes nothing a shopper sees. The second is a second optimization plugin on top of WP Rocket; when WP Rocket is not enough covers what caching cannot reach and why stacking makes it worse. The third is the expensive one, a rebuild commissioned on a red Lighthouse score while field data is green. A Lighthouse run is one emulated phone on a throttled connection. Buy a rebuild against that number and you cannot judge it afterwards, because none of your customers ever experienced the number.

If you would rather not run the numbers yourself, WooCommerce speed optimization starts with a free audit that does this sorting, then a week of measured fixes on the current theme and a ranked list of what each remaining change is worth. A store whose field data already passes on product and category templates needs neither the audit nor the fixes. Spend that budget on traffic or stock instead.