Prueba de rendimiento de WordPress: cómo evaluar el rendimiento del alojamiento de forma reproducible

Qué nos revela una prueba de rendimiento de WordPress

A Comparativa de WordPress Comienza con una pregunta concreta: ¿se carga rápidamente una página determinada en unas condiciones específicas? Para ello, el navegador carga el código HTML, las imágenes, los scripts y otros recursos, y muestra la página. El resultado describe la interacción de estos componentes, no solo la velocidad del servidor de alojamiento.

Una segunda pregunta se refiere a... Comportamiento de respuesta bajo carga: ¿Cómo varían los tiempos de respuesta y los errores cuando llegan solicitudes que se ajustan a un perfil determinado? Una sola visita a la página no basta para responder a esta pregunta. Por el contrario, una prueba de carga HTTP no muestra de forma inmediata la rapidez con la que un navegador carga la página completa de forma visible.

En el caso de una entrada de blog pública, una caché de página puede proporcionar código HTML ya generado; una CDN puede ofrecer recursos o respuestas más cerca de la ubicación de medición. Al mismo tiempo, el tema, los plugins, las imágenes y los scripts externos influyen en el resultado. En el artículo sobre... se explican otras causas que pueden ralentizar una página. Factores ocultos que merman el rendimiento de WordPress.

Para evaluar la influencia del alojamiento web, resultan útiles dos preguntas comparativas. En el caso de Comparación de pilas Ajusta el sitio web y la configuración en la medida de lo posible y documenta las diferencias que queden. Al comparar los paquetes, comprueba las configuraciones ofrecidas, incluidas sus respectivas cachés y servicios. Esto resulta útil a la hora de tomar una decisión de compra, pero no aísla el rendimiento puro del servidor.

Por lo tanto, toma nota de qué página, qué tarifa y qué entorno corresponden a cada resultado. Una ventaja para el artículo del blog analizado puede variar si se consulta desde una cuenta registrada. La medición es válida para las condiciones y el periodo documentados; no constituye ni un ganador general de la prueba ni una garantía de rendimiento.

Comprender las mediciones del navegador y los datos de campo

Una prueba de velocidad de WordPress con Lighthouse ofrece un Fotografía de laboratorio de la página en determinadas condiciones de medición. Por lo tanto, en el registro deben figurar el perfil del navegador, el dispositivo o la emulación, el perfil de red, la ubicación de la medición y la versión de la herramienta. Solo así se podrá evaluar posteriormente si dos ejecuciones son realmente comparables.

La puntuación de rendimiento de Lighthouse resume varios parámetros de forma ponderada. Puede variar debido a cambios en los contenidos y en las condiciones de medición, y no permite identificar qué parámetro concreto ha cambiado. Repite la medición con el mismo perfil y documenta los valores individuales de todas las ejecuciones, en lugar de seleccionar únicamente la mejor puntuación.

Entre los parámetros importantes se encuentra el LCP: describe cuándo se carga de forma visible el elemento de contenido más relevante. El CLS registra los desplazamientos inesperados del diseño durante el uso. El INP describe la capacidad de respuesta ante las interacciones; para ello, requiere interacciones realmente registradas y no viene determinado únicamente por una simple carga de la página.

Por su parte, el Chrome UX Report, o CrUX, proporciona, cuando está disponible, Datos de campo de las visitas de usuarios reales participantes. Estas experiencias dependen, entre otras cosas, de sus dispositivos y redes. No están disponibles para todas las páginas y responden a una pregunta diferente a la de una prueba de laboratorio realizada en condiciones controladas.

Indica para cada valor si procede del laboratorio o del entorno real. Una consulta HTTP pura, por ejemplo, puede registrar el estado y el tiempo de respuesta, pero no ejecuta automáticamente la visualización ni las interacciones de un navegador. Por lo tanto, a partir de ella no se pueden interpretar el LCP, el CLS y el INP como parte de la experiencia del navegador.

Distinguir correctamente los niveles de caché

A Caché de página puede almacenar código HTML ya generado para solicitudes repetidas. Por su parte, una caché de objetos almacena los datos de la aplicación que WordPress necesita durante el procesamiento. Además, el navegador puede reutilizar localmente los recursos ya cargados; una CDN puede almacenar temporalmente el contenido en un nivel adicional, fuera del servidor original.

