La mayoría de los consejos sobre rendimiento se centran en lo que ocurre cuando el tráfico se dispara, como la planificación de la capacidad, el precalentamiento de la caché y el escalado. En la mayoría de los sitios de WordPress, lo habitual es justo lo contrario: un periodo de descenso del tráfico a medida que la actividad vuelve a la normalidad tras el fin de una campaña, el paso de un pico estacional o el fin del impulso de un lanzamiento de producto.
Cuando el tráfico disminuye, podrías pensar que tu situación de alojamiento mejora porque hay menos presión sobre tus recursos. En la práctica, puede ocurrir justo lo contrario. Entender por qué revela mucho sobre cómo funcionan realmente la mayoría de los entornos de alojamiento.
Por qué el rendimiento del alojamiento no debería depender de tus patrones de tráfico
Para un usuario final, el alojamiento compartido suele ofrecer una mejor relación calidad-precio, pero conlleva un mayor riesgo de problemas de seguridad y un rendimiento irregular. La tentación para un proveedor de alojamiento compartido es utilizar el espacio del servidor para sacar el máximo beneficio posible.
Una práctica habitual es la «sobreventa». Esto ocurre cuando un proveedor asigna a los clientes más recursos de los que realmente hay en el servidor. Funciona de forma similar a como operan los bancos: generan intereses prestando el dinero que otros clientes han depositado. El sistema funciona siempre y cuando nadie intente retirar su dinero al mismo tiempo.
Los entornos de alojamiento compartido alojan cientos o miles de sitios web en el mismo servidor físico, por lo que, cuando aumenta la demanda, a menudo no hay suficiente recursos para todos.
Aquí es donde entra en juego la «asignación dinámica de recursos», que da prioridad a los sitios activos frente a los inactivos. Un mayor tráfico en tu sitio significa que recibe más recursos que los sitios con menos visitas. El modelo da prioridad de forma efectiva a los sitios con mucho tráfico, mientras que asigna menos recursos a los que tienen menos tráfico.
Sin embargo, esto no se debe a un plan por niveles. El servidor simplemente decide en tiempo real dónde destinar los recursos disponibles. El rendimiento depende del tráfico, en lugar de depender de la infraestructura.
Cosmick Media, cliente de Kinsta, tuvo problemas parecidos. La agencia sufrió interrupciones intermitentes del servicio y problemas de velocidad en las páginas con sus proveedores de alojamiento anteriores. Estos problemas no aparecieron hasta que el equipo amplió su base de clientes, momento en el que se hizo más difícil ignorar las limitaciones de recursos de la infraestructura compartida.
La limitación de rendimiento oculta que se produce durante el funcionamiento normal
La limitación de recursos en el alojamiento compartido puede adoptar varias formas y ayuda a entender cómo se reparten los recursos entre los sitios web:
- Los límites de CPU limitan la potencia de procesamiento que un sitio puede utilizar en cualquier momento.
- La asignación de RAM restringe la cantidad de memoria que puede utilizar un sitio.
- Las restricciones I/O controlan la velocidad a la que un sitio lee y escribe en el disco.
Cuando hay mucho tráfico, tu sitio tiende a usar más recursos de los que tiene disponibles. Cuando la actividad baja, esos recursos compartidos son rápidamente utilizados por otros sitios del servidor. La consecuencia más evidente es que el front end se ralentiza, pero la consecuencia menos visible (y a menudo más perjudicial) es lo que ocurre con las operaciones en segundo plano.
WP-Cron activa tareas en segundo plano como la optimización de la base de datos, la comprobación de actualizaciones de plugins, la publicación programada y la limpieza de archivos temporales en WordPress. Estas tareas se ejecutan en segundo plano, pero siguen compitiendo por los mismos recursos limitados. En un servidor con exceso de carga, dejan de ser fiables: se retrasan, fallan sin avisar o ni siquiera se ejecutan.
El deterioro del rendimiento se va acumulando con el tiempo
El coste real de la limitación de rendimiento es acumulativo, ya que cada tarea que se deja sin hacer agrava la siguiente:
- Si no se aprovechan las oportunidades para optimizar la base de datos, esto contribuye a que el sistema se sature, lo que ralentiza las consultas en cada solicitud posterior.
- Las tareas en segundo plano que fallan dejan huecos en el ciclo de mantenimiento que no se restablecen automáticamente cuando se recupera el tráfico.
- Las operaciones de administración lentas retrasan el mantenimiento rutinario (actualizaciones de plugins, cambios de contenido y tareas de configuración) que mantienen un sitio de WordPress estable y seguro.
Las revisiones de entradas, los transitorios y las opciones cargadas automáticamente se almacenan en la base de datos de WordPress. Si no se optimiza con regularidad, las tablas se van llenando y las consultas se ralentizan. En un servidor con recursos constantes, la limpieza se ejecuta según lo programado. Sin embargo, en un servidor compartido con recursos limitados, solo se ejecuta cuando hay suficientes recursos disponibles. Durante los periodos de poco tráfico, estas tareas de limpieza pueden ejecutarse con mucha menos frecuencia.
El resultado es un bucle de retroalimentación en el que la degradación del rendimiento dificulta el mantenimiento, lo que produce un sitio menos saludable. Este empeoramiento del rendimiento puede acelerar la disminución del tráfico orgánico a través de cargas de página más lentas y puntuaciones Core Web Vitals más débiles.
Cómo la arquitectura de contenedores de Kinsta elimina la dependencia del tráfico en el rendimiento
Todos los sitios de WordPress en Kinsta se ejecutan dentro de un contenedor Linux aislado y no comparten su asignación de recursos con otros sitios de la plataforma. Tampoco hay colas de prioridad que determinen qué sitios reciben más recursos.
Un sitio web que está bajando tras haber alcanzado el pico de una campaña sigue funcionando con los mismos recursos que tenía asignados durante ese pico. La infraestructura no reasigna los recursos cuando baja el número de visitantes.
Esto es importante porque, aunque los planes superiores de Kinsta admiten más visitas mensuales, todos funcionan con el mismo modelo de contenedores aislados y las mismas garantías de recursos. En cambio, los planes determinan los límites de capacidad, como el ancho de banda mensual, el número de visitas y los recursos disponibles. Esto también influye en cómo Kinsta utiliza los hilos PHP para mejorar el rendimiento general de tu sitio.
En el caso concreto de WP-Cron, esto significa que las tareas programadas cuentan con recursos constantes para ejecutarse de forma fiable. La deuda técnica que se acumula en entornos con restricciones (como limpiezas omitidas, tareas en segundo plano fallidas, tablas sobrecargadas y demás) no se acumula aquí, ya que los recursos necesarios para evitarlo están siempre disponibles.
La caché multicapa funciona igual tanto en momentos de mucho tráfico como de poco tráfico
El stack de caché de Kinsta funciona en cuatro capas, cada una de ellas independiente del volumen de tráfico. Juntas reducen la carga de trabajo de tu contenedor y liberan recursos para las operaciones de administración y las tareas en segundo plano:
- Edge Caching muestra tu sitio directamente desde la red global de Cloudflare antes de que la solicitud llegue a tu servidor de origen. Las tasas de aciertos en la caché se mantienen altas tanto en los picos de tráfico como en los periodos de menor actividad. Las páginas almacenadas en caché no caducan solo porque el tráfico haya bajado, por lo que el sitio sigue mostrándose desde el edge después de la campaña, igual que lo hacía en su momento de mayor actividad.
- La caché a nivel de servidor gestiona las solicitudes dinámicas que no pasan por el edge, lo que reduce la carga de la base de datos en el origen. En los sitios web en los que los usuarios que han iniciado sesión o el contenido dinámico impiden la caché de páginas completas en el edge, esta capa garantiza que los tiempos de respuesta sigan siendo predecibles.
- La CDN de Kinsta sirve recursos estáticos (imágenes, CSS, JavaScript y fuentes) desde ubicaciones edge distribuidas. Se entregan a la misma velocidad independientemente del volumen de solicitudes, lo que hace que no afecten en absoluto a tu contenedor.
Además, no te olvides del almacenamiento en caché de objetos Redis con baja latencia de Kinsta. Esto guarda los resultados de las consultas a la base de datos en la memoria, para que WordPress no repita las mismas consultas cada vez que se carga una página. Para sitios con mucho contenido, tiendas de WooCommerce y plataformas de Membresía en las que se ejecutan las mismas consultas una y otra vez, esto se traduce en respuestas más rápidas y una menor carga sobre la base de datos.
Por qué el alojamiento premium es la mejor opción para un tráfico estable
La idea de que un menor tráfico justifica reducir el plan de alojamiento trata la infraestructura como una herramienta de escalabilidad que se amplía para los picos de tráfico y se reduce durante los periodos de menor actividad. Sin embargo, esto pasa por alto lo que supone alojar un sitio de WordPress durante los periodos entre campañas.
Aunque muchos planes de alojamiento basan el precio en el volumen de tráfico, el volumen de tráfico y la calidad de la infraestructura son dos cosas distintas. Un sitio que recibe menos visitas durante un periodo posterior a una campaña sigue necesitando una infraestructura fiable para que el mantenimiento siga funcionando, las herramientas de administración respondan y las tareas en segundo plano se ejecuten según lo previsto.
La complejidad de las aplicaciones de WordPress no disminuye con el tráfico
Las tareas como la gestión de plugins, el mantenimiento de la base de datos, los escaneos de seguridad y las publicaciones programadas no se detienen durante los periodos de menor actividad. Piensa en lo que necesita una agencia que gestiona la web de un cliente entre campañas:
- Entornos staging que se asemejen lo suficiente al entorno de producción como para detectar problemas antes del despliegue.
- Acceso SSH y WP-CLI para operaciones con la base de datos, gestión de plugins y scripts personalizados.
- Tiempos de respuesta del administrador que se mantengan durante la edición de contenidos y la gestión del sitio.
- Copias de seguridad programadas y escaneos de seguridad que se completan a tiempo.
Si gestionas flujos de trabajo de desarrollo, la transferencia de cambios del entorno staging al de producción, la actualización de plugins y la ejecución de migraciones de bases de datos requieren un rendimiento de alojamiento fiable. Trabajar en la web de un cliente durante un mes tranquilo sigue exigiendo el mismo rendimiento en los procesos de despliegue y los entornos staging.
Para una agencia que gestiona varios sitios de clientes en diferentes fases del ciclo de tráfico, una infraestructura compartida puede dificultar la gestión de los sitios más tranquilos, porque el servidor dirige los recursos hacia los más activos. En una infraestructura de contenedores aislada, todos los sitios se comportan igual, independientemente de lo que hagan los demás.
Un rendimiento coherente permite una planificación fiable a largo plazo
En pocas palabras, una infraestructura predecible cambia tu forma de trabajar. Cuando sabes que las tareas de mantenimiento se completan de forma fiable, que WP-Cron se ejecuta según lo programado y que las operaciones de administración responden de manera consistente, planificar resulta más fácil. Esto tiene varias ventajas prácticas:
- Reducción de la carga de soporte, ya que los problemas de rendimiento derivados de la saturación de recursos no generan los tickets que requieren investigación.
- Ciclos de planificación más fiables, ya que no tienes que tener en cuenta el riesgo de que el entorno de alojamiento se comporte de forma diferente en los meses de menor actividad.
- Menos incertidumbre sobre la infraestructura a la hora de elegir un alojamiento web en función de los patrones de tráfico. Ampliar la capacidad para las campañas y volver a reducirla después conlleva riesgos y una mayor carga administrativa en cada transición.
Merece la pena insistir en este último punto. Un alojamiento que requiere una gestión activa basada en las tendencias del tráfico va en contra de tu planificación, en lugar de acompañarla. Un sitio debería poder entrar en un periodo de inactividad sin ningún cambio en su alojamiento y salir de él en el mismo estado en que entró.
La infraestructura de alojamiento debe apoyar el crecimiento del negocio, no las curvas de tráfico
El patrón que provoca daños en los sitios de WordPress cuando baja el tráfico no es complicado. Una infraestructura con exceso de capacidad deja de dar prioridad a los sitios con menos actividad, las tareas en segundo plano se retrasan y la deuda técnica acumulada va aumentando con el tiempo.
Un modelo de alojamiento que aprovecha los periodos de menor tráfico para reducir los recursos disponibles acaba perjudicando a los sitios web a los que se supone que debe dar soporte.
Si estás evaluando tu configuración actual de alojamiento web, haz preguntas. Por ejemplo: ¿funcionan las tareas en segundo plano de forma fiable durante los periodos de menor actividad? ¿Siguen respondiendo bien tus herramientas de administración cuando el tráfico baja? En términos más generales, pregúntate si el modelo de recursos de tu proveedor de alojamiento trata un bajón tras una campaña igual que un pico de tráfico, o si el nivel de tu plan determina de forma implícita cuánta capacidad del servidor puedes utilizar.
El alojamiento administrado para WordPress de Kinsta se basa en contenedores aislados, un stack de caché de varias capas y recursos dedicados que no varían en función del tráfico. Esto significa que tu sitio funcionará igual de bien al final de una campaña que en el momento de mayor tráfico.
¿Quieres hacer preguntas? Ponte en contacto con nuestro equipo en cualquier momento.
