WordPress hosting for 2026: cloud vs edge vs traditional hosting compared

In 2026, WordPress hosting is an architecture decision, not just a subscription. You choose where PHP runs, where MySQL lives, what is cached at the edge, and which subprocessors handle personal data for your European users.

This guide compares managed hosting, cloud IaaS/PaaS and edge layers. It then covers PHP workers, object cache, WooCommerce limits at the edge, data residency under GDPR, and how CI/CD keeps environments reproducible. The goal is a decision basis you can hand to your operations team, not a vendor list.

Links to WordPress speed optimization and the practical server administration chapters of the WordPress advanced administration handbook help when you move from choosing to measuring.

#What separates managed, cloud and edge hosting for WordPress

The three models solve different problems. Mix them wrongly and you pay for complexity without getting lower TTFB where it counts.

#Managed WordPress hosting

Managed platforms own the stack: PHP-FPM, Nginx or LiteSpeed, MySQL, daily backups, staging and often WP-CLI. You do not patch the operating system, but you inherit their limits on concurrent workers, cron intervals and which object caches are supported.

Typical fit: marketing sites, blogs, smaller WooCommerce shops with predictable traffic, and teams without dedicated DevOps. Weakness: when checkout or admin hits the worker ceiling, the only buttons are “upgrade plan” or “move out”.

#Cloud hosting (IaaS and PaaS)

On AWS, Google Cloud, Azure or European alternatives you build VMs, a managed database, a load balancer and networking yourself (or through Terraform). Kubernetes is common for large fleets, but a well-sized autoscaling group with PHP-FPM and Redis is enough for many mid-sized shops.

Advantage: you control CPU burst, database IOPS and region. Drawback: patching, certificates, log aggregation and failover are your job. Cloud without runbooks is just more expensive downtime.

#Edge hosting with CDN and Workers

Edge here means CDN, HTML edge cache and compute close to the user (for example Cloudflare Workers, covered in my guide to Workers in front of WordPress and WooCommerce). Edge is rarely “WordPress without an origin”. It is a layer in front of the origin: cache hits for anonymous pages, bot filtering, image rewriting, A/B tests without touching PHP.

Cache misses, logged-in users and POST requests to checkout still go to the origin. Plan for that, or edge becomes an illusion of speed.

#Which PHP and database versions WordPress recommends

Before you compare providers, check they meet the baseline. On its requirements page, WordPress.org recommends “PHP version 8.3 or greater”, “MySQL version 8.0 or greater” or “MariaDB version 10.11 or greater”, and HTTPS support. These are recommendations for the host, not a guarantee that every plugin you run supports the same version.

In practice that means three questions for a new provider: which PHP version production runs today, how quickly the next one arrives, and whether you can choose the version per environment so staging can be tested on the new one before production moves. A managed plan that pins you to an older PHP branch gives you an upgrade project on the provider’s timetable instead of your own.

#How many PHP workers does WordPress need

A PHP worker is one process (or thread in some stacks) that handles one request at a time. The number of workers times the average processing time sets the ceiling for requests per second before the queue grows and TTFB rises.

Worked example: a shop with 20 workers and 400 ms average PHP time handles roughly 50 requests per second before queueing. If every uncached product page takes 800 ms because plugins call external APIs, capacity halves. The fix is rarely “more plugins”. It is usually fewer synchronous calls, better page cache, and more workers only where measurement shows the need.

Practical steps:

• Measure PHP-FPM queue time (slowlog, APM) before doubling workers.
• Separate admin and cron from the frontend with their own pools where the platform allows it.
• Do not let wp-cron run on every frontend request; use system cron.
• Keep sessions and temporary files off slow local disk when several nodes share the load.

The WordPress.org server documentation stresses that hosting is more than “PHP plus MySQL”: file permissions, HTTPS and process isolation affect both security and stability.

#How to set pm.max_children in PHP-FPM

On your own server or in the cloud, workers are a setting you own. The PHP manual for FPM describes three modes for pm: static gives a fixed number of child processes, dynamic adjusts the number between pm.start_servers, pm.min_spare_servers and pm.max_spare_servers, and ondemand spawns processes only when requests arrive. Common to all of them is pm.max_children, which according to the manual “sets the limit on the number of simultaneous requests that will be served”.

In practice the ceiling is set by memory: every PHP process uses RAM, and if pm.max_children times the typical process size exceeds what the server has free, you trade queueing for swapping. To see where time goes, set request_slowlog_timeout to a few seconds. FPM then writes a PHP backtrace to the slowlog file for every request that takes longer, and you see which plugin or external call holds the worker.

