What Is WordPress Hosting? Server Stack, Caching Architecture, and How to Choose
Disclosure: some hosting links on this page earn me a commission if you buy. Pricing and benchmark data are verified independently. Full disclosure.
"WordPress hosting" means nothing. A $2/month shared plan and a $200/month managed platform both call themselves WordPress hosting. The actual question is: what does your WordPress site need from a server to perform reliably under real visitor load, and which hosting tier actually provides it? That question has a specific, infrastructure-level answer — and this guide gives it to you without hedging.
WordPress 6.5 runs on any host with PHP 8.x and MySQL 5.7+. That is the minimum bar. The interesting question is what happens at 20, 50, or 200 concurrent visitors — and that answer depends on PHP worker count, Redis availability, OPcache configuration, and MySQL isolation. I tested all four tiers in Q1 2026 with the same WordPress install across 5 global locations to give you the numbers that matter.
What WordPress Actually Needs From a Server (Most Hosts Give You Only Half)
WordPress is a PHP application. It runs PHP, queries MySQL, writes files to disk, and sends HTML over the network. The minimum requirements — PHP 7.4+ and MySQL 5.7+ — are met by literally every hosting provider on the market. The gap between a slow WordPress site and a fast one is almost never about meeting the minimum. It is about how much of the server's performance stack is correctly configured for how WordPress runs.
WordPress makes 30 to 80 MySQL queries per page load. Those queries retrieve post content, post metadata, user data, theme settings, plugin settings, menus, and widgets. Each query either hits the MySQL database and waits for a disk read, or hits a memory cache and returns in under 1ms. Whether your hosting environment provides that memory cache — and how large it is — is the primary variable separating fast WordPress from slow WordPress. It is also the variable most hosting comparison guides never mention.
The six server-level requirements for fast WordPress
PHP 8.3 executes WordPress 15% faster than PHP 8.1. OPcache stores compiled PHP bytecode in memory, eliminating 200 to 400 file compilations per page load. The default opcache.memory_consumption=128 fills up on a WordPress site with 20+ plugins. Set it to 256MB. Set opcache.max_accelerated_files=20000. These two changes cost nothing and reduce PHP execution time by 40 to 60%.
MySQL 8.0 executes WordPress queries 20 to 35% faster than MySQL 5.7 for the same schema. InnoDB buffer pool — the RAM MySQL uses to cache active data pages — should be set to at least 256MB for any WordPress site with over 1,000 posts. On shared hosting, the buffer pool is shared among 200+ accounts. On VPS, you configure it for your database only. A 4GB VPS with innodb_buffer_pool_size=1G keeps your wp_posts and wp_options tables in memory permanently.
WordPress has a built-in object cache that lives only for the duration of a single PHP request — every page load recomputes the same queries from scratch. Redis provides persistent object cache that survives across requests. get_option('blogname') goes from a MySQL SELECT taking 8ms to a Redis GET taking 0.1ms. Multiply by 50 option reads per page load: 400ms vs 5ms from database queries alone. For WooCommerce sites where cart and checkout pages bypass page cache, Redis is not optional — it is the primary performance mechanism.
WordPress renders HTML by executing PHP and querying MySQL on every non-cached request. LiteSpeed's native LSCache serves full-page HTML from memory without invoking PHP — TTFB drops from 200 to 600ms to 20 to 80ms. WP Rocket achieves similar results by writing HTML to disk and serving it on subsequent requests. The correct metric for evaluating this: cache hit rate. A site with 85%+ cache hit rate on shared hosting outperforms an uncached VPS in total server load. Cache hit rate, not hosting tier, determines the performance ceiling for most sites.
Each concurrent uncached page visitor consumes one PHP worker. At 350ms average PHP execution per request, 6 EP workers (standard shared hosting) handles 17 concurrent uncached requests per second theoretically — in practice far fewer because WooCommerce pages take 600 to 1,200ms and variation causes bunching. A 4GB VPS with 30 configured PHP-FPM workers handles 5x the concurrent load from the same hardware, because those workers are not shared with 200 other accounts competing for the same pool.
WordPress reads dozens of PHP files on every cold start — even with OPcache warmed up, file stat calls still occur on modified files. NVMe PCIe 4.0 storage at 3 to 5 GB/s read speed reduces cold-start overhead by 20 to 60ms compared to SATA SSD on the same hardware. This matters most on servers with many active WordPress installs (agency VPS) where the OPcache cannot hold all sites' compiled bytecode simultaneously and must evict and re-warm frequently.
The PHP-OPcache-MySQL Stack: Numbers Behind the Decisions
Three infrastructure variables produce 90% of the measurable WordPress performance difference between hosting plans. Not CPU brand, not SSD type, not network bandwidth. PHP version, OPcache configuration, and MySQL instance isolation. Here are the numbers behind each decision.
PHP version: a one-click change with a 15% performance return
| PHP Version | Support Status | Security Status | Action |
|---|---|---|---|
| PHP 7.4 | End of Life Jan 2023 | No security patches since Jan 2023 | Migrate immediately — actively vulnerable |
| PHP 8.0 | End of Life Nov 2023 | No patches since Nov 2023 | EOL — upgrade to 8.2 or 8.3 now |
| PHP 8.1 | Security only through Nov 2025 | Security fixes only | Upgrade soon — 8.2 is 10–15% faster |
| PHP 8.2 | Active support | Full support | Recommended default for 2026 |
| PHP 8.3 | Active support | Latest stable | Best performance — 15% over 8.1, use if plugins support it |
The practical test I ran in March 2026: same WordPress 6.5 install, same 12 plugins, same Astra theme, on a ScalaHosting managed VPS (2 vCPU, 4 GB RAM), switching only PHP version. PHP 8.1 produced 340ms average TTFB on uncached pages. PHP 8.3 produced 288ms on the same pages — a 15% reduction from a 60-second change in the control panel. If your WordPress site is on PHP 7.4 or 8.0, switching to 8.3 is the highest-ROI free action available to you.
WP_DEBUG=true, load a few pages, and check your error log for deprecated notices or fatal errors. Major plugins — Yoast SEO, WooCommerce, Elementor, ACF, Gravity Forms — are all PHP 8.3 compatible as of 2026.OPcache: the two settings that matter
OPcache is enabled by default on all modern hosts. Most hosts set it with values designed for their server average, not your specific WordPress install. On shared hosting you cannot change these. On VPS you can.
WordPress core + WooCommerce + 15 plugins = approximately 8,000 PHP files. At 16KB average compiled bytecode per file, that is 128MB — exactly the default. Any cache miss forces recompilation. Set to 256MB for safety margin. Check hit rate with the OPcache Status plugin: if hit rate is below 95%, increase memory.
WordPress with WooCommerce, Elementor, and 15 plugins has 8,000 to 15,000 PHP files. The default 10,000 file limit gets breached by a typical WooCommerce install. When breached, OPcache silently evicts files and recompiles them on next request — increasing PHP execution time without any error message. Set to 20,000 on any VPS running a plugin-heavy WordPress install.
MySQL isolation: why shared hosting and VPS behave differently under load
On shared hosting, your WordPress database shares MySQL with 200 to 800 other accounts on the same server. The shared MySQL instance has a global connection pool — typically 150 to 500 connections. When all 150 connections are in use by other accounts' PHP requests, your WordPress queries queue. The queue adds 50 to 500ms to every database interaction. This is the mechanism behind "my site is slow at noon but fast at 3 AM" — noon is when your neighbors' traffic fills the connection pool. 3 AM is when it is empty.
On a managed VPS, MySQL serves only your accounts. The connection pool is fully available to your PHP workers. MySQL query time stabilizes at 1 to 8ms for cached data rather than oscillating between 5ms and 400ms based on what 200 neighboring accounts are doing at the same moment. This stability is the VPS performance benefit that benchmark tests miss — they test at 3 AM, not noon.
Three Caching Layers, Three Different Problems — Most Guides Only Cover One
Install WP Rocket and consider caching done. That is the advice 90% of WordPress performance guides give. WP Rocket handles one of three caching layers. For a content blog, one layer is sufficient. For WooCommerce, one layer is not enough — and the missing layer is exactly the one that addresses the WooCommerce performance problem.
| Cache Layer | Where It Runs | Availability | Performance Impact | Limitation |
|---|---|---|---|---|
| Full-page cache (HTML) | All tiers via plugin | Available | 20–80ms for cached pages | Pages bypass cache if user is logged in or URL has query strings |
| Object cache (Redis) | Managed VPS+ | VPS required | Reduces MySQL from 50ms to <1ms per cached query | Not available on shared hosting at any price |
| OPcache (PHP bytecode) | All modern hosts | Always on | 40–60% PHP execution time reduction | Must be sized correctly — 128MB default fills up fast |
| CDN edge cache | All tiers (Cloudflare free) | Optional | TTFB from <50ms globally for cached content | Only helps cacheable content — dynamic pages still hit origin |
How the three layers stack in practice
For a non-logged-in visitor to a blog post, the request path with all three layers active: the CDN edge node serves the cached HTML (layer 3) in 20ms with zero origin requests. The visitor never touches your server.
For a logged-in WooCommerce user loading the cart page: CDN cannot cache it (per-user content), page cache cannot serve it (dynamic per session), but Redis object cache (layer 2) means the 80 database queries that WooCommerce runs for the cart page are served from Redis memory in 0.1ms each rather than MySQL in 5 to 50ms each. PHP execution time drops from 800ms to 280ms. The user still waits for PHP — but 280ms instead of 800ms.
Without Redis, the logged-in user's cart page hits MySQL directly on every request. On a busy WooCommerce store during a flash sale, with 50 simultaneous logged-in users, the MySQL connection pool saturates, cart pages return 500 errors, and checkout fails. The problem is not server power. It is the absence of layer 2. And layer 2 requires VPS.
WooCommerce Hosting Is a Different Problem Than WordPress Hosting
WooCommerce powers 39% of all e-commerce globally in 2026. Most WooCommerce stores start on shared hosting and leave not because their traffic grew, but because their checkout became unreliable. The mechanism is specific: WooCommerce's four most critical pages — cart, checkout, order received, account — serve different content to every user. They cannot be page-cached. Every authenticated visitor runs PHP.
The checkout worker math
A WooCommerce checkout process takes 600 to 1,200ms of PHP execution time: WooCommerce validates the cart, calculates taxes, initiates the payment gateway handoff, decrements inventory, generates order email, and records the transaction. On a shared hosting plan with 6 EP workers, your store supports exactly 6 simultaneous checkout processes.
What WooCommerce specifically requires beyond standard WordPress hosting
For stores processing under 50 daily orders, shared hosting with LiteSpeed Cache handles the workload — non-authenticated product browsing is fully cacheable, and 50 daily orders does not produce enough simultaneous checkout pressure to exhaust 6 EP workers during business hours. Above 50 daily orders, or if your store runs flash sales or promotions that produce traffic spikes, the EP limit becomes a real failure mode.
The practical threshold: when you see WooCommerce cart errors or checkout timeouts during your store's peak hours while the frontend loads normally, your EP limit is saturated. This is not a plugin problem and not a code problem — no amount of WooCommerce optimization resolves a structural EP ceiling on shared hosting. The fix is VPS with Redis, not a faster WordPress plugin.
For stores above 500 daily orders, dedicated WooCommerce hosting (Nexcess, Liquid Web WooCommerce) or a high-spec managed VPS with dedicated MySQL instance, Redis, and a separate object storage layer for product images becomes the correct architecture. The managed WordPress hosting guide covers these specific platforms and their WooCommerce configurations in detail.
WordPress Hosting Tiers: What Each One Actually Delivers
The WordPress hosting market uses the same vocabulary across a 100x price range. Understanding what you are actually buying at each tier is the only way to make a rational choice.
Standard shared hosting with WordPress one-click install. The "WordPress" label adds nothing to the infrastructure. You get PHP (version depends on host), MySQL (shared instance), OPcache (if configured), SSL (Let's Encrypt), and a control panel. What you do not get: Redis, configurable PHP workers, MySQL buffer pool control, or server-level performance tuning for WordPress specifically.
Dedicated resources (guaranteed CPU, RAM, disk I/O), Redis availability, configurable PHP worker count, isolated MySQL, and full server management from the host. WordPress runs on the same PHP/MySQL stack as shared hosting, but with dedicated allocation and correct tuning. This is the right tier for most growing WordPress and WooCommerce sites. Cloudways and ScalaHosting deliver this with one-click WordPress install, Redis toggle, and a dashboard for all PHP configuration. You still manage WordPress itself — updates, plugins, security plugins.
The host maintains both the server stack and the WordPress application layer. Kinsta, WP Engine, Nexcess, and Pressable run purpose-built WordPress infrastructure: isolated containers or Kubernetes, WordPress-specific PHP-FPM configuration, platform-integrated CDN, Git-based deployment, and WordPress core auto-updates. Support answers WordPress-level questions, not just server issues. The premium is real; so is the product difference from standard VPS.
Auto-scaling cloud infrastructure with horizontal scaling, multi-region deployment, object storage for media, dedicated database instances, and enterprise SLAs. Kinsta enterprise, WP Engine Scale plans, or custom Cloudways infrastructure with load balancers. When your traffic is genuinely unpredictable — viral potential, major product launches, large media publisher spikes — the auto-scaling capability prevents outages that a fixed-capacity server cannot. For the vast majority of WordPress sites, this tier is infrastructure over-engineering. A well-configured LiteSpeed VPS with caching handles 200,000 monthly visits without auto-scaling.
Q1 2026 WordPress Performance Benchmarks by Tier
Benchmark numbers published by hosting companies test their infrastructure under optimal conditions — single request, no concurrent load, from a nearby location. The numbers below test under conditions that reflect real site behavior: multiple concurrent users from multiple global locations.
The finding that changes how you think about tier selection: the LiteSpeed shared host beats managed VPS at 50 concurrent cached requests. The managed VPS beats everything at 50 concurrent uncached requests. Your site's cache hit rate determines which row you should read, not which tier is theoretically faster. A WooCommerce store with 40% cache hit rate (most pages are dynamic) should read the uncached rows. A content blog with 92% cache hit rate should read the cached rows — and will find shared LiteSpeed performs nearly identically to managed WordPress at a fraction of the cost.
The WordPress Hosting Decision Framework in Four Questions
The wrong way to choose a WordPress host: read a roundup, pick the one with most stars. The right way: answer these four questions in order, then follow the logic to the right tier.
- What is your monthly traffic, honestly?Under 30,000 visits/month: Shared hosting with LiteSpeed + caching plugin. Do not upgrade infrastructure when the correct action is installing a free plugin.
30,000 to 200,000 visits/month: Managed VPS (ScalaHosting, Cloudways). This is the traffic range where EP limits and shared MySQL produce real performance degradation.
200,000+ visits/month: Managed WordPress or cloud infrastructure. At this volume, single-server architecture introduces risk. - Do you run WooCommerce with active checkout traffic?No WooCommerce, or under 50 daily orders: Caching covers your workload. Tier 1 or Tier 2 depending on traffic.
50 to 500 daily orders: Managed VPS with Redis is mandatory. Checkout reliability depends on it.
500+ daily orders: Dedicated WooCommerce hosting (Nexcess, Liquid Web) or high-spec VPS with separate MySQL instance. - Do you want the host to manage WordPress updates and security?No — I manage WordPress myself: Any tier works. You are buying infrastructure.
Yes — I want automated WordPress management: Managed WordPress tier only (Nexcess from $19/month, Kinsta from $35/month). Verify the plan explicitly includes WordPress core updates, not just server management. - Do you need developer workflow features?No staging, no Git deploy needed: Any tier. Shared hosting Softaculous staging is sufficient for plugin testing.
Git deploy, multiple environments, team permissions: Cloudways (best workflow at VPS price), Kinsta (best workflow overall), or WP Engine. These platforms treat WordPress as a deployment target, not just a hosted application.
Five WordPress Hosting Myths That Persist Despite the Evidence
A shared LiteSpeed host with LSCache active serves cached pages at 28ms TTFB. A managed WordPress platform serves uncached pages at 82ms TTFB. For a content blog with 90%+ cache hit rate, shared hosting is faster for the traffic that actually matters. Managed WordPress wins on uncached performance, concurrency under load, and global edge distribution. The gap only matters when you have significant uncached traffic — which most content sites do not.
Plugin count is not the variable. Database query count, PHP execution time, and external HTTP requests on the front end are the variables. A well-coded plugin adding 2 optimized queries adds less overhead than a poorly coded plugin making 40 unoptimized calls. A plugin that only fires on the admin dashboard adds zero frontend load time. Measure with Query Monitor — look at query count and execution time, not plugin count.
TTFB over 800ms is often host-related and switching hosts fixes it. LCP over 2.5s is almost always caused by a large unoptimized hero image, render-blocking scripts, or a page builder loading 400KB of unused CSS. CLS failures come from missing image dimensions or layout-shifting ads. These problems exist on every host. Fix the site before blaming the server.
WordPress.com free and Personal plans do not allow plugin installation — which eliminates WooCommerce, advanced SEO plugins, most page builders, and any customization requiring a plugin. The Business plan at $25/month enables plugins. For $3 to $4/month on shared hosting, you run full WordPress with zero restrictions. WordPress.com's simplicity is real; what it costs is platform lock-in and capability restrictions at every tier below Business.
Cloudflare's free tier caches static assets (images, CSS, JS) and, with correct configuration, full HTML pages at 300+ edge nodes globally. A Singapore visitor accessing a US-based WordPress site gets cached content from a Singapore edge node at 20ms TTFB. But WooCommerce checkout, login, and admin always route to the origin server regardless of CDN. For a pure content site, Cloudflare free CDN solves the international latency problem entirely. For WooCommerce, it solves the problem for product browsing but not for checkout — origin server location still matters for the purchase flow.
WordPress Hosting FAQ
What is WordPress hosting and is it different from regular web hosting?
WordPress hosting describes any hosting plan configured or marketed for WordPress. The difference from generic web hosting ranges from cosmetic (a WordPress logo and one-click install) to substantial (platform-level PHP tuning, Redis object cache, WordPress-aware caching, Git deploy workflows, and automatic WordPress updates). Basic shared WordPress hosting is standard shared hosting with WordPress pre-installed. Managed WordPress hosting at the Kinsta or WP Engine tier runs a purpose-built stack: LXD containers, WordPress-specific PHP-FPM pools, integrated CDN, and WordPress-aware support. The 30x price range between these endpoints reflects genuinely different infrastructure, not branding.
Which PHP version should I run for WordPress in 2026?
PHP 8.2 is the safe default — virtually every major plugin that supports PHP 8.x runs on 8.2 without issues. PHP 8.3 is 5 to 10% faster than 8.2 for WordPress workloads and is supported by WordPress 6.4+ and all actively maintained plugins as of Q1 2026. PHP 7.4 reached end of life in January 2023 — it receives no security patches. Running PHP 7.4 in 2026 means running an unpatched runtime with publicly known CVEs. Switching PHP version takes under 60 seconds in any control panel: cPanel PHP Selector, SPanel, hPanel, or Cloudways App Management. There is no cost, no downtime, and the performance improvement is immediate.
Does WordPress need Redis, or is a caching plugin enough?
For content sites, a caching plugin (WP Rocket, LiteSpeed Cache) is enough. Full-page caching handles non-logged-in visitors efficiently, and those represent 85 to 95% of a typical blog's traffic. Redis becomes necessary when a significant portion of your traffic bypasses page cache: WooCommerce cart and checkout pages, membership sites where most users are logged in, forums, or any site where AJAX requests represent the performance-critical path. Without Redis, each of these uncacheable requests triggers 30 to 80 MySQL queries. With Redis, those queries are served from memory in under 1ms total instead of 150 to 400ms from MySQL. Redis requires VPS-level hosting — it is not available on any shared hosting plan.
What is OPcache and do I need to configure it manually?
OPcache stores compiled PHP bytecode in memory so WordPress does not reparse and recompile its PHP files on every request. Without OPcache, loading a WordPress page compiles 200 to 400 PHP files from source on every request — a process that adds 50 to 150ms of execution time. With OPcache, that compilation happens once and is reused. OPcache is enabled by default on all modern shared hosts and VPS environments. The configuration detail most hosts get wrong: opcache.memory_consumption defaults to 128MB, which fills up on a WordPress site with 20+ active plugins, causing cache misses and silent recompilation. On VPS where you control php.ini, set opcache.memory_consumption=256 and opcache.max_accelerated_files=20000.
Is managed WordPress hosting worth the price over shared hosting?
For content sites with high cache hit rates (blogs, marketing sites, portfolios), a quality LiteSpeed shared host at $3 to $5/month with LiteSpeed Cache enabled delivers performance that rivals managed WordPress platforms costing $35 to $100/month. The managed WordPress premium is justified when you need: (1) hands-off WordPress updates and security management, (2) developer workflow features (Git deploy, staging environments, environment cloning), (3) WooCommerce at scale where a dedicated PHP worker pool and platform-managed Redis is critical, or (4) genuine 24/7 WordPress-expert support. If none of these four apply to your site, the managed WordPress premium buys you infrastructure you are not using.
How do I know if my WordPress site is outgrowing shared hosting?
Four signals, in order of reliability: (1) Your cPanel Resource Usage panel shows EP (Entry Process) usage regularly hitting 80 to 100% of your allocation during business hours — this is the definitive sign. (2) Your TTFB under real traffic exceeds 600ms despite having a caching plugin configured correctly. (3) WooCommerce checkout errors or timeouts appear during peak hours while the frontend loads normally — this is MySQL connection exhaustion, not a plugin problem. (4) You need Redis object cache and your host cannot provide it — shared hosting structurally cannot support Redis. If none of these four apply, the infrastructure is not the constraint. Optimize your site code before spending on a tier upgrade.