VPS para WordPress: cuánta RAM necesitas según tu tráfico

Busca “VPS para WordPress” y en todos los artículos te encuentras la misma tabla: hasta 10.000 visitas, 2 GB; hasta 100.000, 8 GB; de ahí para arriba, 16.

Llevan años copiándose de un sitio a otro y tiene un fallo de base, porque las visitas no consumen memoria. La consumen las peticiones que tu caché no puede servir, y eso depende mucho más de lo que hace tu web que de cuánta gente entra.

Un blog con 200.000 visitas al mes y una caché de página decente va sobrado con 3 GB. Una tienda WooCommerce con 40.000 visitas se ahoga con esos mismos 3 GB, porque el carrito, el checkout y “mi cuenta” no se cachean nunca. La misma RAM, el resultado contrario.

En este post hemos detallado la cuenta bien hecha: la fórmula, el reparto de memoria componente a componente y el momento exacto en el que el hosting compartido deja de darte.

Por qué las visitas mensuales no te dicen nada

Cuando una página está cacheada, el servidor devuelve un archivo estático. No arranca PHP, no consulta la base de datos y el coste en memoria es casi cero. Un servidor modesto sirve miles de peticiones así por segundo sin despeinarse.

El trabajo de verdad empieza cuando la petición tiene que pasar por PHP. Y hay una lista corta de cosas que no se pueden cachear nunca:

• Carrito, checkout y “mi cuenta” de WooCommerce
• Cualquier visita con sesión iniciada
• Búsquedas internas y filtros de catálogo por atributos
• Formularios y llamadas AJAX, incluidos los fragmentos del carrito
• Todo el escritorio de WordPress
• Las tareas de fondo: wp-cron, importaciones de catálogo, sincronización con el ERP, generación de feeds

Ahí está la diferencia entre los dos ejemplos de arriba: En un blog bien montado el 95% de las peticiones se resuelven desde la caché y solo un 5% llega a PHP. En una tienda con usuarios registrados ese porcentaje se dispara al 40% o al 60%, porque media web es dinámica por diseño.

Así que la pregunta útil no es cuántas visitas tienes al mes. Es cuántas peticiones por segundo esquivan tu caché en el peor minuto del día.

La fórmula del peor minuto

Los procesos PHP que necesitas a la vez salen de una multiplicación:

Procesos simultáneos = peticiones por segundo que esquivan la caché × segundos que tarda cada petición

Un ejemplo con números reales:

Tienes una tienda y mandas una newsletter a 10.000 suscriptores. Un 20% abre el correo en la primera media hora y un 10% de esos hace clic: 200 visitas concentradas en unos diez minutos. Son 0,33 visitas por segundo, y como cada persona ve unas seis páginas mientras husmea el catálogo, el servidor recibe 2 páginas por segundo. La mitad esquiva la caché, así que tienes 1 petición PHP por segundo. Si cada una tarda 600 milisegundos, la media es de 0,6 procesos ocupados, con picos de cuatro o cinco cuando varias coinciden.

Con diez procesos PHP disponibles eso lo aguantas sin enterarte. El problema es que en un hosting compartido no decides tú cuántos hay.

Cada cuenta de un servidor compartido vive dentro de un LVE de CloudLinux, que es un cerco de recursos con su propio límite de memoria, de núcleos y de procesos de entrada. Cuando lo tocas, el servidor deja de encolar y devuelve un error 508, Resource Limit Is Reached. No hay degradación suave: la web va perfecta hasta que de golpe deja de ir, y justo en el momento en el que más gente está mirando.

El reparto de memoria, componente a componente

Esta es la tabla que echo de menos en los demás artículos. La RAM de un servidor de WordPress se reparte siempre entre las mismas cinco cosas, y los procesos PHP no son ni de lejos la que más pesa:

Fíjate en dónde se va el dinero. En la tienda mediana los procesos PHP ocupan 1,5 GB y la base de datos, 2 GB. Quien te vende RAM “para aguantar tráfico” te está vendiendo la columna equivocada: lo que hace que una tienda vaya rápida es que el buffer pool de MariaDB quepa entero en memoria, porque en cuanto la base de datos no cabe y empieza a leer de disco, cada consulta se paga en milisegundos que el cliente nota en el checkout. Por eso el tipo de disco tampoco da igual, como explicamos en esta guía sobre VPS administrados con NVMe.