#When should you use Redis or Memcached on WordPress

The object cache stores the results of wp_cache_* calls and persistent objects between requests. Without a persistent backend the cache only lives in memory for one request. The WP_Object_Cache documentation says it plainly: “By default, the object cache is non-persistent”, and nothing survives across page loads until you install a persistent backend as a drop-in in wp-content. With Redis or Memcached, options, postmeta hot spots and transients are reused across workers.

Where object cache helps most:

• WooCommerce with many products and variations
• Pages with heavy WP_Query calls that are not page cached
• Multisite, or many active plugins reading options repeatedly

Where it helps little:

• Purely static landing pages already full-page cached on the CDN
• Misconfigured plugins that bypass the object cache or write huge objects
• A database that is already the bottleneck on write-heavy checkout flows

Set TTLs deliberately. Evict aggressive keys on deploy. Monitor the hit rate: “Redis is on” without a hit percentage is theatre. Keep Redis in the same region as PHP to avoid extra latency; an object cache hop to another continent costs more than it saves.

#What Cloudflare caches by default in front of WordPress

Many people assume a CDN in front of WordPress caches whole pages automatically. Cloudflare’s own documentation on default cache behavior says otherwise: “The Cloudflare CDN does not cache HTML or JSON by default”. Without your own rules, files are cached by extension, such as images, CSS, JS, fonts and PDF, while the HTML produced by PHP goes to the origin every time.

The same page lists what stops caching even after you switch it on: a Set-Cookie header from the origin, Cache-Control: private, no-store, no-cache or max-age=0, and any request method other than GET. To cache HTML, Cloudflare recommends a Cache Rule that caches everything, or Workers for custom logic.

For WordPress the consequence is that a plugin which sets a cookie on every page quietly makes the edge cache worthless. Check the response headers on an anonymous product page before concluding that “the CDN does not help”.

#Which WooCommerce pages can be cached at the edge

WooCommerce mixes cacheable catalogue pages with highly dynamic paths: cart, checkout, My account, REST endpoints for payment gateways, webhooks from Stripe or PayPal. An edge cache serving anonymous HTML for /product/ is good. An edge cache serving the same HTML to a user with items in the cart destroys conversion.

Edge rules that work in practice:

• Cache GET for catalogue, posts and cacheable landing pages
• Bypass on cookies such as woocommerce_items_in_cart, wp_woocommerce_session_* and login cookies
• Never cache POST, admin-ajax cart requests or payment callbacks
• Keep the origin close to payment and ERP integrations; the edge cannot magically “move” PCI or session logic

WooCommerce’s own guide to configuring caching plugins confirms the boundary: cart, My account and checkout must stay out of the cache because they show information specific to the current customer. The cookie list there is woocommerce_cart_hash, woocommerce_items_in_cart, wp_woocommerce_session_, woocommerce_recently_viewed and store_notice[notice id]. If the cache layer offers database caching, the guide also suggests excluding _wc_session_. Use that list as the starting point for the edge bypass rule instead of guessing.

A typical scenario: a Black Friday campaign with heavy catalogue traffic from several countries. The CDN and edge cache take landing and product pages. Checkout stays on the origin in an EU region with enough PHP workers and Redis. If you try “the whole shop on Workers”, you still lack an authoritative database for stock, orders and VAT.

Measure TTFB for both cache hits and cache misses. web.dev’s TTFB guide separates server response from network delay; the edge often improves the latter for static content, while PHP and database traces still dominate an uncached checkout.

#GDPR and data residency when choosing WordPress hosting

Choosing a host is also choosing a processor: where do MySQL snapshots, logs, backups, support access and subprocessors live?

Checklist before you sign:

• Primary region for database and files (for example EU/EEA). “Global anycast” for a CDN is not the same as data residency for personal data.
• A data processing agreement (DPA) with a clear subprocessor list.
• A transfer mechanism if data leaves the EEA (standard contractual clauses, supplementary measures). “We use a US CDN” without documentation is a risk, not a feature.
• Logs and APM: do they contain email addresses, IPs, order IDs, and how long are they kept?
• Support access: who can use SSH or SFTP, and is it logged?

For US providers there is one more transfer mechanism: on 10 July 2023 the European Commission adopted an adequacy decision for the EU-US Data Privacy Framework. According to the Commission’s page on EU-US data transfers, it covers only companies that participate in the framework. Check whether your specific hosting or CDN provider is on the participant list instead of assuming “the US is covered”.

Edge compute that runs on personal data (A/B tests, personalisation) has to be treated as processing. Cache keys that include a user ID across hundreds of points of presence increase the attack surface. Keep personal content on the origin or in short-lived, tightly keyed layers.

