Note: I have spent more than twenty years inside WordPress infrastructure across several angles. I co-ran a small managed WordPress host called PressTitan, served as a Senior Technical Account Manager at Acquia, ran audits as part of Pressable’s audit program, and I am currently the systems team’s Lead PM at Fueled. The views here are my own, not those of any current or former employer.
I’ve noticed that two hosting companies can offer the same PHP version, the same Nginx config, the same Redis cache, and the same data center, but one of them makes your WooCommerce site feel fast and the other does not. Developers feel it. End users feel it. SEO tools measure it.
The difference is usually not obvious. It lives in two decisions most hosts do not put on a marketing page:
- What single-core CPU speed their servers actually run at.
- How close Redis actually is to PHP.
Both are real bottlenecks. Each one, on its own, can hold back a perfectly well-built dynamic WordPress site. Together they decide whether your checkout flow feels snappy or whether your customers are waiting on a spinner.
I came to those two conclusions by testing the same WordPress codebase across a variety of hosts. The two indicators that felt like they made the biggest practical difference were fast single-core CPU performance and whether Redis was present and connected locally. Plenty of hosts have tried other object caching approaches, or skipped object caching entirely. For WooCommerce in particular, those choices show up in the experience pretty quickly.
Single-core CPU speed is a bigger deal than core count
PHP is single-threaded per request. One PHP-FPM worker handles one HTTP request at a time. It reads the file, processes the template, runs the plugins, builds the output, all in serial.
When that worker is busy, it does not share the load across your other cores. It sits on the one core until it is done.
More cores let you handle more concurrent visitors. That is throughput. A faster single core makes every page faster for every visitor. That is latency. Both matter, and they solve different problems.
After decades of WordPress optimization, a typical dynamic request on a well-cached site still spends 50 to 150 milliseconds in PHP execution. Move from a 3.0 GHz chip to a 4.5 GHz chip, a 50% clock speed improvement, and you shave meaningful milliseconds off that execution time. PHP does not parallelize. Each instruction runs one after another, and a faster core finishes them sooner.
This is most visible on:
- WooCommerce stores. Cart, checkout, and account pages are dynamic by design. They cannot be page-cached the way logged-out pages can. Every hook, filter, and database call runs in sequence on every load.
- Membership and LMS sites. Access checks, enrollment lookups, content restrictions, all serial PHP.
- The admin. The WordPress admin is famously single-threaded. A faster core makes the edit screen load faster for every content editor.
Most hosting companies advertise core count. They almost never mention the specific CPU model or clock speed. There is a reason for that. Selling “4 cores” is easier than explaining that those 4 cores are on a 2.2 GHz chip from three generations ago.
What to ask: “What specific CPU model are my sites running on, and what is the clock speed?”
Redis proximity matters, not just Redis availability
Object caching is the single best performance investment for a dynamic WordPress site. Redis (or Memcached) stores database query results, transients, options, and post metadata in memory, which saves PHP from hitting MySQL dozens of times per page load.
“We have Redis” and “Redis is close to PHP” are two very different statements.
Redis is itself single-threaded. Every get(), set(), and delete() from PHP blocks until Redis responds. On a local Unix socket, that response takes about 0.1 to 0.5 milliseconds. Negligible on its own.
Multiply by 50 to 100 object cache calls per request, which is common on WooCommerce or any complex site, and you are looking at 5 to 50 milliseconds of total cache latency per page. That is still fine, until Redis is not on the same server.
Many managed hosts run Redis on a separate node. Maybe it is on a dedicated cache server, maybe it is in a cluster. Either way, PHP now makes a network hop, 1 to 3 milliseconds, for every single cache call. That 5 to 50 milliseconds becomes 50 to 300 milliseconds of pure waiting time per request.
(Yes, pipelining and persistent connections can amortize some of that hop cost. The default WordPress Redis object cache plugins do not pipeline meaningfully, so most real-world deployments pay close to the full per-call penalty.)
On a backend response budget of 200 to 500 milliseconds (after CDN), that is the difference between a checkout that feels instant and one that feels broken.
I have benchmarked this. The same site on a host with local-socket Redis compared to the same site on a host with network Redis, same theme, same plugins, same traffic, showed a measurable and consistent TTFB difference.
What to ask: “Is Redis running on the same server as my PHP, connected via Unix socket? Or is it on a separate node?”
Why Redis won, and what you are missing without it
If Redis is so important, why doesn’t every host just include it?
Some do. A lot of them rely on older or different caching approaches that look good on paper and do not solve the dynamic-content problem.
File-based page caching works beautifully for logged-out visitors. Nginx or Varnish stores the rendered HTML and serves it instantly. The moment someone logs in, adds something to a cart, or hits the admin, those caches are bypassed entirely. You get zero benefit on the dynamic pages where performance matters most to your actual users.
MySQL-stored transients are WordPress’s fallback. You enable object caching via a plugin, and without Redis or Memcached available, those cache values end up in the wp_options table. That table grows, autoloaded data accumulates, and the cache lookups become slower than just running the original query. I have seen wp_options tables with millions of expired transients bringing admin pages to a crawl, and the fix was enabling Redis, not deleting transients.
PHP-based object caches like APCu or shared memory backends are fast but ephemeral. Populated on one request, gone on the next server restart, or invisible to other PHP workers. They work for single-server toy setups and fail at any scale with multiple web nodes.
There are also hosts running newer or in-house caching layers that try to be clever about this, sometimes sitting between PHP and MySQL, sometimes living inside the web server. Some of those are interesting on benchmark pages and well-behaved on logged-out traffic. For WooCommerce specifically, where almost every page that matters is dynamic and authenticated, they have not, in my testing, held up the way a properly configured Redis does.
Redis wins because it sits at the intersection of three things:
- It is an object cache. It stores query results, transients, and options across requests, so PHP never needs to recalculate them.
- It is persistent. Restart your PHP workers or your web server, and the cache is still warm.
- It is networked. Multiple web servers can share the same Redis instance, which makes it viable for multi-node architectures.
The other approaches solve one or two of those. Redis solves all three.
Here is the catch: a surprising number of managed WordPress hosts still do not include Redis in their stack. They offer page caching. They offer CDN. They offer automatic plugin updates. There is no Redis socket, and no way to enable persistent object caching. If you try to plug one in, your cache hits go to MySQL tables or fail silently.
That gap is one no amount of page cache optimization can fill. On a WooCommerce store, the entire customer-facing flow (cart, checkout, account, my-orders) lives outside the page cache. Whatever object cache you have, or do not have, is what decides how fast those pages feel. Hosts that lean on page caching alone, or on alternative object caching approaches that do not survive a restart or scale across nodes, end up with a fast brochure site bolted to a slow store.
What to ask: “Does your standard stack include Redis or Memcached for persistent object caching, not just page caching?”
When the two bottlenecks compound
These two problems do not just add up. They reinforce each other.
A slow core means PHP takes longer to execute. Distant or missing Redis means each of the 50+ cache calls per request takes longer, or skips the cache and hits the database directly. The slow PHP runtime now has to wait for slow cache responses, multiplied by every dynamic page load, multiplied by every concurrent visitor. The compounding is worst exactly where it hurts most: WooCommerce checkout, the admin under content editing load, REST endpoints serving a logged-in mobile app.
Fix one and you get a meaningful improvement. Fix both and you cut the critical path of every dynamic page by a significant margin.
None of this replaces the basics. A good page cache, a CDN, image optimization, a modern PHP version, proper database indexing. Those are table stakes.
For the moments when the page cache misses, and on dynamic WordPress sites that is far more often than most people realize, your low-level infrastructure choices determine the experience.
What to ask your host
A short checklist for your next hosting conversation or migration evaluation:
- CPU model and clock speed. Determines per-request PHP execution speed. Marketing pages rarely tell you, so ask.
- Where Redis sits relative to PHP. Same server or separate node? Decides per-call cache latency.
- Unix socket or TCP connection. Socket is roughly 10x faster per call.
- Redis INFO p50 and p99 latency. Reveals whether Redis is overloaded or distant.
- Shared CPU cores with neighbors. Affects whether the advertised GHz is actually available to your site.
- Redis (or Memcached) in the standard stack, not just page caching. Many hosts offer page cache without object cache. You want both.
The bottom line
WordPress performance at the infrastructure level is not about checking boxes. It is about understanding which details actually affect the request lifecycle for the kind of traffic your site sees.
For anonymous, cacheable traffic, CDN and page cache dominate. That problem is mostly solved.
For dynamic traffic, WooCommerce checkout, logged-in members, the admin, and authenticated REST calls, the bottlenecks shift. Single-core CPU speed and Redis proximity become the difference between a site that feels fast and one that feels heavy. On a WooCommerce store specifically, where almost nothing that matters can be page-cached, these two decisions can shape your conversion numbers without anyone in the room understanding why.
The best hosts know this. The best developers ask about it.
