Classic WooCommerce or headless, which suits your store?

# TagsWooCommerceHeadlessSpeed

The WPhost team30 Sep 202615 min read

Your store runs on WooCommerce, and the pages slow down with every campaign. Or you are just starting out and wondering whether to choose classic WooCommerce or a headless store, which you have heard is faster. The choice depends on a few things you can judge without being a developer.

In this guide we go through them one by one: how big the catalogue is, how many visitors you have and whether there are peaks, which plugins take part in the checkout, what the budget is and who will look after the store. We also explain what stays the same for you, what changes and how the choice affects speed and SEO. There is a checklist at the end.

How classic WooCommerce differs from a headless store

In classic WooCommerce the store is part of WordPress. The theme shows the products, the cart and the checkout page, and plugins add whatever is missing, from choosing a courier office to the invoice fields. Every page view that is not served from the cache goes through PHP and the database on the same server.

In a headless store, the storefront shoppers see is a separate Next.js application. WooCommerce keeps the products, stock, orders and customers, and it remains the place where you run the store. The two parts talk through APIs. WooCommerce has a REST API for products and orders and a Store API built for the cart and checkout on the public side of a store. The Store API documentation also describes how the cart works with a headless storefront.

If you would like to understand how headless works in general first, start with our guide on whether headless WordPress with Next.js is right for your site.

What stays the same for you and what changes

For an owner, the most important thing is that the work in the admin does not change. You add products, change prices and stock and process orders in WooCommerce as before. What changes is the storefront and the way couriers, payments and other services are connected.

Part of the store	Classic WooCommerce	Headless store
Products, orders, customers	In WooCommerce	In WooCommerce
Admin	WordPress and WooCommerce	The same
Storefront for shoppers	WordPress theme	Next.js application
Econt and Speedy	The couriers' modules	Connected through the couriers' APIs
Cash on delivery	Built into WooCommerce	Offered in the storefront, the order goes into WooCommerce
Card payment	The provider's plugin	Agreed separately
A new feature for shoppers	Often a ready plugin	Programmed in the storefront

The last row is the difference you feel most from day to day. In a classic store many things are added by installing a plugin. In a headless store every change to what the shopper sees goes through a developer, so it is best to have the storefront's features written into the quote.

Start with the numbers of your current store

Before you compare options, collect a few numbers. They make the conversation with any developer more concrete, and the decision rests on facts.

Measure the home page, one category and one product in PageSpeed Insights on mobile. Run the test several times, because the result changes slightly from run to run.
Look in Google Analytics or your host's statistics to see how many visitors you have on an ordinary day and on the busiest day of your last campaign.
Check in your hosting panel whether the store has hit the CPU or memory limit during a campaign.
Count the products together with their variations, and the plugins that take part in the checkout.

If the store is fast and the server stays within its limits even during campaigns, classic WooCommerce is probably enough for you. Our guide on how to measure site speed with PageSpeed Insights explains how to read the result.

How big the catalogue is

The number of products alone rarely settles the question. A store with a small catalogue and simple products runs well on classic WooCommerce with a light theme, good hosting and a cache.

Things change when there are many products with variations in size and colour, and shoppers filter and search. Category pages with filters and search put load on the database with every visit that is not served from the cache. With a large catalogue, the cache rarely holds every page and every combination of filters.

In a headless store, product and category pages are prepared in advance and refreshed in the background, so the shopper gets a finished page without waiting for the database. Search and filters still need data at the moment the shopper uses them. How exactly they are built is a question worth asking whoever builds the store.

How many visitors you have and whether there are peaks

A cache solves a large part of the problem in classic WooCommerce, but not all of it. According to the WooCommerce documentation, the cart, the checkout and the customer's account must not be cached, because they show data specific to the current shopper. Those are exactly the pages that put the most load on the server during campaigns and sales, when many people shop at once.

A classic store usually runs on one server or hosting account with a fixed capacity. When traffic exceeds it, pages slow down or stop answering, and some shoppers leave halfway through the order.

