WooCommerce Performance: The Hosting Tier Decision Tree

Every WooCommerce store has a hosting ceiling it does not know about until the day it slams into it. Usually that day is a launch, a Meta ad that actually worked, or a press mention. The checkout starts timing out, admin-ajax goes to sleep, and the host support ticket comes back with a sentence about a rogue plugin. The plugin is not rogue. The store has outgrown its tier.

After migrating more than 250 WooCommerce stores across shared, VPS, managed WordPress, and dedicated cloud infrastructure, the team at WitsCode has a firm view on where the real boundaries sit. This is a decision tree grounded in real numbers from real migrations, not marketing sheet comparisons, and it ends with the signals that mean you are ready to move up.

What Actually Determines a WooCommerce Hosting Tier

Before the tier names, understand the four variables that decide whether a host can carry a store. The first is time to first byte on an uncacheable request, which for WooCommerce always means the cart, checkout, and my-account routes. Cached home pages are a vanity metric. The second is PHP worker count, because every concurrent checkout consumes one worker until the response flushes, and a two-worker plan can mathematically never serve more than two simultaneous checkouts regardless of how fast the CPU is. The third is the MySQL configuration, specifically whether the database lives on a shared multi-tenant instance or on dedicated resources, because WooCommerce hammers wp_options, wp_postmeta, and the sessions table on every transaction. The fourth is disk IOPS, which almost no host publishes and which quietly caps throughput once wp_postmeta crosses a few million rows.

Hold those four in mind as we walk the tiers. Price is almost incidental. The architecture is what you are buying.

Tier One: Shared Hosting and Why WooCommerce Punishes It

Shared hosting is where most WooCommerce stores begin and where the largest number of them remain stranded. SiteGround StartUp runs around 2.99 dollars per month on promotional pricing and renews near 17.99, Bluehost Online Store sits at roughly 9.95 promotional and 29.99 renewal, and Hostinger Business floats around 3.99 promotional. On paper the specifications are appealing. In practice, a single CPU core is shared with up to two hundred neighbour sites, PHP workers are capped at one or two per account, and the MySQL server is a single multi-tenant instance that can be crushed by any one tenant running a bad query.

The TTFB floor on shared hosting for a WooCommerce checkout request sits between eight hundred milliseconds and one point six seconds once the catalogue grows past a few hundred SKUs, and no cache plugin moves that number because checkout is uncacheable by definition. The PHP worker ceiling of two means that with an average checkout render time of one point two seconds, the theoretical maximum is roughly one hundred checkouts per minute, but queueing effects drop the realistic ceiling to around forty orders per minute for short bursts and somewhere between thirty and eighty orders per day sustained before the host starts throttling or the MySQL contention produces visible failures.

Shared hosting works for a brand new store doing under thirty orders a day with a small catalogue. Beyond that, the ratio of revenue lost to slow checkouts quickly exceeds the entire hosting bill.

The second hidden failure mode on shared hosting is the autoload table. WooCommerce and its extensions write settings to wp_options with autoload set to yes, which means every single page request loads the entire autoload payload into memory before any logic runs. On a store that has installed and removed twenty plugins over eighteen months, the autoload row count can cross fifteen thousand and the payload can cross four megabytes. On a shared MySQL instance under contention, that single query can take four hundred milliseconds on its own, before WordPress has even decided which template to render. No caching plugin touches this path. The only fix is a database audit or a tier move, and on shared hosting a database audit buys you months at best before the problem returns.

Tier Two: VPS for the Technically Confident

The jump to a virtual private server is the largest single performance step most stores will ever make, and also the one with the largest hidden cost in time. A DigitalOcean four gigabyte droplet with two dedicated vCPUs runs 24 dollars a month. Hetzner CPX31 delivers four AMD EPYC vCPUs and eight gigabytes of RAM for roughly sixteen dollars a month and is the best pure price-to-performance option available in 2026. Linode four gigabyte sits at 24 dollars and matches DigitalOcean closely.

On a properly tuned VPS with Nginx or OpenLiteSpeed, PHP-FPM set to six to twelve workers via pm.max_children, Redis for object cache, and MariaDB tuned for the InnoDB buffer pool, TTFB on cached pages drops to one hundred eighty to three hundred fifty milliseconds and uncached checkout sits between four hundred and seven hundred milliseconds. Realistic sustained capacity moves into the five hundred to two thousand orders per day range depending on catalogue size and plugin load.

The catch is the word properly. A VPS is a blank Linux box. The store owner or their agency is responsible for the webserver stack, PHP version upgrades, kernel patching, firewall rules, fail2ban, TLS renewal, database backups, off-site backup rotation, and staging environments. A single kernel CVE becomes an emergency patching night. Most store owners underestimate this cost until the first time something breaks at two in the morning. A VPS is the correct answer when you have an in-house developer or a retained agency. It is the wrong answer when you want to never think about infrastructure again.

Tier Three: Managed WordPress and the Disk IOPS Secret

Managed WordPress hosting exists because the sysadmin burden of a VPS is real, and stores will pay a premium to make it go away. This tier has fragmented into five meaningful players and one modern outlier.

Kinsta sits at the quality end. The Pro plan at roughly one hundred fifteen dollars a month and the Business One plan at two hundred twenty-five run on Google Cloud C2 compute-optimised machines, with four PHP workers at Pro and eight at Business. Kinsta tunes the stack seriously, publishes clear per-site dashboards, and handles CDN and backup without extras. WP Engine Startup at twenty-five dollars through Growth at one hundred sixteen is visits-metered with overage billing that can surprise you on a viral day. Pressable, owned by Automattic, ranges from forty-five to one hundred sixty-five and runs on what is essentially a stripped-down WordPress.com VIP infrastructure with generous performance per dollar. Cloudways acts as a thin management layer over DigitalOcean, Vultr, AWS, or GCP droplets for fourteen to one hundred dollars or more, and the tuning depth is noticeably lighter than Kinsta.