#How to replace wp-cron with system cron

WP-Cron does not run on a clock. It is checked when someone loads a page, so scheduled tasks are delayed on quiet sites and compete with visitors on busy ones. The WordPress developer documentation shows the fix in two steps. First, switch off the traffic-driven trigger in wp-config.php:

define( 'DISABLE_WP_CRON', true );

Then let the system scheduler call wp-cron.php with a web request. The documentation uses */15 * * * * as the example for every 15 minutes and shows a wget call against wp-cron.php. Choose the interval from the actual jobs: a shop with subscription renewals needs a shorter interval than a blog with scheduled posts. On managed hosting, ask how the provider runs cron before you change anything, as some already do this for you.

#How to set up CI/CD for WordPress hosting

Without CI/CD, staging becomes “manual FTP on Thursday night”. In 2026, code, themes, plugins you own, and infrastructure definitions should go through a pipeline.

A minimum that works:

1. Git as the source of truth for custom code (theme, mu-plugins, infrastructure as code).
2. Build and test in CI: PHPStan or Psalm where available, PHPUnit for your own plugins, linting for the theme.
3. Deploy to staging with the same PHP version and extensions as production.
4. Smoke tests: home page, a product page, add to cart, login.
5. Production with an atomic release (new release directory plus symlink) or a container image with a health check.
6. Database migrations through WP-CLI or controlled migration scripts, never “edit in production”.

Secrets (API keys, database passwords) belong in a vault or the platform’s secret store, not in Git. Object cache and CDN purges should be triggered after deploy, not left to “remember to flush Redis”.

For managed hosting: use their Git deploy or rsync hooks, but keep the same test gate. For cloud: Terraform or Ansible plus baked images reduce snowflake servers. For edge: deploy Workers and CDN config from the same repository as the WordPress code, with review on cache rules that could break checkout.

#How to choose a WordPress hosting architecture in practice

Start with the workload, not with marketing words.

• Content-heavy, geographically spread read traffic: managed or cloud origin plus aggressive edge caching.
• WooCommerce with local payment methods and ERP: an EU-region origin, Redis, enough PHP workers, edge only for the catalogue.
• Strict compliance requirements: cloud or managed with documented EU/EEA storage and a short subprocessor list.
• Small team, predictable traffic: managed first; move to cloud when the worker ceiling and database I/O become the measured limit.

Hybrid is normal: managed or cloud for WordPress, Redis in the same region, CDN and Workers in front. Pure “serverless WordPress everywhere” is still a special case, not the default for real shops.

#Which performance metrics to record before switching WordPress hosting

Switching hosts without a baseline is guessing. Log for at least one week:

• TTFB and LCP on key templates (home, category, product, checkout steps)
• PHP-FPM queue and slow requests
• MySQL slow query log
• Cache hit rate (page and object)
• Error rates on payment webhooks

web.dev recommends understanding what TTFB actually measures before chasing a magic number. There, TTFB is the sum of redirects, DNS lookup, connection and TLS, and the wait until the first byte arrives. As a rough guide, web.dev calls 0.8 seconds or less good and anything above 1.8 seconds poor. A global marketing site can have low TTFB on cache hits and still a slow checkout. Optimise the layer that is actually the bottleneck.

#Common hosting mistakes on WordPress sites

• Edge caching without a cookie bypass for WooCommerce sessions
• Too few PHP workers, compensated with several cache plugins fighting over the same HTML
• Redis in a different region from PHP
• Backups only on the same disk as production
• No staging that mirrors the PHP version and extensions
• Personal data in CDN logs without a retention policy
• Deploys without a page cache purge, so old HTML fragments live for hours

Each of these is cheaper to fix with measurement and configuration than with “let’s switch provider again”.

#Help with choosing WordPress hosting

I map the existing stack, measure workers and cache, and propose managed, cloud or hybrid without overselling edge where checkout must stay consistent. The work usually covers architecture choice, Redis and page cache tuning, CDN rules for WooCommerce, and CI/CD to staging and production.

If you need a concrete review of your infrastructure, get in touch through the contact page.

#How to choose between managed, cloud and edge in 2026

Managed gives operational help and a ceiling. Cloud gives control and responsibility. Edge gives low latency for cacheable content, not a replacement for PHP and MySQL on dynamic WooCommerce paths. PHP workers and object cache decide capacity at the origin. GDPR and data residency decide region and subprocessors. CI/CD keeps changes reproducible.

Choose the architecture by measured load and compliance, then tune cache and workers. That lasts longer than chasing the newest hosting label.