A headless store handles peaks differently. The storefront is served from a cache. Kubernetes, a system that runs applications across several servers, starts more copies of the storefront when traffic grows and stops the extra ones when it falls. WooCommerce no longer serves every product view. In our model, orders go through a queue, so no order is lost even when WooCommerce does not answer at that moment.

If your store has steady, moderate traffic, you will hardly notice this difference. If you sell through campaigns, it matters in exactly the hours when you sell the most.

Which plugins take part in the checkout

This is the question that most often decides the price and the complexity. In Bulgarian stores the checkout usually goes through the Econt and Speedy modules, cash on delivery, card payment and the invoice fields.

In classic WooCommerce each module adds its own fields to the WooCommerce checkout page. How the couriers are set up this way is described in our guide to setting up Econt and Speedy shipping in WooCommerce. In a headless store the checkout page is part of the storefront and the modules do not change it, so everything has to be connected again.

Econt and Speedy. Both couriers publish APIs with lists of their offices and cities and with shipment services. The storefront uses them to show the office selection right in the checkout. This is part of our headless model.
Cash on delivery. It is built into WooCommerce and needs no connection to a bank. The shopper chooses it in the storefront, the order goes into WooCommerce as a cash on delivery order just as before, and the courier collects the money on delivery.
Card payment. The modules of banks and payment providers are made for the WooCommerce checkout page. In a headless checkout, card payment needs its own connection to the provider. If you need it, make sure it is agreed with whoever builds the store and written into the quote. Which card modules exist for a Bulgarian store is covered in our guide on cash on delivery and card payments in WooCommerce.
Invoices and other modules. Plugins that only work with the order in the admin usually keep working, as long as the storefront sends the data they need, such as the company name, its EIK registration number and the VAT number. Plugins that show something to the shopper are built again.

The more of these modules your checkout has, the more work there is on the storefront. Make a list before you ask for a quote.

The budget and who will look after the store

Classic WooCommerce is cheaper to build and easier to change. There is a wide choice of plugins and many developers for it, and a new feature can often be added with a ready module.

A headless store costs more, because two parts and the connection between them have to be built. The infrastructure usually costs more than a shared hosting account, too. The storefront and WooCommerce run in the cloud, in an account in your name, and Kubernetes adds capacity when it is needed. The actual price depends on the store and shows in the quote. What to ask for in it is covered in our guide with 10 questions for an online store quote.

Also think about who will look after the store. In classic WooCommerce the regular work is updating the plugins, the theme and WordPress and checking that the checkout works after every change. With headless, the Next.js application and its dependencies are added to that, so you need a team or partner who knows both sides. In both cases, without maintenance nobody checks for vulnerabilities every day or updates in time.

How the choice affects speed and SEO

Well-built classic WooCommerce can be fast too. The classic WordPress sites we build are handed over scoring above 90 in Google PageSpeed Insights, measured on mobile on the day of handover, given fast hosting and plugins we have tested. The difference shows with a large catalogue, many plugins and many visitors, when a classic store struggles to stay fast.

For headless stores we aim for 90+ for speed and 100 for SEO in PageSpeed Insights. The SEO score there is a set of technical checks, for example whether the page has a meta description, a valid canonical address and hreflang, and whether it answers with a successful status code. It does not measure rankings in Google.

Speed matters to Google itself. According to its documentation, Google's core ranking systems look to reward content that provides a good page experience, but Google always tries to show the most relevant content, even when the page experience is weaker. Good Core Web Vitals do not guarantee the top spots.

Moving to headless also carries a risk. The titles, meta descriptions, canonical addresses, structured data and sitemap that the SEO plugin used to print now have to come from the storefront. Every address that changes has to redirect to the new one with a 301. If any of this is missed, the store can lose visibility in Google, so make sure it is in the quote.

The rule of thumb

