La mayoría de los proveedores de alojamiento hablan de velocidad en términos de medias. Tiempo medio de respuesta. Tiempo medio de carga. Puntuaciones medias en pruebas de rendimiento. Pero los visitantes reales no ven medias. Lo que ven es la página que tienen delante, en su dispositivo, a través de su conexión, en ese momento concreto.
Un sitio puede dar muy buenos resultados en una prueba de velocidad y, aun así, parecer lento cuando un cliente llega a realizar el pago, un usuario inicia sesión, se envía un formulario o el tráfico aumenta de repente. Esos momentos de lentitud pueden afectar solo a un pequeño porcentaje de visitas, pero suelen ser los que más importan.
Por eso la consistencia en el rendimiento merece más atención. La velocidad máxima está bien, pero es la velocidad predecible la que hace que la experiencia del usuario sea más fluida.
En el caso de las páginas de WordPress, sobre todo aquellas dedicadas al comercio electrónico, con membresías, funcionalidades de LMS, actividad de administración o patrones de tráfico impredecibles, la verdadera pregunta no es solo «¿Qué velocidad puede alcanzar tu sitio?», sino «¿Con qué frecuencia consigue mantenerse rápido?»
El problema de las afirmaciones sobre el rendimiento basadas en medias
La velocidad media es fácil de promocionar porque resume un montón de actividad en una sola cifra sencilla. Les da a los equipos un dato claro con el que comparar, informar y promocionarse.
Pero los promedios también pueden ocultar los problemas concretos que tus visitantes probablemente recordarán.
Por ejemplo, una página puede cargarse rápido para la mayoría de los usuarios, pero ralentizarse mucho para unos pocos. Una vez que se mezclan esas visitas rápidas y lentas, la media final puede seguir pareciendo aceptable. Sobre el papel, el rendimiento parece estar bien. En la práctica, algunos usuarios se quedan esperando.
Esto es importante porque las experiencias lentas rara vez se distribuyen de forma uniforme. Suelen aparecer en situaciones concretas, como:
- Picos de tráfico
- Errores de caché
- Sesiones con inicio de sesión
- Actividades de pago
- Consultas de búsqueda
- Envíos de formularios
- Tareas de administración del backend
- Tráfico de bots
- Solicitudes que cargan mucho la base de datos
Es posible que una prueba de velocidad de la página de inicio nunca ponga de manifiesto esos problemas. Tampoco lo hace un único tiempo de respuesta medio. Podrías tener un sitio que parezca rápido en un informe mensual, mientras que una parte de los visitantes sufre retrasos con frecuencia en momentos clave.
Y en el caso de las páginas de WordPress, esos momentos importantes suelen implicar actividades dinámicas, como un carrito de WooCommerce, un panel de control de membresía, una lección de un sistema de gestión del aprendizaje (LMS) o una búsqueda de productos filtrada.
Puede que tus pruebas de velocidad den buenos resultados, pero eso no lo dice todo
Las pruebas de velocidad son útiles. Pueden mostrar problemas de rendimiento evidentes, ayudar a los equipos a hacer un seguimiento de las mejoras y ofrecerte una referencia para comparar.
Pero siguen siendo solo una instantánea.
La mayoría de las pruebas sintéticas miden una sola página, desde una única ubicación y en un momento concreto. Dependiendo de cómo esté configurada la prueba, es posible que también esté midiendo una versión limpia y almacenada en la caché de la página, en condiciones ideales. Eso puede ser útil para pruebas controladas, pero no siempre refleja lo que experimentan los usuarios reales.
Los visitantes reales traen consigo más variables. Usan diferentes dispositivos, navegadores, redes y ubicaciones. Algunos ven páginas en la caché. Otros generan solicitudes sin caché o con caché parcial. Algunos han iniciado sesión. Otros añaden productos al carrito, envían un formulario, buscan en un catálogo o pasan por el proceso de pago.
Esas interacciones pueden suponer exigencias muy diferentes para un sitio de WordPress.
Una prueba sintética puede indicarte que tu página de inicio se carga rápido. Pero puede que no te diga si el proceso de pago sigue respondiendo bien durante una promoción, si los usuarios que han iniciado sesión pueden navegar sin problemas por el panel de control de su cuenta, o si una página de productos con muchas búsquedas se ralentiza cuando aumenta el tráfico.
Esta es una de las razones por las que decir «nuestras pruebas de velocidad salen bien» puede ser engañoso. Las pruebas pueden ser precisas en lo que miden, pero no miden todas las experiencias que realmente importan.
Por qué son importantes los percentiles p95 y p99
Si las medias muestran el punto medio de la historia, los percentiles muestran los extremos.
Los percentiles de rendimiento te ayudan a entender lo que experimentan los visitantes con menor velocidad, no solo cómo es una visita típica. En lugar de agrupar todas las solicitudes en una sola cifra, muestran cómo varía el rendimiento entre los distintos grupos de usuarios.
Por ejemplo, el rendimiento p95 representa el 5 % de las experiencias más lentas. Si tu tiempo de carga p95 es alto, significa que 5 de cada 100 visitas son notablemente más lentas que el resto. El p99 va aún más allá, mostrando el 1 % de las experiencias más lentas.
Puede que te parezca una parte pequeña del tráfico. Pero en una web con mucho tráfico, se acumula rápidamente.
Si tu web recibe 100.000 visitas al mes, una experiencia p95 lenta podría afectar a miles de sesiones. Si esas sesiones se producen durante el proceso de pago, el inicio de sesión en la cuenta, la captación de clientes potenciales o la búsqueda de productos, el impacto en el negocio puede ser mucho mayor de lo que sugiere el porcentaje.
Los percentiles son especialmente útiles porque revelan patrones que las medias pueden ocultar. Un sitio web puede tener un tiempo de respuesta medio razonable y, aun así, ofrecer una experiencia deficiente a los usuarios que se ven afectados por picos de tráfico, fallos de caché, solicitudes que sobrecargan la base de datos o flujos de comercio electrónico sin caché.
Para los equipos técnicos, las métricas p95 y p99 ofrecen una forma más fiel de evaluar el rendimiento del alojamiento. Ayudan a responder preguntas como:
- ¿Con qué frecuencia se ralentiza el sitio?
- ¿Hasta qué punto se ralentizan las solicitudes más lentas?
- ¿Las páginas dinámicas siguen respondiendo bien?
- ¿Se mantiene estable el rendimiento cuando hay más tráfico?
- ¿Hay un pequeño número de solicitudes lentas que están lastrando los recorridos importantes de los usuarios?
Estas cifras no sustituyen a la velocidad media, pero le dan contexto. Está bien tener una media alta. Un p95 y un p99 estables te indican si esa velocidad llega a los usuarios que más probablemente se darían cuenta si no fuera así.
¿Qué provoca que el rendimiento de WordPress sea irregular?
El rendimiento de WordPress no suele deberse a un único problema. Se debe a la carga de trabajo.
Una simple página en caché y una solicitud dinámica de pago pueden estar en el mismo sitio web, pero exigen cosas muy diferentes al servidor. Cuando el alojamiento gestiona bien un tipo de solicitud pero tiene dificultades con el otro, el rendimiento empieza a parecer irregular.
Las páginas en caché son la parte fácil
La caché puede hacer que WordPress vaya rapidísimo. Cuando alguien visita una página de inicio, una entrada de blog o una página de destino almacenada en la caché, el servidor suele poder mostrar una versión guardada de esa página en lugar de generarla desde cero. Eso significa menos trabajo para PHP, menos consultas a la base de datos y tiempos de respuesta más rápidos para los visitantes.
Por eso puede que un sitio obtenga unos resultados excelentes en una prueba de velocidad de la página de inicio. Puede que la página sea ligera, esté almacenada en la caché y sea fácil de cargar.
Pero muchos de los momentos que más importan en WordPress no funcionan así.
Las páginas dinámicas necesitan más recursos del servidor
Las páginas del carrito y de pago de WooCommerce no suelen poder utilizar la misma caché de página completa que una entrada de blog pública. El contenido varía en función de cada comprador, el contenido del carrito, los datos de envío, los impuestos, los cupones, las opciones de pago y los datos de la sesión.
Lo mismo se aplica a:
- Páginas de la cuenta una vez iniciada sesión
- Paneles de control de membresía
- Lecciones de LMS y seguimiento del progreso
- Contenido personalizado
- Filtrado de productos y búsqueda interna
- Envío de formularios
- Pantallas de administración y flujos de trabajo editoriales
Estas solicitudes suelen requerir hilos PHP, consultas a la base de datos, la lógica de los plugins y, a veces, servicios de terceros antes de que WordPress pueda dar una respuesta.
Ahí es donde suele aparecer la inconsistencia. Un visitante que lea un artículo almacenado en caché puede obtener una respuesta rápida. Otro visitante que actualice un carrito o envíe un formulario puede encontrarse con una solicitud mucho más pesada segundos después.
Los plugins, los temas y las llamadas a servicios de terceros pueden provocar ralentizaciones irregulares
Los plugins y los temas también pueden hacer que el rendimiento sea más difícil de predecir.
Un plugin podría añadir consultas a la base de datos en las páginas de productos. Un tema podría cargar scripts adicionales en toda la web. Un plugin de formularios podría llamar a un servicio externo al enviar el formulario. Una integración de envíos, impuestos, CRM, analíticas o pagos podría añadir tiempo de espera adicional en alguna parte del recorrido del usuario.
Estos problemas no siempre afectan a todas las páginas. La página de inicio puede seguir pareciendo rápida, mientras que el proceso de pago, la búsqueda, las páginas de cuenta o el área de administración de WordPress se ralentizan.
Esto hace que sea frustrante evaluar un rendimiento tan irregular. El sitio no es simplemente «rápido» o «lento». Depende de lo que esté haciendo el visitante.
Las tareas en segundo plano pueden competir con el tráfico en tiempo real
Las páginas de WordPress siguen trabajando incluso cuando los visitantes no están navegando por ellas. Las importaciones de productos, las entradas programadas, las copias de seguridad, las actualizaciones de plugins, los análisis de seguridad, las tareas de analítica, las sincronizaciones de correo electrónico, las herramientas de informes y la actividad de administración consumen recursos. En una página con poco tráfico, esas tareas pueden ejecutarse sin que nadie se dé cuenta. Durante un periodo de mucho tráfico, pueden entrar en conflicto con el tráfico en tiempo real.
Por ejemplo, una tienda de WooCommerce podría realizar una sincronización del inventario mientras los compradores están viendo productos y completando el proceso de pago. Un sitio de membresía podría procesar automatizaciones de correo electrónico mientras los usuarios que han iniciado sesión están cargando las páginas de las lecciones. Un sitio de contenidos podría realizar copias de seguridad mientras los editores están trabajando en el panel de control.
Cada tarea por sí sola puede ser razonable. Pero juntas, pueden alargar los tiempos de respuesta.
Los picos de tráfico y los bots aumentan la presión rápidamente
El tráfico casi nunca llega en una línea perfectamente constante. Una oferta, un newsletter, una campaña publicitaria, una publicación en redes sociales, el lanzamiento de un producto o una mención en la prensa pueden provocar una avalancha repentina de visitantes en tu sitio. El tráfico de bots puede provocar el mismo efecto, a menudo sin previo aviso. A diferencia de un pico promocional, no guarda relación con ninguna actividad empresarial que te ayude a anticiparlo.
El impacto en la infraestructura depende de dónde acaben los bots. Un bot que acceda a páginas de la caché supone una carga relativamente pequeña. En cambio, un bot que acceda a endpoints dinámicos, como páginas de carrito, URLs de productos filtrados o consultas de búsqueda con parámetros, consume los mismos recursos del servidor que un visitante real en cada una de sus solicitudes. A gran escala, ese tipo de tráfico automatizado puede agotar la capacidad de PHP y ralentizar los tiempos de respuesta para los usuarios legítimos, incluso aunque el sitio en sí no haya cambiado en absoluto.
Si la mayor parte del tráfico entrante llega a páginas almacenadas en la caché, es posible que la web aguante bien la carga. Pero cuando los bots o un pico de tráfico dirigen el volumen hacia endpoints dinámicos que no están en la caché, la carga de trabajo cambia rápidamente y los tiempos de respuesta se ven afectados.
Los recursos compartidos pueden hacer que el rendimiento sea más difícil de explicar
La infraestructura compartida añade otra capa de incertidumbre. Cuando varios sitios compiten por la misma CPU y memoria subyacentes, la actividad de un sitio puede afectar al rendimiento de otro. Puede que tu sitio de WordPress no haya cambiado. Puede que tus plugins no se hayan actualizado. Puede que tu tráfico parezca normal. Pero si aumenta la competencia por los recursos en torno a tu sitio, este puede ralentizarse de todos modos.
Esa imprevisibilidad complica la resolución de problemas. Puedes optimizar la propia página web y, aun así, seguir teniendo bajadas de rendimiento debido al entorno que la rodea.
Por qué la consistencia importa más que la velocidad máxima
La velocidad máxima queda muy bien en un titular. Puede mostrar de lo que es capaz un entorno de alojamiento en las condiciones adecuadas.
Pero los usuarios no juzgan un sitio web por su mejor momento. Lo juzgan por la visita que realmente tienen.
Una página de inicio que se carga rápido en una prueba no garantiza una experiencia de pago fluida. Una página de destino almacenada en caché no te dice cómo se comportan las búsquedas, el inicio de sesión, las actualizaciones del carrito o el envío de formularios cuando el sitio está bajo presión. Y un resultado rápido desde una ubicación concreta en un momento determinado no prueba que el rendimiento se mantenga estable a lo largo del día.
La consistencia es lo que hace que la experiencia resulte fiable.
- En el caso de las webs de comercio electrónico, eso significa que las páginas del carrito y de pago siguen respondiendo bien cuando los compradores están listos para comprar.
- En el caso de los sitios de membresía, esto significa que los usuarios pueden iniciar sesión y acceder al contenido sin retrasos.
- En el caso de las páginas para captar clientes potenciales, esto significa que los formularios se envían sin problemas, en lugar de atascarse justo en el peor momento posible.
Lo mismo pasa con las agencias y los equipos técnicos. Una web que solo funciona bien en condiciones ideales es más difícil de mantener. Genera más incertidumbre, más problemas que resolver y más conversaciones incómodas con los clientes. Un rendimiento predecible ofrece a los equipos algo más estable que monitorizar, explicar y mejorar.
Cómo garantiza Kinsta un rendimiento predecible de WordPress
Un rendimiento constante empieza por el propio entorno de alojamiento. En Kinsta, cada sitio de WordPress se ejecuta en su propio contenedor aislado con recursos dedicados que no se comparten con otros sitios, ni siquiera con los de la misma cuenta. Esa separación resuelve directamente el problema de que un sitio afecte a los tiempos de respuesta de otro sin ninguna causa aparente.
La caché juega un papel fundamental en dos capas. Edge Caching distribuye el HTML almacenado en caché a través de una red global de centros de datos, sirviendo las páginas desde ubicaciones cercanas a cada visitante, aumentando el rendimiento hasta un 40 % y evitando por completo los hilos de PHP para las solicitudes que se pueden almacenar en caché. Eso libera capacidad de PHP para las solicitudes que realmente la necesitan. En el caso de las páginas dinámicas que no se pueden almacenar completamente en la caché, el almacenamiento en caché de objetos de Redis reduce la carga de la base de datos al guardar los resultados de las consultas en la memoria, de modo que PHP no tiene que volver a consultar la base de datos en cada solicitud.
Como Edge Caching y Redis evitan que muchas solicitudes pasen por PHP, los hilos de PHP restantes quedan libres para las cargas de trabajo que realmente los necesitan. Para los equipos que gestionan sitios web complejos de WordPress, Kinsta te ofrece visibilidad y control sobre el rendimiento de PHP directamente en MyKinsta, lo cual resulta especialmente útil cuando las cargas de trabajo incluyen páginas de WooCommerce sin almacenar en caché, áreas de membresía, contenido LMS, actividad de administración o tráfico constante que llega de forma irregular.
La visibilidad también es importante. La herramienta APM de Kinsta ayuda a identificar cuellos de botella en el rendimiento de PHP, consultas lentas de MySQL, llamadas HTTP externas y otras actividades del backend que pueden afectar a solicitudes concretas. En lugar de intentar adivinar por qué una página de pago, una pantalla de inicio de sesión o el área de la cuenta van lentas, los equipos pueden investigar qué partes de la solicitud son las que más tiempo consumen.
Nada de esto elimina la necesidad de tener una buena arquitectura del sitio, un código limpio, plugins optimizados y reglas de almacenamiento en caché sensatas. Pero ofrece a los equipos de WordPress una base más sólida para gestionar la mezcla de tráfico que reciben los sitios web reales: visitantes con contenido en caché, solicitudes sin caché, sesiones de usuario, tareas de administración y tráfico constante que no siempre llega de forma ordenada o uniforme.
Las medias rápidas no garantizan experiencias rápidas
La velocidad media puede ser útil, pero no debería ser la única cifra que guíe tus decisiones de alojamiento.
Un sitio web puede parecer rápido en una prueba de rendimiento y, aun así, frustrar a los usuarios cuando el proceso de pago se ralentiza, las páginas con sesión activada van con retraso, la búsqueda tarda demasiado o el envío de un formulario se queda colgado.
Puede que esos momentos no arruinen tu puntuación media de rendimiento, pero sí pueden influir en la opinión que la gente se forma de tu sitio web.
La consistencia es el objetivo más práctico: un rendimiento de WordPress que se mantenga tanto en páginas almacenadas en la caché como en solicitudes dinámicas, actividad de administración y tráfico constante.
Que sea rápido de media no es lo mismo que rápido para el usuario que está listo para convertir.
Si estás listo para un alojamiento de WordPress diseñado en torno a un rendimiento constante, echa un vistazo a los planes de alojamiento administrado de WordPress de Kinsta.