Los megas por proceso tampoco son inventados. Un WordPress limpio con una plantilla ligera se mueve entre 60 y 80 MB por proceso. Una tienda con WooCommerce, pasarela de pago, sincronización de stock y un constructor visual se pone en 150 o 200 MB, y la propia documentación de WooCommerce pide un memory_limit de 256 MB o más desde la versión 10.8, que además exige PHP 8.3 y MySQL 8.0 o MariaDB 10.6.

Para los núcleos la regla es más sencilla: uno por cada tres o cuatro procesos PHP que estén trabajando a la vez.

Cuánto necesitas según lo que tengas montado

Dos avisos sobre esta tabla. El primero es que un catálogo con muchos atributos y filtros pesa más que el número de pedidos: 5.000 referencias con filtrado por talla, color y marca generan consultas que ningún plugin de caché va a salvar. El segundo es que si tienes tráfico internacional de verdad, la hora punta se te alarga y el margen de la última columna se come antes de lo que dice la cuenta.

Siete señales de que te has quedado corto en compartido

No hace falta que adivines. El servidor avisa, y casi siempre por este orden:

1. Errores 508 en horas concretas del día, normalmente por la tarde o cuando mandas una campaña.
2. El medidor de “entry processes” de cPanel tocando el tope. Es el primer límite que se agota, antes que la RAM y antes que la CPU.
3. El TTFB se dispara solo en hora punta. A las tres de la madrugada la web vuela; a las siete de la tarde tarda dos segundos en empezar a responder. Ese patrón no se arregla con un plugin de caché, aunque conviene descartar antes lo evidente con las herramientas de diagnóstico habituales.
4. El backup nocturno no termina o el panel empieza a saltarlo.
5. Importar el CSV del catálogo tumba la web durante veinte minutos.
6. Necesitas software que el compartido no te deja instalar: Redis con la memoria que tú decidas, un Elasticsearch para la búsqueda interna, una versión concreta de una extensión de PHP, un proceso que se quede escuchando.
7. El LCP pasa de 2,5 segundos solo en determinadas franjas. Google mide con datos de campo, así que esos picos te cuentan en Core Web Vitals aunque en tu PageSpeed de por la mañana salga todo en verde.

Si has marcado uno o dos, casi seguro que te sobra con más recursos. Si has marcado cuatro o más, el problema ya no es de plan, es de arquitectura.

Administrado o autogestionado: la cuenta que nadie hace bien

Aquí está la decisión de verdad, y es la que decide tu factura durante los próximos tres años. La planteamos con más calma en qué es el hosting WordPress gestionado y cuándo te conviene.

Un VPS pelado cuesta entre 5 y 15 euros al mes. Es una cifra que engancha, y es la que sale en los foros cuando alguien pregunta por hosting para su WordPress. El problema es que ese precio es solo la primera línea de la factura.

La línea de la licencia ya descoloca los números: cPanel cuesta más que el propio servidor en la gama baja. Y las horas son las que de verdad deciden.

Haz esta multiplicación con tu tarifa. La diferencia entre un VPS de 5,50 euros y uno administrado de 94 son 88,50 euros al mes. Si tu hora vale 40 euros, esa diferencia equivale a dos horas y diez minutos de tu tiempo. Si dedicas más de eso al mes a parchear el sistema, revisar logs, actualizar el panel, probar que los backups restauran y responder cuando algo se cae, el administrado ya te sale más barato, y eso sin contar las 8 o 12 horas del montaje inicial ni el coste de la noche en la que la tienda está caída y tú estás cenando fuera.

El VPS sin administrar tiene su sitio, y es honesto decirlo: si eres desarrollador, te gusta tener el control del stack y el servidor es un proyecto tuyo, montarte tu Docker o tu LEMP a mano es una opción perfectamente razonable. Lo que no funciona es contratarlo pensando que te ahorras noventa euros, porque lo que haces es cambiarlos por horas tuyas a un precio peor.