A small store that is just starting out does well on classic WooCommerce. The build is cheaper, changes are easier, and with a light theme and good hosting the store is fast. At the start it matters more to find out which products sell than to build a complex system.

A growing store with traffic and campaigns gains the most from headless. The more visitors and products it has, the more speed and stability count in the hours when it sells the most.

There is a middle way too. If you start with classic WooCommerce and the store grows later, moving to headless replaces only the storefront. Products, orders and customer accounts stay in WooCommerce, so you do not start from scratch. Our guide on how a headless rebuild of a WooCommerce store works walks through it step by step.

Checklist

You know how many products and variations the store has and how fast the catalogue grows.
You know how many visitors you have on an ordinary day and on the busiest day of a campaign.
You have a list of the plugins that take part in the checkout: couriers, payments, invoices and others.
If you need card payment, it is agreed in the quote.
You have measured the store in PageSpeed Insights on mobile on the home page, a category and a product.
You know who will look after the store after launch and what the maintenance includes.
If you are moving to headless, the quote includes the SEO data and redirects for the old addresses.

When you do not have to decide alone

If your store is small and fast, there is no need to change anything. If it is slow, first check whether the cause is something that can be fixed without a new storefront. The most common causes are covered in our guide on why a WooCommerce store is slow and how to fix it.

If the store is growing and the classic setup is no longer enough, the page on website and online store development describes our headless online store. For a store that is already running there is a rebuild on the same model, in which products, orders and customer accounts stay in WooCommerce and you run the store from the same admin.

Frequently asked questions

What is the difference between classic WooCommerce and a headless store?

In classic WooCommerce the store is part of WordPress, the theme shows the products, cart and checkout, and plugins add whatever is missing. In a headless store the storefront shoppers see is a separate Next.js application, while WooCommerce keeps the products, stock, orders and customers. In both options you work from the same WooCommerce admin.

Will my work in the admin change with a headless store?

No. You add products, change prices and stock and process orders in WooCommerce as before. What changes is the storefront and the way couriers, payments and other services are connected, and every new feature shoppers see goes through a developer.

Which option suits a small store that is just starting out?

A small store that is just starting out does well on classic WooCommerce. The build is cheaper, changes are easier, and with a light theme and good hosting the store is fast. If the store grows later, moving to headless replaces only the storefront, while products, orders and customer accounts stay in WooCommerce.

Does caching help classic WooCommerce during campaigns and sales?

It helps for many pages but not all of them. According to the WooCommerce documentation, the cart, checkout and customer account must not be cached because they show the current shopper's data, and those are exactly the pages that load the server most during campaigns. A classic store usually runs on one server or hosting account with fixed capacity, and when traffic exceeds it, pages slow down.

Do Econt, Speedy and cash on delivery work in a headless store?

Yes. Econt and Speedy publish APIs with lists of their offices and cities, and the storefront uses them to show office selection right in the checkout. Cash on delivery is built into WooCommerce, the shopper chooses it in the storefront and the order goes into WooCommerce as before. Card payment needs its own connection to the provider, so it is agreed separately and should be written into the quote.

Will my invoice plugins work in a headless store?

Plugins that only work with the order in the admin usually keep working, as long as the storefront sends the data they need, such as the company name, its EIK registration number and the VAT number. Plugins that show something to the shopper are built again in the storefront. The more such modules your checkout has, the more work the storefront takes, so make a list before you ask for a quote.

Is a headless store more expensive?

Yes. The build costs more because two parts and the connection between them have to be made, and cloud infrastructure usually costs more than a shared hosting account. Maintenance adds the Next.js application and its dependencies, so you need a team or partner who knows both sides. The actual price depends on the store and shows in the quote.

Can moving to headless hurt SEO?

It can, if something is missed. The titles, meta descriptions, canonical addresses, structured data and sitemap the SEO plugin used to print now have to come from the storefront, and every changed address has to redirect to the new one with a 301. Good Core Web Vitals do not guarantee the top spots either, because Google always tries to show the most relevant content.

Sources