WooCommerce Hosting: Shared vs Cloud VPS for Traffic Spikes

The two pages you can’t cache

Your store is fast when you test it. You run PageSpeed on the homepage, get a good score, and move on.

Then you send a campaign, or a post takes off, or Black Friday arrives, and the tickets start landing. “I tried to check out three times.” Someone sends a screenshot of a spinner. Meanwhile your homepage is still loading in under a second, which makes the whole thing feel like a lie.

It isn’t a lie. It’s just how WooCommerce works.

Product pages, category pages, and your blog can be saved as finished HTML and handed to visitors without your server doing any thinking. Cart, checkout, and My Account cannot. They’re excluded from caching deliberately, because a cached cart would show one shopper somebody else’s items, and a cached checkout would be a data breach with a “Place order” button.

So every add-to-cart, every coupon check, every shipping recalculation, every order that gets written down is built from scratch. PHP runs, the database gets read and written, and someone waits.

The pages that make you money are the ones your cache can’t help with. Everything below follows from that.

What “heavier than a blog” actually means

A blog post asks your server for one thing: give me this article. Cached, that’s barely a file lookup.

An order asks for a dozen things in sequence. Check stock. Recalculate tax for that address. Validate the coupon. Look up shipping rates. Write the order row, then the order items. Update inventory. Fire the confirmation email. Notify whatever plugin syncs to your accounting software.

That sequence runs inside its own slice of PHP memory, and it’s not a small slice. A lean blog request might use 40 MB. A checkout on a store with a page builder, a filter plugin and a shipping calculator can use 200 MB or more. Ten shoppers at once and you’ve asked for 2 GB before the database gets a look in.

Most of that work is writing rather than reading, too, which is the slow direction on any disk. Orders, stock counts, session data. It’s the unglamorous reason storage type keeps showing up in hosting comparisons: NVMe drives handle a lot of small simultaneous writes far better than the SATA SSDs plenty of budget hosting still runs on. We went through the numbers in why NVMe matters.

Then there’s the ceiling nobody puts on a signup page. Your account can only build so many pages at the same time. Requests past that number wait in line, and if they wait long enough the visitor gets a 504, which a shopper reads as “this store is broken.”

Notice that monthly page views appear nowhere in that list. Four people buying at a leisurely pace is easy, while three hundred arriving in the ten minutes after an email lands is hard, even if both stores end the month on the same total.

Where shared hosting actually breaks

The usual version of this argument blames your neighbours. Somebody else’s traffic spike drains the server and drags you down with it.

On genuinely oversold hosting, sure. On any competent modern platform it’s mostly solved. Our shared plans run CloudLinux, which fences each account into its own resource allocation, so the site next door hitting its ceiling stays the site next door’s problem. Same LiteSpeed web server, same NVMe storage as the higher tiers.

The real limit is quieter, and it’s about you rather than your neighbours. The fence works in both directions.

Your account gets a defined slice of CPU, memory and simultaneous processes. That slice is generous for a website. For twenty people checking out in the same second, it’s a queue. And because carts and checkouts can’t be cached, a burst of shoppers turns straight into a burst of uncacheable work with nothing to absorb it.

Those limits aren’t a secret, either. They’re written down in our CloudLinux resource limits guide, along with how to see which one you’re actually hitting. Worth ten minutes before you conclude you need a bigger server.

A typical case: a store with 5,000 products and a decent cache setup serves category pages all day without breaking stride. Then a newsletter goes out. Two hundred people arrive over six minutes, eighty add something to the cart, thirty start checking out. The cacheable traffic is fine. The thirty checkouts stack up behind the process ceiling, each one waiting on the ones ahead. Requests that would normally take 400 milliseconds take nine seconds. Some of those people leave.

Nothing actually went wrong, and no neighbour misbehaved. The plan did exactly what it says it does. It just wasn’t sized for thirty simultaneous uncacheable requests, and nothing at signup told you that was the number to watch.

Shared hosting is still right for a lot of stores

We sell both, so take this as it’s meant: most stores don’t need to move.

You’re fine on shared if:

• Your peak is a handful of people in the cart at once, not dozens
• You’re under roughly 30,000 monthly page views with reasonably even traffic
• You’re not running paid ads that dump traffic in bursts
• Your plugin list is short and your theme isn’t a page builder with a store bolted on
• You’ve never had a “site was slow during a sale” complaint you couldn’t explain

