WordPress Hosting

Hosting sets an important performance floor beneath a WordPress site: caching and front-end optimization can reduce work, but they cannot fully compensate for an origin that lacks the resources required for important uncached requests. This hub covers how to evaluate hosting architecture, understand what a plan actually includes, and separate a hosting limitation from an application-level problem before spending money or effort in the wrong place.

Shared, VPS, cloud, and managed WordPress hosting
These category labels describe general infrastructure and service approaches, not standardized guarantees. Shared hosting pools resources across multiple sites on one server; a VPS provides dedicated virtual resources on shared physical hardware; cloud hosting draws from a distributed, often auto-scaling resource pool; and managed WordPress hosting layers WordPress-specific configuration and support on top of any of these underlying infrastructure types. Two providers using the same category label can offer meaningfully different actual resources.

PHP and server performance
PHP version, configuration, and the number of available PHP workers (concurrent request-handling processes) directly affect how quickly a page can be generated and how well a site handles simultaneous traffic. A limited PHP worker count can cause slowdowns specifically during traffic spikes even when average performance seems fine.

CPU, memory, storage, network, and database resources
Beyond PHP workers, the underlying CPU allocation, available memory, storage type (SSD versus older spinning disks), network capacity, and database resources all set limits on how a site performs, independent of any WordPress-level setting. A well-configured cache can reduce how often these resources are taxed, but it can’t manufacture resources a plan doesn’t actually provide.

Server location
The physical distance between a server and its visitors adds network latency that no amount of application-level optimization can remove. A site with a geographically concentrated audience benefits from hosting located near that audience, or from a CDN serving cached content from closer edge locations.

How caching and CDN use relate to hosting
Effective page caching can make a modest hosting plan perform well by avoiding repeated PHP and database work; a CDN can reduce network latency for cacheable content served from locations closer to visitors. Neither compensates for a genuinely under-resourced server handling uncached, dynamic requests.

Test cacheable and dynamic requests separately
A public article served from full-page cache may respond quickly even while logged-in dashboards, search, checkout, API requests, or other personalized pages remain slow. Test both the cacheable path and the important uncached path that represents the site’s real workload. Record response headers and user state so that a cache HIT is not compared with a cache MISS and mistaken for a hosting improvement. For dynamic sites, concurrency and PHP-worker pressure may matter more than a single quiet test of a cached page.

Hosting limitations versus application problems
A slow Time to First Byte on uncached requests points to origin-side work, but that work may involve hosting limits, PHP execution, database queries, a plugin, an external API, or a combination of factors. A slowdown concentrated after the document arrives may instead be browser-side. Distinguishing these layers before acting prevents a costly migration when the real cause is application code, and prevents endless plugin tuning when the server is genuinely constrained.

Questions to ask before changing hosting
Ask about specific PHP worker allocation for the exact plan being considered, not just the category name; whether a persistent object cache backend such as Redis or Memcached is available; what resource limits or fair-use policies apply and what happens when they’re reached; where data centers are located relative to your audience; and what updates, backups, and security monitoring are included by default versus left entirely to the site owner.

Recommended reading path
Start with WordPress Hosting, PHP Version, and the Server Performance Floor to understand the underlying resource concepts, then Shared, VPS, Cloud, or Managed WordPress Hosting to compare categories against your specific traffic and budget. Confirm a suspected hosting bottleneck using the baseline method in How to Measure WordPress Speed Before Making Any Changes before committing to a migration.

Related categories
Hosting decisions interact closely with caching and front-end performance, covered in WordPress Speed, and with the diagnostic tools covered in Tools & Experiments, which can help confirm whether a slowdown genuinely originates at the hosting level.

A note on scope
This category currently includes two published guides, covering the underlying performance floor and a comparison of common hosting categories. Neither ranks or recommends a specific hosting company; guidance focuses on the underlying categories, resources, and trade-offs a reader should evaluate for their own specific situation, budget, and technical comfort.