En el caso de una caché de páginas «caliente», se accede repetidamente a una página pública tras un periodo de calentamiento documentado. Esto es relevante para los contenidos más visitados, pero no dice mucho sobre el coste que supone su generación dinámica. Anota qué URL se ha calentado y qué reglas de caché y ajustes de CDN se han aplicado.

Para una solicitud sin caché, debes utilizar el Desvío de caché Compruébalo de forma rigurosa, en lugar de limitarte a darlo por bueno. Una sesión registrada puede seguir otras reglas y ofrecer contenidos personalizados. Comprueba cuál es la respuesta real: una consulta rápida no sirve de mucho si ofrece un contenido erróneo u obsoleto.

Una primera visita en un nuevo estado del navegador no implica que la caché del servidor o de la CDN esté vacía. Del mismo modo, un fallo de la CDN no significa automáticamente que la caché de la aplicación se haya vaciado. Los encabezados de caché pueden ofrecer pistas, pero, dependiendo del proveedor, no prueban el estado de cada nivel implicado; por lo tanto, documenta también la configuración disponible y los métodos de comprobación.

En principio, la caché de objetos de WordPress, si no cuenta con una extensión persistente adecuada, se limita a la solicitud correspondiente. La constante WP_CACHE Por sí solo, no activa ni Redis ni una solución de almacenamiento en caché automática. El artículo sobre Redis y Memcached en el alojamiento de WordPress.

Preparar la conciliación y las autorizaciones

Para comparar servicios de alojamiento web, lo primero que necesitas es un estado comparable del sitio web. Crea una copia depurada con el mismo contenido, el mismo conjunto de datos, el mismo tema y los mismos complementos, incluidas sus versiones. Elimina o sustituye los datos personales y las credenciales de acceso de producción, de modo que la página de prueba siga reflejando el caso de uso deseado.

Utiliza, en la medida de lo posible, las mismas versiones de PHP y de la base de datos, así como la configuración pertinente. Anota las diferencias que no se puedan eliminar o que formen parte del paquete contratado. Una comparación de los paquetes estándar respectivos responde a una pregunta diferente a la de una comparación de pilas lo más homogeneizada posible: el resultado no se puede atribuir sin más únicamente al rendimiento del servidor.

Antes de la primera ejecución, elabora un plan de medición. Debe ser lo suficientemente concreto como para que otra persona pueda comprender la configuración e identificar las desviaciones en caso de repetirla. La siguiente lista de comprobación distingue las características de la oferta de alojamiento de las del sitio web y de la medición.

• Plan de tarifas, límites de recursos, ubicación del servidor y versiones de software de ambos entornos.
• URL de prueba y tipos de página, estado de inicio de sesión, cookies y cuentas de prueba utilizadas.
• CDN, caché de páginas y caché de objetos, incluidas las reglas, la fase de calentamiento y el bypass programado.
• Lugar de medición, versión de la herramienta, perfil del navegador y del dispositivo, condiciones de red, momentos y repeticiones.
• Perfil de carga, responsabilidades, ventana de pruebas acordada y límites concretos de interrupción.

Para las pruebas de carga, debes acordar la Publique Consulta con todos los responsables y, si procede, con el proveedor de alojamiento, antes de generar carga. Aclara quiénes son las personas de contacto, cuáles son los límites de recursos y cuál es el procedimiento en caso de incidencias. Excluye los servicios externos sin su consentimiento; evita, en particular, los pagos reales, los pedidos y las notificaciones. Comprueba de antemano si la copia de prueba impide realmente dichas operaciones.

Concepto de medición para páginas típicas

Elige la herramienta en función de la pregunta, no en función de obtener el mejor valor individual posible. Una Concepto de medición asigna a cada fila un tipo de página y un estado de caché. La tabla muestra qué resultados se pueden obtener con cada uno de los enfoques y cuáles son sus limitaciones.

Para un artículo de blog público, mide la misma URL representativa varias veces utilizando un perfil fijo de navegador y red. Anota si el CDN y la caché de página están activados y cómo se ha precargado la página antes de las pruebas. De este modo, se puede evaluar la experiencia de carga de esta página pública, y no automáticamente la de una sesión con usuario registrado.

Cada búsqueda dinámica o vista de cuenta cuenta con su propia serie de pruebas, con datos de prueba compartidos y, si es necesario, una cuenta de prueba. No te limites a comprobar el código de estado: la respuesta debe coincidir con la consulta de búsqueda o con la cuenta en la que se ha iniciado sesión, y debe estar actualizada. Comprueba además si hay alguna Desvío de caché funciona realmente; una cookie por sí sola no lo demuestra.

