WooCommerce hosting: what a shop needs that a blog doesn't

A shop builds a different page for every visitor

A blog hands the same page to everybody. A shop builds a different page for every visitor, because everyone has a different basket, a different postcode and a different set of discounts.

It is also why shop trouble rarely looks like server trouble. The site is up and the product pages are quick. What you are actually dealing with is a basket that empties itself, an order confirmation that never arrived, or a checkout that stopped taking cards after an update. Those are all hosting requirements in disguise, and none of them shows up in a plan comparison.

Caching, and the pages it must never touch

Page caching is the biggest single speed win on any WordPress site. The server builds a page once, saves the finished HTML and hands that copy to the next thousand visitors without WordPress or the database being involved.

Do that to a checkout and you have a problem. The basket, checkout, account pages and order-received page belong to one visitor, so they have to be left out of the cache entirely. So does anyone logged in, and anyone with something in their basket. WooCommerce leaves cookies such as woocommerce_items_in_cart and its session cookie so a properly configured cache knows to stop serving a saved copy. A generic cache switched on across the whole site ignores them, and you get the symptoms every shop owner dreads:

• A customer adds something, refreshes, and the basket appears empty.
• Two people see the same basket, which is the version that produces an email nobody wants to read.
• Discounts or shipping totals show the wrong figure because the page was built for somebody else.
• The basket total in the header never updates.

That last one is usually cart fragments, a background request WooCommerce makes to keep the basket counter current. It cannot come from the page cache, and on a slow server it becomes the thing holding product pages back.

Object caching matters more to a shop than to a blog. Redis keeps the results of database queries in memory, and since the uncacheable pages do all the querying, this is where a busy checkout gets its speed back. Everything that slows an ordinary WordPress site down still applies on top.

The database stops being an archive

A blog's database is read constantly and written to a few times a week. A shop writes all day. Every basket update, session, stock change, order and status change is a write, and writes are the expensive part.

Older WooCommerce versions stored orders in the same tables as blog posts, which is why established shops end up with an enormous posts table full of things that are not posts. Newer versions use dedicated order tables, which is a real improvement, and moving an established shop over is a job to try on a copy first.

Other things grow where nobody looks. Expired transients pile up. The options table fills with settings loaded on every request whether they are needed or not. Sessions accumulate. None of it is dramatic alone, and all of it adds up until the shop is slow and nobody changed anything.

Then there is your own team. Searching orders, running a sales report or exporting for the accountant are heavy queries competing with customers for the same database. On a shared server with a hard cap on database connections, the busiest day of your year is exactly when someone in the office runs a report. Shops rarely hit a storage limit first. They hit a database limit.

Backups and updates need a way back

Lose a day on a blog and you lose a post you can rewrite. Lose a day on a shop and you have lost orders you were already paid for, addresses you were meant to ship to, and stock counts that no longer match the shelves.

That changes how restores work. Rolling the whole shop back to last night is the obvious move and often the wrong one, because it deletes today's orders along with today's problem. Files and database usually need restoring separately: put the code back to the version that worked and keep the live data. Your payment provider also keeps its own record of every transaction, which helps if the worst happens.

On a blog, a bad plugin update breaks a layout. On a shop it can break the checkout, and you find out when the orders stop and you assumed it was a quiet afternoon. The safe routine is simple:

1. Take a fresh backup of files and database immediately before updating.
2. Update WooCommerce and its payment and shipping extensions as a set, since add-ons are written against particular versions.
3. Run any database update step WooCommerce asks for, and never five minutes before a sale goes live.
4. Test the checkout straight afterwards: add to basket, apply a coupon, pick a shipping option, run a test payment and check the confirmation email arrives.
5. If anything misbehaves, roll back and fix it before customers notice.

That is how we run updates on our WooCommerce hosting, which sits on the same managed WordPress hosting underneath.

Capacity is counted in checkouts, and email counts too

Hosting plans advertise monthly visits. For a shop that number tells you very little, because cached product pages barely trouble the server while every checkout is real work. What decides it is how many people are doing something at once. Ten checkouts together on a December evening ask more of a server than a quiet month of browsing, which is why shops are worth sizing individually.

Then there is the email nobody thinks about. Order confirmations, dispatch notices and password resets are not marketing. If they land in spam, customers assume the order failed and ring you, or order again. WordPress sends them through the web server unless someone sets it up otherwise, and mail providers treat that as suspicious. Sending through an authenticated route, with the right SPF, DKIM and DMARC records on your domain, is a short job that saves a lot of grief.

How dijihost hosts WooCommerce shops

Ordinary WordPress sites on dijihost Complete Hosting cost £1 a day + VAT. A shop gets its own figure, because a ten-product shop and one taking hundreds of orders a day need different servers. There is no charge for the move, and we can move a shop without closing it.

After that, the plugin update that could take your checkout down is ours to run, with a fresh backup and a rollback ready, and daily off-site backups behind it. Ring 01623 650333 and walk us through an ordinary week for your shop, then the worst one you have had, because that is the week the server has to be built for. Or ask for a quote.

Related