The previous two posts explained why a WooCommerce store is slow for structural reasons and what Headless WooCommerce is. This post is the other side of that coin, and it is the one we most want you to read: when not to do it.
Why write this at all
Because the most expensive thing about a project is not the money, it is discovering six months later that it was not the problem. A store whose speed was never the bottleneck ends up with the same revenue, minus the cost.
Here are five situations where we will tell you that upfront.
1. Speed is not costing you money
This is the first and most important test, and it is entirely numerical.
Take three figures from your own data: monthly sessions, conversion rate, and average order value. Multiply them and you have your revenue from the site. Now ask what one or two percentage points of conversion is worth.
In a store making a few thousand a month, that improvement is a small sum. In a store making tens of thousands, the same percentage is already a number that justifies a project.
The same budget, in a small store, will do more if it goes to product photography, content or advertising.
2. The catalogue is too small to justify a store
With five to ten products, the right question is sometimes not how to speed the store up but whether you need a store at all.
A fast brochure site with a page per product, and a purchase that moves to WhatsApp or an external link, usually gives a faster experience, costs less to build and needs far less ongoing maintenance.
A full store earns its keep when there is a real catalogue, variations, changing stock and orders arriving steadily.
3. Plugins that live in exactly the layer we touch
Splitting rebuilds the side your customer sees. Plugins generating complex real-time behaviour in the display layer live precisely there:
- Personalisation calculators and product configurators
- Pricing that changes for the logged-in user
- Membership systems and complex gated areas
- Integrations injecting their own interface into the product page
Sometimes there is a clean equivalent. Sometimes it raises the cost of the project substantially. And sometimes the right answer is not to touch it, which we will say after looking, not before.
4. Something fundamental in the business is about to change
If you are mid-rethink about what you sell, to whom, or under what model, there is no point building the storefront for something that may not survive the rethink.
Decide what you sell first. Build second.
5. Your store is already fast enough
This happens, and not rarely. If your TTFB is low, the score is decent and Core Web Vitals are green, the gain from splitting is small.
In that situation, every unit of budget spent on photography, content or advertising will return more than the same amount spent on architecture.
How to check this yourself, without talking to us
- Run the store through PageSpeed Insights and look at TTFB, not just the overall score.
- Open your own data and pull the three figures: sessions, conversion, average order.
- Ask what a one-point improvement in conversion is worth, in money, per month.
- Compare that to the cost of the project.
If the answer is small, you just saved yourself money and made the right call.
And if you are not sure
That is exactly what the digital health report is for: it measures speed, real Google rankings and visibility in AI engines, and shows what is worth fixing and what is not. It exists partly to save you from unnecessary large decisions.
If after all that the split does look right for you, the full details are on the online store page.