El escalón intermedio que casi nadie te cuenta

Entre el hosting compartido de 6 euros al mes y el VPS de 94 hay un salto que la mayoría de artículos se salta, y es justo donde encaja media España.

Si lo que te falta son recursos y no control del sistema, no necesitas un VPS. Necesitas recursos dedicados dentro de un entorno gestionado.

Nuestros planes de hosting elástico están pensados para eso:

Compara el Elastic Start con la tabla de perfiles de antes. Cinco gigas de RAM, tres núcleos y 200 procesos simultáneos cubren de sobra una web de contenido con picos y se quedan cerca de una tienda pequeña, por un tercio de lo que cuesta el VPS más básico.

¿Cuándo sí necesitas el VPS? Cuando quieras acceso root de verdad, cuando tengas que instalar software que no viene en un panel compartido, cuando el aislamiento sea un requisito de tu cliente o de tu auditoría, o cuando manejes tantos sitios que el reparto por cuenta deje de tener sentido. Nuestros planes VPS empiezan en 94 euros al mes con 6 GB, 3 vCPU y 50 GB NVMe, y llegan a 209 euros con 16 GB, 8 vCPU y 200 GB. Esos 16 GB son, si vuelves a la tabla de componentes, exactamente el número de la última columna. Y si el siguiente salto te lo estás planteando ya, lo comparamos en servidores dedicados administrados frente a VPS.

Y si ya sabes que vas a crecer, el pago anual te sale a precio de diez meses.

Qué administramos nosotros y qué sigue siendo tuyo

Esto es lo que más se difumina en las páginas de producto, así que va en dos listas. El detalle completo está en cómo funcionan nuestros VPS administrados para empresas.

De esto nos encargamos nosotros:

• Monitorización 24/7 del uptime y de los servicios, con respuesta en menos de una hora
• Hardening de seguridad e Imunify360
• Actualizaciones del sistema operativo y de cPanel
• Ajuste de rendimiento de Apache, Nginx o LiteSpeed
• Backups diarios con JetBackup en ubicación externa, con 15 días de retención más ciclos de dos meses
• Respuesta inmediata ante caídas, reinicios incluidos
• Instalación de extensiones de PHP y de Apache que necesites
• Análisis de problemas de rendimiento e intervención ante ataques

Esto sigue siendo tuyo:

• El código y la programación de tu web
• El diseño y el contenido de WordPress o PrestaShop
• Las actualizaciones de tus plugins, plantillas y del núcleo de WordPress, que son la puerta de entrada de casi todos los ataques, como repasamos en WordPress seguro
• La creación de las cuentas de correo
• La subida de archivos por FTP

Te entregamos el servidor con acceso root, aunque la idea es que no te haga falta entrar. Y va con IP española, en un datacenter en España, con el soporte en español al otro lado del ticket.

La migración, que es donde la gente se atasca

Migrar un WordPress con tienda da respeto, sobre todo por los pedidos que puedan entrar mientras dura el cambio. El orden que evita los sustos es este, y lo desarrollamos paso a paso en nuestra guía de migración de hosting:

1. Montamos tu web en el servidor nuevo y la dejamos funcionando con el dominio todavía apuntando al viejo. Aquí es donde se prueba todo: pasarela de pago en modo test, correos transaccionales, los cron.
2. Baja el TTL del dominio a 300 segundos 24 horas antes. Con un TTL alto, media internet sigue enviando tráfico al servidor antiguo durante horas y algún pedido se queda por el camino.
3. Congelas la tienda unos minutos, se hace una última sincronización de la base de datos y se cambian los registros DNS.
4. Con el TTL bajo la propagación se resuelve en minutos, no en un día.
5. Una semana después el TTL vuelve a valores normales.

La primera migración va incluida y la hacemos nosotros. Si vienes de otro proveedor con cPanel, el traspaso es directo; si vienes de un panel distinto o de una instalación a mano, lo montamos igual.

Lo que contratas en Nicalia