En 2026, el hosting de WordPress es una decisión de arquitectura, no solo una suscripción. Decides dónde corre PHP, dónde vive MySQL, qué se cachea en el borde de la red y qué subencargados tratan los datos personales de tus usuarios en España y en el resto de la UE.
Esta guía compara el hosting gestionado, la nube IaaS/PaaS y las capas edge. Después repasa los PHP workers, el object cache, los límites de WooCommerce en el edge, la ubicación de los datos bajo el RGPD y cómo el CI/CD mantiene los entornos reproducibles. El objetivo es una base de decisión que puedas llevar a tu equipo de operaciones, no una lista de proveedores.
Para pasar de elegir a medir te servirán nuestra guía de optimización de velocidad WordPress y los capítulos sobre servidor del WordPress Advanced Administration Handbook.
Qué diferencia el hosting gestionado, la nube y el edge para WordPress
Los tres modelos resuelven problemas distintos. Si los combinas mal, pagas complejidad sin conseguir un TTFB más bajo donde importa.
Hosting WordPress gestionado
Las plataformas gestionadas son dueñas de la pila: PHP-FPM, Nginx o LiteSpeed, MySQL, copias diarias, staging y a menudo WP-CLI. Tu sitio corre en un entorno aislado dentro de un centro de datos; el proveedor se ocupa de las actualizaciones del servidor, los parches de seguridad, las copias y la monitorización. Un CDN distribuye el contenido estático, pero PHP sigue ejecutándose en una ubicación física concreta. No parcheas el sistema operativo, pero heredas sus límites de workers simultáneos, intervalos de cron y object caches admitidos.
Encaje típico: webs de marketing, blogs, tiendas WooCommerce pequeñas con tráfico previsible y equipos sin DevOps propio. Ventajas: soporte que entiende WordPress, staging para probar actualizaciones antes de producción y copias con restauración sencilla. Debilidades: si tu origen está en Europa, los usuarios de otros continentes notan latencia extra en las peticiones no cacheadas, y cuando el checkout o el panel chocan con el techo de workers, los únicos botones son «subir de plan» o «irse».
Hosting en la nube (IaaS y PaaS)
En AWS, Google Cloud, Azure o alternativas europeas montas tú mismo (o con Terraform) máquinas virtuales, base de datos gestionada, balanceador y red. Kubernetes es habitual en flotas grandes: varios pods de PHP-FPM que escalan según la demanda, MySQL o MariaDB con réplicas, Redis para object cache compartido y volúmenes persistentes para los archivos subidos, compartidos entre pods. Para muchas tiendas medianas basta un grupo de autoescalado bien dimensionado con PHP-FPM y Redis, sin la carga operativa de un clúster.
Ventaja: controlas el burst de CPU, los IOPS de la base de datos y la región. Inconveniente: parches, certificados, agregación de logs y failover son cosa tuya. La nube sin runbooks es solo una caída más cara.
Hosting edge con CDN y Workers
Edge significa aquí CDN, caché de HTML en el borde y cómputo cerca del usuario (por ejemplo Cloudflare Workers, que tratamos en la guía de Workers delante de WordPress y WooCommerce). El edge rara vez es «WordPress sin origen». Es una capa delante del origen: aciertos de caché para páginas anónimas, filtrado de bots, transformación de imágenes, pruebas A/B sin llamar a PHP.
Los fallos de caché, los usuarios con sesión y los POST al checkout siguen yendo al origen. Además, invalidar la caché cuando publicas contenido nuevo exige una estrategia de purga clara, y si el proveedor del CDN tiene un problema global, todo tu tráfico lo nota. Planifícalo, o el edge se queda en una ilusión de velocidad.
Qué versiones de PHP y base de datos recomienda WordPress
Antes de comparar proveedores, comprueba que cumplen los requisitos base. En su página de requisitos, WordPress.org recomienda PHP 8.3 o superior, MySQL 8.0 o superior o MariaDB 10.11 o superior, y soporte de HTTPS. Son recomendaciones para el proveedor, no una garantía de que todos tus plugins admitan la misma versión.
En la práctica salen tres preguntas para un proveedor nuevo: qué versión de PHP corre hoy en producción, cuándo llega la siguiente y si puedes elegir la versión por entorno para probar la nueva en staging antes de mover producción. Un plan gestionado que te ata a una rama antigua de PHP te deja un proyecto de actualización con el calendario del proveedor, no con el tuyo.
Cuántos PHP workers necesita WordPress
Un PHP worker es un proceso (o hilo en algunas pilas) que atiende una petición cada vez. El número de workers por el tiempo medio de proceso fija el techo de peticiones por segundo antes de que crezca la cola y suba el TTFB.
Ejemplo de cálculo: una tienda con 20 workers y 400 ms de tiempo medio de PHP atiende unas 50 peticiones por segundo antes de que haya cola. Si cada ficha de producto sin caché de página tarda 800 ms porque los plugins llaman a API externas, la capacidad se reduce a la mitad. La solución rara vez es «más plugins»; suele ser menos llamadas síncronas, mejor caché de página y más workers solo donde la medición lo justifica.
Medidas prácticas:
- Mide el tiempo de cola de PHP-FPM (
slowlog, APM) antes de duplicar workers. - Separa el panel y el cron del frontend con pools propios si la plataforma lo permite.
- No dejes que wp-cron se ejecute en cada petición del frontend; usa el cron del sistema.
- Mantén sesiones y archivos temporales fuera de un disco local lento cuando varios nodos reparten la carga.
La documentación de servidor de WordPress.org insiste en que el hosting es más que «PHP más MySQL»: los permisos de archivos, HTTPS y el aislamiento de procesos afectan a la seguridad y a la estabilidad.
Cómo ajustar pm.max_children en PHP-FPM
En tu propio servidor o en la nube, los workers son un ajuste que te pertenece. El manual de PHP para FPM describe tres modos para pm: static da un número fijo de procesos hijo, dynamic ajusta el número entre pm.start_servers, pm.min_spare_servers y pm.max_spare_servers, y ondemand lanza procesos solo cuando llegan peticiones. Común a todos es pm.max_children, que según el manual «fija el límite de peticiones simultáneas que se atenderán» (traducción propia).
En la práctica el techo lo pone la memoria: cada proceso PHP ocupa RAM, y si pm.max_children por el tamaño típico de proceso supera la memoria libre del servidor, cambias cola por swap. Para ver dónde se va el tiempo, pon request_slowlog_timeout en unos segundos. FPM escribirá entonces un backtrace de PHP en el archivo slowlog por cada petición más lenta, y verás qué plugin o qué llamada externa retiene al worker.
Cuándo usar Redis o Memcached en WordPress
El object cache guarda los resultados de las llamadas wp_cache_* y objetos persistentes entre peticiones. Sin un backend persistente, la caché solo vive en memoria durante una petición. La documentación de WP_Object_Cache lo dice claramente: «Por defecto, el object cache no es persistente» (traducción propia), y nada sobrevive entre cargas de página hasta que instalas un backend persistente como drop-in en wp-content. Con Redis o Memcached, las opciones, los puntos calientes de postmeta y los transients se reutilizan entre workers.
Cuándo ayuda más:
- WooCommerce con muchos productos y variaciones
- Páginas con consultas
WP_Querypesadas que no entran en la caché de página - Multisite o muchos plugins activos que leen opciones una y otra vez
Cuándo ayuda poco:
- Landings puramente estáticas ya cacheadas enteras en el CDN
- Plugins mal configurados que se saltan el object cache o escriben objetos enormes
- Una base de datos que ya es el cuello de botella en flujos de compra con muchas escrituras
Fija los TTL a propósito. Vacía las claves agresivas al desplegar. Vigila la tasa de aciertos: «Redis está activado» sin porcentaje de aciertos es teatro. Mantén Redis en la misma región que PHP; un salto del object cache a otro continente cuesta más de lo que ahorra.
Qué cachea Cloudflare por defecto delante de WordPress
Mucha gente da por hecho que un CDN delante de WordPress cachea páginas enteras automáticamente. La propia documentación de Cloudflare sobre el comportamiento de caché por defecto dice otra cosa: «El CDN de Cloudflare no cachea HTML ni JSON por defecto» (traducción propia). Sin reglas propias, los archivos se cachean por extensión, como imágenes, CSS, JS, fuentes y PDF, mientras que el HTML que genera PHP va al origen cada vez.
La misma página enumera lo que impide cachear incluso después de activarlo: una cabecera Set-Cookie del origen, Cache-Control: private, no-store, no-cache o max-age=0, y cualquier método de petición distinto de GET. Para cachear HTML, Cloudflare recomienda una Cache Rule que lo cachee todo, o Workers para lógica propia.
Para WordPress, la consecuencia es que un plugin que pone una cookie en cada página deja la caché edge sin valor sin que nadie lo note. Revisa las cabeceras de respuesta de una ficha de producto anónima antes de concluir que «el CDN no ayuda».
Qué páginas de WooCommerce se pueden cachear en el edge
WooCommerce mezcla páginas de catálogo cacheables con rutas muy dinámicas: carrito, finalizar compra, Mi cuenta, endpoints REST de pasarelas de pago, webhooks de Redsys, Bizum o Stripe. Una caché edge que sirve HTML anónimo para /producto/ está bien. Una caché edge que sirve el mismo HTML a un usuario con artículos en el carrito destroza la conversión.
Reglas edge que funcionan en la práctica:
- Cachear GET para catálogo, entradas y landings cacheables
- Saltar la caché con cookies como
woocommerce_items_in_cart,wp_woocommerce_session_*y las de inicio de sesión - No cachear nunca POST, peticiones de carrito por admin-ajax ni callbacks de pago
- Mantener el origen cerca de las integraciones de pago y ERP; el edge no «traslada» por arte de magia la lógica PCI o de sesión
La propia guía de WooCommerce para configurar plugins de caché confirma el límite: carrito, Mi cuenta y finalizar compra deben quedar fuera de la caché porque muestran información del cliente concreto. La lista de cookies que da es woocommerce_cart_hash, woocommerce_items_in_cart, wp_woocommerce_session_, woocommerce_recently_viewed y store_notice[notice id]. Si la capa de caché ofrece caché de base de datos, la guía sugiere excluir también _wc_session_. Usa esa lista como punto de partida de la regla de bypass en el edge en lugar de adivinar.
Un escenario típico: una campaña de Black Friday con mucho tráfico de catálogo. El CDN y la caché edge se quedan con las landings y las fichas de producto. El checkout sigue en el origen, en una región de la UE con suficientes PHP workers y Redis. Si intentas «toda la tienda en Workers», sigues sin una base de datos autoritativa para stock, pedidos e IVA.
Mide el TTFB tanto en aciertos como en fallos de caché. La guía de web.dev sobre TTFB separa la respuesta del servidor del retardo de red; el edge suele mejorar lo segundo para contenido estático, mientras que las trazas de PHP y base de datos siguen mandando en un checkout sin caché.
RGPD y ubicación de datos al elegir hosting WordPress
Elegir hosting también es elegir un encargado del tratamiento. ¿Dónde están los snapshots de MySQL, los logs, las copias, el acceso del soporte y los subencargados?
Lista de comprobación antes de firmar:
- Región principal para base de datos y archivos (por ejemplo UE/EEE). El «anycast global» de un CDN no es lo mismo que la ubicación de los datos personales.
- Contrato de encargo del tratamiento con una lista clara de subencargados.
- Base para la transferencia si los datos salen del EEE (cláusulas contractuales tipo, medidas complementarias). «Usamos un CDN de EE. UU.» sin documentación es un riesgo, no una función.
- Logs y APM: ¿contienen correos, IP o números de pedido, y cuánto tiempo se guardan?
- Acceso del soporte: ¿quién puede entrar por SSH o SFTP, y queda registrado?
Para proveedores de EE. UU. existe una base de transferencia más: el 10 de julio de 2023 la Comisión Europea adoptó una decisión de adecuación para el EU-US Data Privacy Framework. Según la página de la Comisión sobre transferencias de datos a EE. UU., solo cubre a las empresas que participan en ese marco. Comprueba si tu proveedor concreto de hosting o CDN figura en la lista de participantes en lugar de suponer que «EE. UU. está cubierto».
El cómputo edge que trabaja con datos personales (pruebas A/B, personalización) es tratamiento. Las claves de caché que incluyen el ID de usuario en cientos de puntos de presencia aumentan la superficie de ataque. Mantén el contenido personal en el origen o en capas de vida corta y con claves bien controladas.
Cómo sustituir wp-cron por el cron del sistema
WP-Cron no funciona con reloj. Se comprueba cuando alguien carga una página, así que las tareas programadas se retrasan en sitios con poco tráfico y compiten con los visitantes en los que tienen mucho. La documentación para desarrolladores de WordPress muestra la solución en dos pasos. Primero desactivas el disparo por tráfico en wp-config.php:
define( 'DISABLE_WP_CRON', true );Después el programador del sistema llama a wp-cron.php con una petición web. La documentación usa */15 * * * * como ejemplo de cada 15 minutos y muestra una llamada wget contra wp-cron.php. Elige el intervalo según las tareas reales: una tienda con renovaciones de suscripciones necesita un intervalo más corto que un blog con entradas programadas. En un hosting gestionado, pregunta cómo ejecuta el cron el proveedor antes de tocar nada, porque algunos ya lo hacen por ti.
Cómo montar CI/CD para el hosting WordPress
Sin CI/CD, el staging acaba siendo «FTP manual el jueves por la noche». En 2026, el código, los temas, los plugins propios y las definiciones de infraestructura deberían pasar por un pipeline.
Un mínimo que funciona:
- Git como fuente de verdad del código propio (tema, mu-plugins, infraestructura como código).
- Build y pruebas en CI: PHPStan o Psalm donde existan, PHPUnit para tus plugins, linting del tema.
- Despliegue a staging con la misma versión de PHP y las mismas extensiones que producción.
- Pruebas de humo: portada, una ficha de producto, añadir al carrito, acceso.
- Producción con release atómico (nuevo directorio de release más symlink) o imagen de contenedor con healthcheck.
- Migraciones de base de datos con WP-CLI o scripts de migración controlados, nunca «editar en producción».
Los secretos (claves de API, contraseñas de base de datos) van en un vault o en el almacén de secretos de la plataforma, no en Git. La purga del object cache y del CDN debe lanzarse tras el despliegue, no depender de «acordarse de vaciar Redis».
En hosting gestionado: usa su despliegue desde Git o hooks de rsync, pero conserva la misma puerta de pruebas. En la nube: Terraform o Ansible más imágenes horneadas reducen los servidores copo de nieve. En el edge: despliega la configuración de Workers y del CDN desde el mismo repositorio que el código de WordPress, revisando las reglas de caché que podrían romper el checkout.
Cómo elegir la arquitectura de hosting WordPress en la práctica
Empieza por la carga de trabajo, no por las palabras de marketing.
- Mucho contenido y lectores repartidos geográficamente: origen gestionado o en la nube más caché edge agresiva.
- WooCommerce con pagos locales y ERP: origen en una región de la UE, Redis, suficientes PHP workers, edge solo para el catálogo.
- Requisitos estrictos de cumplimiento: nube o gestionado con almacenamiento documentado en la UE/EEE y una lista corta de subencargados.
- Equipo pequeño y tráfico previsible: primero gestionado; pasa a la nube cuando el techo de workers y la E/S de la base de datos sean el límite medido.
Lo normal es el híbrido: gestionado o nube para WordPress, Redis en la misma región, CDN y Workers delante. El «WordPress serverless en todas partes» sigue siendo un caso especial, no el estándar para tiendas reales.
Qué métricas de rendimiento tomar antes de cambiar de hosting WordPress
Cambiar de hosting sin línea base es adivinar. Registra durante al menos una semana:
- TTFB y LCP en las plantillas clave (portada, categoría, producto, pasos del checkout)
- Cola de PHP-FPM y peticiones lentas
- Slow query log de MySQL
- Tasa de aciertos de caché (página y objeto)
- Tasa de errores en los webhooks de pago
web.dev aconseja entender qué mide de verdad el TTFB antes de perseguir una cifra mágica. Allí el TTFB es la suma de redirecciones, consulta DNS, conexión y TLS, y la espera hasta que llega el primer byte. Como guía aproximada, web.dev considera bueno 0,8 segundos o menos y deficiente más de 1,8 segundos. Una web de marketing internacional puede tener un TTFB bajo en aciertos de caché y seguir con un checkout lento. Optimiza la capa que de verdad es el cuello de botella.
Errores de hosting habituales en sitios WordPress
- Caché edge sin bypass de cookies para las sesiones de WooCommerce
- Pocos PHP workers, compensados con varios plugins de caché peleando por el mismo HTML
- Redis en otra región distinta de PHP
- Copias de seguridad solo en el mismo disco que producción
- Ningún staging que replique la versión de PHP y las extensiones
- Datos personales en los logs del CDN sin política de retención
- Despliegues sin purga de la caché de página, con fragmentos de HTML viejos vivos durante horas
Cada uno de estos errores sale más barato de corregir con medición y configuración que con «cambiamos otra vez de proveedor».
Ayuda para elegir hosting WordPress
Mapeamos la pila actual, medimos workers y caché, y proponemos gestionado, nube o híbrido sin vender edge de más donde el checkout tiene que ser coherente. El trabajo suele cubrir la elección de arquitectura, el ajuste de Redis y de la caché de página, las reglas del CDN para WooCommerce y el CI/CD hasta staging y producción, además del mantenimiento WordPress posterior.
Si necesitas una revisión concreta de tu infraestructura, escríbeme desde la página de contacto.
Cómo elegir entre gestionado, nube y edge en 2026
El gestionado da ayuda operativa y un techo. La nube da control y responsabilidad. El edge da baja latencia para contenido cacheable, no un sustituto de PHP y MySQL en las rutas dinámicas de WooCommerce. Los PHP workers y el object cache deciden la capacidad del origen. El RGPD y la ubicación de los datos deciden la región y los subencargados. El CI/CD mantiene los cambios reproducibles.
Elige la arquitectura según la carga medida y el cumplimiento normativo, y después ajusta caché y workers. Eso dura más que perseguir la etiqueta de hosting más nueva.
