Store owners usually blame the theme or a plugin when checkout slows down. Sometimes that’s right. More often the store has outgrown the hosting, and the symptoms show up in a predictable order.
- Cache hit rate collapses. Browsing is cached, so it looks fine. Then a sale drives shoppers into carts, and carts are per-person. Your cache hit rate drops, PHP workers fill up, and the queue starts.
- PHP workers max out. Shared and small VPS plans cap concurrent PHP processes. When every worker is busy calculating shipping, new shoppers wait or get a 503. If you’ve seen a 504 gateway timeout during a promotion, this is usually why.
- MySQL falls behind. Order writes, stock decrements, session rows and product queries compete for the same throttled database. Checkout is the step that fails, which is the worst place for it.
- Something external notices. Payment gateways and shipping APIs time out when your server is slow to respond, and the shopper sees a failed payment that was really a slow server.
| Shared or managed Woo plan | GigeNET dedicated server | |
|---|---|---|
| CPU at checkout | Shared with other tenants, or capped per plan | Every Intel Xeon core is yours |
| Database | Shared MySQL host, connection limits | Your own MySQL, tuned to your RAM |
| Traffic limit | Monthly visit tiers | No visit caps. 1 Gbps unmetered on the D-1541 Special; other builds come with a bandwidth allowance |
| Stack choice | Fixed by the host | Your choice of web server, PHP version, cache layer |
| Billing | Often annual, with overages | Month to month, $0 setup |
If your store is also a content site with logged-in members, the same logic applies and the WordPress dedicated server page covers the non-store side.