If that’s your store, put the money into product photography or ads instead. Upgrading hosting that isn’t the bottleneck buys you a faster version of a problem you don’t have.

The full shared vs VPS decision framework covers the general case. What follows is the store-specific part.

What a Cloud VPS changes for a store

A VPS gives you CPU cores, RAM and NVMe storage that are yours, and enough of them that thirty simultaneous checkouts is a Tuesday rather than an event. Four things change in practice.

The queue takes far longer to form

More memory and more simultaneous processes means the burst that used to stack up just gets served. This is the whole point, and the only one of the four that touches revenue directly.

Your admin stops fighting your customers

On shared, bulk-editing 400 products or running an inventory sync competes with shoppers for the same slice. A VPS has room for both. That matters more than people expect during a sale, because a sale is exactly when you’re also in the admin, watching orders come in and fixing the stock count you got wrong.

Caching gets smarter, not just bigger

LiteSpeed with LSCache serves product and category pages as static HTML straight from the web server, while knowing to leave cart, checkout and My Account dynamic. You can add object caching on top so repeated database lookups stop being repeated. Our WordPress speed playbook covers the thinking, and the LiteSpeed Cache setup guide covers the clicking.

You can roll back

Snapshots turn a plugin update that breaks the checkout into a five-minute problem instead of a two-hour one. For a store, how fast you can undo something is a performance number like any other.

One thing doesn’t change: pages already served from cache. If your product pages are quick today, they’ll be quick tomorrow. Anyone promising a VPS will transform your cached homepage is selling you something.

Side by side

	Shared hosting	Cloud VPS
CPU and RAM	Fixed slice, fenced by CloudLinux	Dedicated cores and memory, yours alone
Simultaneous checkouts	Fine at low numbers, queues under burst	Handles bursts without queueing
Storage	NVMe on our plans, SATA SSD on many budget hosts	NVMe
Cached product pages	Fast	Fast, no real difference
Cart and checkout under load	The weak point	The reason to upgrade
Isolation from neighbours	Good, CloudLinux enforces it	Complete, separate environment
Recovery from a bad update	Restore from daily backup	Snapshot rollback in minutes
Server admin	None, it’s managed	None on a managed plan, all of it on self-managed

Two of those rows are ties. If a comparison table you’re reading has the cheap option losing every single line, somebody wrote it to sell you the expensive one.

Doing the arithmetic on one bad Friday

The “cheap hosting costs more” argument usually turns up without any numbers attached, so we’ll attach some. Swap in your own.

Say your store does $40,000 in November, and Black Friday weekend is 15% of that, around $6,000, most of it squeezed into a few evening hours. Say the checkout crawls for two hours during the Friday peak and roughly a third of the people who would have bought give up.

Call it $600 to $900 gone. Then add the ad spend that kept running into a broken checkout, the support replies, and the shoppers who now quietly believe your store is unreliable.

The gap between a shared plan and a managed Cloud VPS runs roughly $50 to $80 a month depending on which control panel you pick. At the low end that’s $600 a year.

So one bad Friday evening costs about what a whole year of headroom costs. If your store never has a Friday evening like that, keep the $600.

Which side of the line is your store on

Check the ones that are true right now.

• More than about 20 people are in the cart or checkout at the same moment during peaks
• I run paid ads or send campaigns that land traffic in bursts
• Checkout has been noticeably slower than the rest of the site during a sale
• I’ve seen a 504 or a timeout on the store, ever
• Working in wp-admin slows the front end down
• My catalogue is over a few thousand products, or I use faceted product filters
• A bad plugin update would cost me real money per hour of downtime
• My next planned event is bigger than my last one

Three or more, and you’re already paying for the headroom in lost orders rather than in hosting. That’s the more expensive way to pay for it.

One or two: fix that specific thing. Nine times out of ten it’s caching configuration or one heavy plugin, not the server.

None: your hosting isn’t your problem. Go and sell things.

Moving a live store without losing orders

What keeps store owners on a plan they’ve outgrown usually isn’t the price of the next one. It’s the quiet fear of losing order history, or dropping somebody’s order halfway through the transfer. It’s a fair fear, and getting the sequence right is what removes it.

