WordPress Performance: Hosting and Infrastructure: Scaling for Growth

16 minute read WordPress Performance · Part 5

Infrastructure choices that directly affect WordPress speed and reliability: hosting types, PHP worker sizing, Redis, CDN edge caching, monitoring, backups, and scaling for traffic spikes.

Great code cannot fix bad infrastructure. If the server is underpowered, misconfigured, or missing the right cache layers, WordPress will feel slow no matter how much you “optimise the theme”.

This guide breaks down hosting and infrastructure decisions that actually move performance, reliability, and scalability.

Why Infrastructure Sets the Ceiling

Code quality determines efficiency. Infrastructure determines capacity.

Once traffic grows, performance issues usually come from:

  • PHP worker exhaustion
  • Database contention
  • Cache misses under load
  • Lack of observability

Good infrastructure keeps bad days boring.

Design Rationale and Trade-offs

Managed hosting trades control for consistency

Often a good deal for teams without ops focus.

PHP workers are the silent limiter

CPU can look fine while requests queue.

Scaling vertically is simpler than horizontally

Until it is not.

Practical Guardrails

  • Monitor workers, not just CPU
  • Test traffic spikes intentionally
  • Treat backups as recovery drills

Key Takeaways

  • Hosting choices are architectural
  • Observability is not optional
  • Reliability beats raw speed

The goal

  • predictable TTFB under load
  • enough concurrency for peak traffic
  • fast, reliable database performance
  • sane caching layers and purge rules
  • monitoring and recovery you trust

1. Choose the right hosting model

Shared hosting

Cheap, but unpredictable.

  • noisy neighbours
  • limited PHP workers
  • inconsistent caching
  • hard limits you only discover when you hit them

Shared hosting can work for hobby sites, but it is usually the wrong choice for a business site once traffic and plugin complexity grows.

Managed WordPress hosting

Often the best balance of ease and performance.

  • tuned stacks (PHP, NGINX, caching)
  • backups and staging built in
  • support that understands WordPress

The trade-off is less control and sometimes pricing that rises with traffic and storage.

VPS or cloud

Best when you need control and you can manage it.

  • choose your stack (NGINX, PHP-FPM, Redis)
  • tune database properly
  • manage costs and scale strategy

The trade-off is responsibility: security updates, monitoring, and reliable backups are now on you.

Custom or enterprise stack

For high-traffic or complex platforms.

  • multiple app nodes behind a load balancer
  • dedicated database layer
  • object cache cluster
  • CI/CD, observability, and strict security posture

Do not go here unless you have a clear need.

2. PHP workers and concurrency (the hidden bottleneck)

Every uncached request needs PHP workers. If you have too few, requests queue and TTFB spikes.

Common causes of worker exhaustion:

  • WooCommerce and logged-in traffic that bypasses page cache
  • slow database queries
  • slow remote API calls
  • heavy cron tasks running frequently
  • admin usage during peak traffic

Practical guidance

  • brochure sites can be fine with fewer workers if page caching is solid
  • WooCommerce needs more concurrency and careful bypass rules
  • if your host provides worker metrics, watch them during peak traffic and deployments

3. Caching layers should match your hosting

A good host makes caching easy. A poor host makes it fragile.

Minimum baseline:

  • full page cache for anonymous requests
  • OPcache enabled for PHP
  • CDN for static assets

If the site is dynamic (ACF heavy, membership, WooCommerce):

  • Redis object caching
  • targeted application caching (transients and wp_cache_*)
  • strong “do not cache” rules for account and transaction flows

Transients can use the database or object cache depending on your setup. cite

4. CDN and edge caching

A CDN reduces latency and protects your origin from spikes.

What to cache at the edge

  • images and media
  • CSS and JS
  • fonts
  • some HTML routes, only if safe and paired with correct bypass logic

If you use “cache everything” rules, you must bypass logged-in sessions and dynamic endpoints to avoid serving the wrong content. cite

5. Database: keep it close and keep it fast

The database is usually the first shared bottleneck.

Infrastructure considerations:

  • place the database close to the app server (low latency)
  • prefer dedicated resources over noisy shared DB
  • ensure InnoDB and sensible memory allocation
  • monitor slow queries and address root causes (indexes, autoload bloat, meta query patterns)

Also note: MySQL query cache is removed in MySQL 8.0, so plan caching above the DB. cite

6. Monitoring and observability

You cannot manage performance without visibility.

Basic monitoring

  • uptime monitoring (StatusCake or similar)
  • server metrics (CPU, RAM, disk I/O)
  • traffic spikes and bandwidth

Performance monitoring

  • New Relic APM (or your host equivalent)
  • slow query logs
  • real user monitoring if you care about geo performance

What to alert on

  • sustained high CPU or high load average
  • memory pressure and swap usage (a missing swap file can crash MySQL)
  • increased 5xx error rate
  • rising TTFB
  • database connections approaching limits

7. Backups and disaster recovery

Backups are not a feature, they are a plan.

Minimum expectations:

  • automated daily offsite backups
  • point-in-time restore if your business depends on the site
  • snapshots before updates or deployments
  • regular restore testing (this is what most people skip)

A backup you have never restored is not a backup you can trust.

8. Handling traffic spikes and scaling

If you are on managed hosting

Managed hosts often scale within limits, and may throttle beyond that. Know what “scaling” means for your plan.

Ask:

  • what happens when PHP workers are saturated?
  • do they auto-scale or queue requests?
  • do they block traffic or degrade gracefully?

If you are on VPS or cloud

Plan a simple scaling path:

  • better page caching and edge caching first
  • vertical scaling (more CPU and RAM) as the simplest next step
  • horizontal scaling (multiple app nodes) if you have sustained load

For serious spikes, aim to keep most requests off the origin via edge caching and a strong page cache.

Real-world setup

For a high-conversion WooCommerce project:

  • CDN and WAF at the edge to protect the origin
  • Redis object cache enabled
  • solid full page caching for non-commerce routes
  • monitoring for workers, database performance, and error rates
  • backups tied to deployments with quick rollback

FAQ

Is managed hosting always faster?

Not always, but it is often more consistent. Speed depends on the stack, cache configuration, worker limits, and how your site behaves under load.

What is the first infrastructure upgrade I should make?

Usually: move from shared hosting to a tuned managed host or a well-managed VPS, then add a proper page cache and CDN. After that, add Redis if the site is dynamic.

Do I need Kubernetes for WordPress?

Almost never. You need good caching, enough workers, and reliable database performance. Kubernetes is a tooling choice, not a performance strategy.

Need WordPress support? I provide maintenance and development for businesses across Cheshire. Learn more about my WordPress services or get in touch.