El hecho de que los tiempos de respuesta varíen no significa que se haya identificado la causa. La lógica de la aplicación, los accesos a la base de datos, una caché de objetos persistente y el entorno de alojamiento pueden influir en el resultado. Documenta las diferencias en la estructura y, a continuación, analízalas de forma específica, en lugar de considerar una única consulta lenta como prueba de un cuello de botella concreto.

Aumentar la carga de forma controlada

Empieza en una página de prueba expresamente autorizada con unas pocas consultas aisladas. Comprueba el estado y el contenido, y asegúrate de que no se produzcan efectos secundarios en el entorno productivo. Solo después se llevará a cabo una prueba de carga acordada por separado, por ejemplo, para las páginas de productos autorizadas de una tienda. Quedan excluidos los pedidos, pagos y notificaciones reales.

Organiza una carga gradual con el nivel inicial, la duración y los incrementos. Acuerda de antemano unos límites de interrupción cuantificables en cuanto a errores, tiempos de respuesta u otros parámetros operativos disponibles, así como una persona de contacto en caso de interrupción. Limítate a los procesos expresamente permitidos; una vista previa del producto no ofrece información sobre un proceso de pago que no se haya probado.

En el modelo de carga cerrada, una instancia virtual de usuario espera a que finalice su iteración actual antes de comenzar la siguiente. Si la aplicación se ralentiza, la carga ofrecida puede disminuir como consecuencia de ello. El modelo es adecuado para procesos en los que precisamente esa espera forma parte del proceso; sin embargo, no mantiene una tasa de llegada fija.

A modelo de carga abierto Por el contrario, planifica nuevas iteraciones independientemente de si las anteriores se han completado. Para ello, el generador de carga debe disponer de suficiente capacidad y de instancias virtuales de usuario disponibles. Si no puede iniciar las iteraciones, la prueba no alcanzará el perfil previsto; por lo tanto, documenta también estas iteraciones que no se han iniciado.

Anota tanto la tasa configurada como la realmente alcanzada. Las iteraciones por segundo solo equivalen a solicitudes por segundo si cada iteración genera exactamente una solicitud. Además, registra la distribución de los tiempos de respuesta, los errores y los tiempos de espera, así como la comprobación de que el contenido sea correcto: un alto rendimiento con respuestas erróneas no constituye una prueba de carga satisfactoria.

Evaluar las series de mediciones de forma transparente

Una serie de mediciones solo es significativa si se tiene en cuenta su alcance. Por eso, anota para cada página probada y cada paso de carga el número de solicitudes evaluadas, así como el número de errores y tiempos de espera agotados. Distingue las respuestas correctas de las fallidas, sin omitir los fallos en el informe: un tiempo de respuesta bajo con muchos errores no indica que el servicio sea fiable y rápido.

El Mediana describe el valor medio de las mediciones correctas ordenadas. El percentil 95, abreviado p95, indica además un umbral por debajo del cual se sitúan aproximadamente el 95 % de estos valores de medición. Cuando el número de consultas es reducido, el p95 depende en gran medida de observaciones individuales; por ello, indica siempre el tamaño de la muestra e interpreta las diferencias con cautela.

Anota también, para cada ejecución, el modelo de carga y la tasa realmente alcanzada. Una tasa configurada por sí sola no indica si el generador ha podido iniciar todas las iteraciones previstas. La siguiente plantilla permanece en blanco hasta que se realice la medición; cada ejecución cuenta con su propio registro.

Guarda los datos brutos, el script de prueba y la configuración junto con el registro. De este modo, más adelante se podrá comprobar qué consultas se incluyeron en el análisis y si dos series son realmente comparables. No te limites a seleccionar a posteriori solo la ejecución más rápida: si los resultados se solapan en gran medida, la diferencia observada puede estar dentro de los márgenes de variación.

Además de los indicadores clave, incluye también anomalías en el contenido, como, por ejemplo, una página de inicio de sesión inesperada en lugar de la vista de la cuenta prevista. Un estado técnico satisfactorio no garantiza por sí solo que se haya mostrado la página correcta. Estas desviaciones deben incluirse por separado en la descripción del error y pueden hacer que una serie de mediciones resulte inservible para la decisión prevista.

Identificar las causas y volver a realizar la medición

