Un blog con 200.000 visitas al mes y una cach\u00e9 de p\u00e1gina 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.<\/em><\/p><\/blockquote>\n En este post hemos detallado la cuenta bien hecha<\/strong>: la f\u00f3rmula, el reparto de memoria componente a componente y el momento exacto en el que el hosting compartido deja de darte.<\/p>\n <\/p>\n Cuando una p\u00e1gina est\u00e1 cacheada, el servidor devuelve un archivo est\u00e1tico. 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\u00ed por segundo sin despeinarse.<\/p>\n El trabajo de verdad empieza cuando la petici\u00f3n tiene que pasar por PHP. Y hay una lista corta de cosas que no se pueden cachear nunca:<\/p>\n Ah\u00ed est\u00e1 la diferencia entre los dos ejemplos de arriba:<\/strong>\u00a0En un blog bien montado el 95% de las peticiones se resuelven desde la cach\u00e9 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\u00e1mica por dise\u00f1o.<\/p>\n As\u00ed que la pregunta \u00fatil no es cu\u00e1ntas visitas tienes al mes. Es cu\u00e1ntas peticiones por segundo esquivan tu cach\u00e9 en el peor minuto del d\u00eda.<\/p>\n Los procesos PHP que necesitas a la vez salen de una multiplicaci\u00f3n:<\/p>\n Procesos simult\u00e1neos = peticiones por segundo que esquivan la cach\u00e9 \u00d7 segundos que tarda cada petici\u00f3n<\/p><\/blockquote>\n Un ejemplo con n\u00fameros reales: <\/strong><\/em><\/p>\n 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\u00e1ginas mientras husmea el cat\u00e1logo, el servidor recibe 2 p\u00e1ginas por segundo. La mitad esquiva la cach\u00e9, as\u00ed que tienes 1 petici\u00f3n 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.<\/p>\n Con diez procesos PHP disponibles eso lo aguantas sin enterarte. El problema es que en un hosting compartido no decides t\u00fa cu\u00e1ntos hay.<\/p>\n Cada cuenta de un servidor compartido vive dentro de un LVE de CloudLinux, que es un cerco de recursos con su propio l\u00edmite de memoria, de n\u00facleos y de procesos de entrada. Cuando lo tocas, el servidor deja de encolar y devuelve un error 508, Resource Limit Is Reached<\/strong>. No hay degradaci\u00f3n suave: la web va perfecta hasta que de golpe deja de ir, y justo en el momento en el que m\u00e1s gente est\u00e1 mirando.<\/p>\n Esta es la tabla que echo de menos en los dem\u00e1s art\u00edculos. 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\u00e1s pesa:<\/p>\nPor qu\u00e9 las visitas mensuales no te dicen nada<\/h2>\n
\n
La f\u00f3rmula del peor minuto<\/h2>\n
El reparto de memoria, componente a componente<\/h2>\n
![\"\u00bfNecesitas](\"https:\/\/www.nicalia.com\/blog\/wp-content\/uploads\/2026\/09\/vps-para-wordpress-01-1024x572.jpg\" "\\"\\"")
<\/a><\/p>\n