The outlier is Rocket.net. At thirty dollars a month the Starter plan bundles OpenLiteSpeed with LSCache, Cloudflare Enterprise including Argo, Tiered Cache, and Bot Fight Mode, and Object Cache Pro licensed and configured by default. This stack replicates what you would pay roughly four hundred dollars a month to assemble from Kinsta plus Cloudflare Enterprise plus a separate Object Cache Pro licence. For a WooCommerce store between one hundred and one thousand orders a day, this is the modern sweet spot and it is not close. The combination of OpenLiteSpeed serving static assets, LSCache holding the uncached route intelligently, Cloudflare Enterprise routing and protecting the origin, and Object Cache Pro offloading database reads produces TTFB numbers in the one hundred twenty to three hundred millisecond range on cached pages and three hundred to six hundred on checkout, which is legitimately competitive with self-managed AWS.

The secret that almost no managed WordPress provider discloses prominently is disk IOPS throttling. Kinsta enforces a sustained IOPS ceiling around three thousand on its Pro tier. WP Engine applies soft caps and an inode limit around five hundred thousand that larger stores hit without warning. When wp_postmeta grows past a few million rows and you start running dynamic catalogue queries or bulk order exports, these IOPS caps produce slowness that support teams will confidently attribute to a plugin. It is not a plugin. It is the disk. Ask any managed host for their sustained IOPS number before you sign. If they will not give you one, assume it is low.

Realistic order capacity in this tier ranges from one thousand orders per day on entry managed plans to roughly ten thousand on the upper tiers, and it is bounded far more often by PHP worker count than by CPU.

Tier Four: Dedicated Servers and Cloud for Stores That Have Earned It

The top tier splits into two shapes. Traditional dedicated servers from Liquid Web or similar run between one hundred ninety-nine and four hundred ninety-nine dollars a month and give you a single-tenant physical box with generous resources. Cloud infrastructure on AWS EC2 with m7i.large or c7i.xlarge instances paired with RDS Aurora MySQL lands realistically between two hundred fifty and twelve hundred dollars a month once you include data transfer and egress, and similar ranges apply on Google Cloud N2 with Cloud SQL. True enterprise managed WordPress from Pagely or WordPress VIP starts at two thousand and climbs past twenty-five thousand a month, and at those prices you are buying staff time and SLA, not just infrastructure.

The performance floor here is only meaningful when the stack is tuned end to end. TTFB on cached pages can reach eighty to two hundred milliseconds and uncached checkout can sit between two hundred and four hundred fifty milliseconds. Horizontally scaled architectures with an application load balancer, multiple EC2 nodes behind it, an ElastiCache Redis cluster, and Aurora with read replicas can serve twenty-five thousand to over two hundred thousand orders per day.

This tier is only rational when you have either a dedicated DevOps hire or a permanent agency retainer. A dedicated server run by someone who does not know what InnoDB buffer pool size to set is slower than a well-tuned VPS at a tenth of the price.

How to Know You Have Outgrown Your Current Host

The signals are concrete and measurable. Admin-ajax.php response time at the ninety-fifth percentile climbing above one point two seconds is a queueing indicator. Checkout TTFB above eight hundred milliseconds at median traffic is a database indicator. Lock contention errors in the wp-cron log and a wp_options autoload table exceeding three megabytes both point to a database under pressure that a bigger box will not permanently solve but will at least extend. Any 503 during a flash sale is a PHP worker exhaustion event and means your current worker count is below your burst demand. Backup windows exceeding two hours, or slow query log entries above one hundred per day, are both disk and database capacity warnings.

If three or more of those appear in a single week of normal trading, you are not optimising your way out. You are buying a bigger tier or you are leaving revenue on the floor.

What Upgrading Actually Buys You

Honest numbers from real migrations. Moving from shared to a tuned VPS produces a three to five times speed improvement on uncached routes and roughly ten times the order capacity, for an additional fifteen to twenty-five dollars a month, with the significant caveat of new sysadmin responsibility. Moving from shared to managed WordPress produces a two to four times speed gain with five to twenty times the capacity, costs an extra twenty to two hundred dollars a month, and eliminates the sysadmin burden entirely. Moving from a well-tuned VPS to managed WordPress is usually lateral in raw speed, and the real gains are SLA, support response time, automated backups, and the end of weekend patching. Moving from the top of managed into dedicated or cloud only makes sense when you have verified that the PHP worker cap at your highest available managed plan is the binding constraint, which for most stores never happens.

Where WitsCode Fits

WitsCode runs WooCommerce hosting migrations as a fixed-scope engagement, with more than two hundred and fifty completed across every tier discussed above. A typical migration uses DNS pre-warm with a reduced TTL two days ahead, a Percona XtraBackup or mysqldump snapshot, a delta sync window under ten minutes to capture orders placed during migration, and a cutover executed in the store's lowest-traffic hour. The outcome is a tier upgrade with zero downtime, no lost orders, and a post-migration tuning pass that actually uses the resources you just paid for.

If your store is hitting the signals above, or you suspect it is about to, talk to WitsCode. The decision tree ends with a tier recommendation backed by your real numbers, and the migration that follows is a Tuesday afternoon, not a crisis.