1. The store is copied to the new server, database and media included, and tested on a preview URL while the old store keeps trading.
2. You check the parts nobody else can check for you: a live test order, the payment gateway callback, tax and shipping rates, and any plugin holding an API key or licence.
3. DNS TTL comes down the day before, and the switchover happens in your quietest window. Look at your own analytics for that instead of guessing.
4. Orders placed on the old server during the switchover get reconciled across. Careless migrations skip this step, and it’s the reason the window should be quiet.
5. The old plan stays alive for a week afterwards, which is cheap insurance.

Our migration team does this for free, reconciliation included, and it’s the same process described in our zero-downtime WordPress migration guide. If you’d rather do it yourself, work off the website migration checklist and keep the order above.

The short version

Your product pages are a caching problem, which caching solves cheaply. The checkout is a capacity problem, and nothing but more capacity will fix it.

If your peaks are modest, shared hosting is the right answer and we’ll happily sell you that instead. If your peaks are the few hours your year turns on, then you’re going to buy the headroom either way. The only question is whether you buy it in advance or discover the price of it mid-sale.

Not sure which one you are? Tell us what your store looks like, including traffic pattern, catalogue size and plugin list, and we’ll point you at the smallest plan that won’t bottleneck your checkout. Nobody here is paid more for putting you on a bigger one. Or read what current customers say before you talk to us at all.

Frequently asked questions

Can WooCommerce run on shared hosting?

Yes, and plenty of profitable stores do. Shared hosting handles a store fine as long as your simultaneous checkout traffic stays low. The number that matters is how many people are in the cart at the same moment, not how many visit in a month. Under roughly 20 to 30 at once, a good shared plan copes. Above that, requests start queueing behind each other.

Why does my WooCommerce checkout get slow when the rest of the site is fast?

Because the rest of the site is being served from cache and the checkout isn’t. Product and category pages can be saved as finished HTML and handed out instantly. Cart, checkout, and My Account are excluded from caching on purpose, since a cached cart would show one shopper another shopper’s items. Every checkout request is built from scratch by PHP and the database, which is why a page speed score on your homepage tells you almost nothing about your checkout.

Does a Cloud VPS make my WooCommerce store faster?

It makes the uncacheable parts faster and much steadier under load. Product pages that already come out of cache won’t change much. Cart, checkout, coupon validation, and the admin order screens are where you see the difference, because those need CPU and database speed that nobody else can claim. If your complaint is “slow during sales” rather than “slow all the time,” a VPS is aimed at your problem.

How many products before I need a VPS?

Product count matters less than plugin weight and how many shoppers overlap. A 10,000-product catalogue with clean code and good caching can be comfortable on shared. A 300-product store with a page builder, faceted filters, a currency switcher, and a live inventory sync can struggle. Rough line: past a few thousand products with filtering, the database work per page stops being trivial.

How much traffic can a WooCommerce store handle on shared hosting?

Think in concurrent shoppers rather than monthly visits. A store selling steadily to a handful of people at a time is comfortable on shared. A store that emails 20,000 subscribers and puts 300 people on the site in ten minutes is not, because those arrivals overlap and the uncacheable requests queue up. Same monthly total, completely different demand on the server.

Will moving my WooCommerce store to a new host lose my orders?

It shouldn’t, if the move is sequenced properly. The store is copied and tested on the new server while the old one keeps taking orders, then the domain is switched during a quiet window and any orders placed in the gap are reconciled. The danger isn’t the technology, it’s copying the database at a busy moment, or forgetting to test the payment gateway callback on the new server.

Is LiteSpeed better than Apache for WooCommerce?

For the cacheable half of your store, meaningfully so. LSCache serves product and category pages as static HTML from the web server itself and knows to leave cart, checkout, and My Account alone. For the uncacheable half, the web server matters less than your CPU, RAM, and disk speed, which is the part shared hosting can’t guarantee you. Both halves are worth having, and they’re separate wins.

---

Ready to give your checkout room to breathe? Our e-commerce hosting plans run LiteSpeed with LSCache, NVMe Gen 4 storage and daily backups, with free migration and a 45-day money-back guarantee. Or start with the general shared vs VPS framework if you’re weighing this up for a site that isn’t a store.