Empieza a buscar el error en la respuesta recibida: ¿coinciden el contenido, el estado de inicio de sesión y la URL probada? A continuación, comprueba lo documentado Estado de la caché y el entorno de medición. Unas cookies diferentes, una ubicación de medición distinta o un cambio en una regla de CDN pueden hacer que dos ejecuciones sean diferentes, sin que haya variado el rendimiento de la pila de aplicaciones propiamente dicha.

Solo entonces los datos operativos disponibles ayudan a delimitar el problema: la ocupación de recursos y las colas de espera pueden indicar cuellos de botella, mientras que la información de la aplicación o de la base de datos puede apuntar a un procesamiento que requiere mucho tiempo. Un único valor HTTP lento no identifica la causa. WordPress señala, además del alojamiento, el software, la configuración y los contenidos como factores que influyen.

Para realizar una comparación «antes y después», cambia deliberadamente solo un parámetro, como la integración de una caché de objetos persistente. El estado del sitio web, la página de prueba, el perfil de carga y la ubicación de la medición deben permanecer lo más iguales posible; documenta también el tiempo de calentamiento de la caché correspondiente. Sin una implementación persistente adecuada, la caché de objetos de WordPress se limita a cada solicitud individual, por lo que es necesario comprobar su integración efectiva.

Realiza varias pruebas antes y después del cambio y espácialalas en el tiempo. Así podrás detectar mejor si una diferencia se repite o si podría deberse a fluctuaciones normales. No te limites a comparar la mediana y el percentil 95, sino también los errores, el contenido de las respuestas y la tasa alcanzada; de lo contrario, una aparente aceleración podría deberse a un cambio en las condiciones de la prueba.

Ni siquiera una comparación minuciosa permite controlar todos los factores que influyen. En el caso del alojamiento compartido, otros usuarios y una infraestructura a la que no se tiene acceso pueden influir en el resultado. Si te faltan datos sobre los recursos o las colas, señala expresamente esta laguna y formula una causa presunta como hipótesis, en lugar de como un hallazgo demostrado.

Interpretar correctamente el resultado del hosting

Toma la decisión sobre el alojamiento basándote en las páginas y los procesos que son importantes para tu sitio web. Un artículo de blog público con una caché de página activa puede generar una carga diferente a la de la visualización de una cuenta de usuario registrado. Por lo tanto, los buenos aciertos en la caché de las páginas públicas no garantizan ni respuestas personalizadas rápidas ni un proceso de pago fiable.

Antes de realizar la comparación, define qué tiempos de respuesta, índices de error y perfil de carga son aceptables para cada proceso. A continuación, comprueba si las series de mediciones documentadas cumplen estos requisitos en las condiciones acordadas. Esto incluye también que los contenidos sean correctos y que el proceso sea estable; una elevada tasa de consultas por sí sola no constituye una base suficiente para tomar una decisión.

Establecer usuarios virtuales no equivalen a visitantes reales presentes al mismo tiempo. Su comportamiento viene determinado por el guion de la prueba y el modelo de carga: en el modelo cerrado, una instancia espera a que finalice su iteración antes de comenzar la siguiente. Por lo tanto, sin un modelo de comportamiento adecuado, no es posible deducir el número real de visitantes a partir de su número.

Informa del resultado junto con la tarifa, el estado del sitio web, las URL probadas, las reglas de caché y CDN, la ubicación de medición y el periodo. Distingue, además, si has comparado pilas lo más homogéneas posible o los paquetes completos que se ofrecen en cada caso. En la comparación de paquetes, las diferencias de configuración pueden influir en el resultado; esta comparación no aísla automáticamente el rendimiento puro del servidor.

Si las series se solapan en gran medida o si no es posible controlar suficientemente el entorno, una afirmación posible y útil es que „no se ha demostrado ninguna diferencia significativa“. Esto no significa que ambas ofertas tengan la misma velocidad en todas las condiciones. Simplemente significa que la prueba en cuestión no permite establecer la distinción deseada.

Para los controles operativos, guarda el perfil de medición y repite las mediciones seleccionadas del navegador y de la carga tras cambios importantes o a intervalos acordados. Compara los nuevos resultados únicamente con series anteriores adecuadas y documenta los cambios en los contenidos, las versiones y las reglas de caché. Las pruebas de carga siguen requiriendo un intervalo de tiempo autorizado y límites de interrupción acordados.