Hoy vamos a hablar de WebPageTest, una herramienta imprescindible para analizar tiempos de carga, de forma gratuita, más allá de otras tools como Pingdomtools, Gtmetrix, YSlow o Page Speed.
Por tanto hoy abrimos una serie de post sobre Webpagetest, la herramienta en la que merece la pena profundizar y que nos dará insights muy valiosos a través del análisis y seguimiento de unos KPIs de rendimiento muy útiles.
Qué es y qué mide Webpagetest
Webpagetest mide el tiempo que tarda una web en cargar, desde la primera petición, hasta que el navegador muestra el contenido al completo. O dicho de otra manera: mide cuánto tiene que esperar un usuario hasta poder usar la página.
No obstante alguna de las métricas que muestra por defecto, como «Load time», puede no representar de manera fiable o precisa el tiempo que espera el usuario.
Quizás es más sensato fijarse en la métrica «DOMContentLoaded» pues sería lo mismo que la anterior, pero exceptuando la carga de imágenes , por lo que puede ser más acertado o relevante como métrica.
Con esto hacemos una reflexión que se extiende a casi cualquier software: La métrica por defecto no es siempre la más fina para la página analizada.
Webpagetest y otras herramientas de performance buscan responder dos preguntas principales:
- Cómo de rápida es la web
- Cómo podría ser la web más rápida
En este sentido nos encontramos dos tipos de tools:
- Herramientas Synthetic
- Herramientas Real User Monitoring (RUM)
Las RUM son las más fiables, ya que se centran en la experiencia real del usuario, las sintéticas aunque pretendan acercarse a mediciones reales del usuario, están diseñadas en centrarse en el performance de una web bajo estrictas condiciones que son altamente volátiles en RUM.
Fases de Análisis con WebPageTest
La herramienta analiza sitios de forma gratuita y dicho análisis atraviesa tres fases principales:
- Waiting
- Testing
- Done
Al ser una herramienta pública puede estar siendo usada por mucha gente a la vez, por lo que la petición de análisis puede prolongarse en ocasiones, haciendo más larga la fase de waiting.
El test puede entrar «en cola» y en función de la complejidad de los test que se ejecuten delante, puede demorarse más, por lo cual su tiempo es indeterminado según el caso.
No obstante, se pueden comprobar los listados de test en cola, en webpagetest.org/getLocations.php
Con configuraciones simples, la fase de test puede durar un par de minutos y después mostrarnos el report resumido, como punto de partida de profundizar en el análisis
Tabla resumen de resultados en WebPageTest
Una vez finalizado el test, se mostrarán todas las métricas resumidas en una tabla, con los principales hitos
Load time
Tiempo desde la solicitud inicial hasta que el navegador carga. Es el document complete time
Es la métrica por defecto de la herramienta
First byte
Tiempo hasta que el servidor responde con el primer byte de la respuesta
Start render
Tiempo hasta que el navegador pinta contenido en la pantalla
DOM elements
Número de elementos en el documento
Document Complete
Time: es lo mismo que load time
Request: Número de solicitudes http antes de la carga, sin incluir la solicitud inicial.
Bytes In: tamaño total del cuerpo de las respuestas a las solicitudes de Document Complete, expresado en bytes.
Fully loaded
Time: tiempo desde la solicitud inicial hasta que WPT determina que la página ha terminado de cargar. La página ha podido esperar a cargar para aplazar la carga de contenido secundario. Ese tiempo se suma a la métrica.
Request: número total de peticiones http grabadas en el test, sin incluir la petición inicial
BytesIn: número de bytes recibidos en el test.
Después de cada análisis, WebPageTest vacía el cache de navegador para asegurarse que descarga todos los recursos, esto se considera la primera vista o «first view».
Otra configuración por defecto de WebPageTest es cargar la página una segunda vez sin vaciar el cache, esto es el «repeat view».
La diferencia entre el número de peticiones en first o repeat view, puede ser un magnífico indicador del número de elementos cacheables en la web.
Este resumen de métricas solo refleja el rendimiento de ese test aislado, a menos test, las métricas pueden verse fácilmente afectadas por fluctuaciones de la red o del server, por tanto, con test aislados, se pueden tomar por anomalías aspectos que pueden ser irreales.
Una buena práctica con WebPageTest es lanzar múltiples test y elegir el más representativo para observar las métricas, como máximo se pueden lanzar 9 veces, y para elegir en cual fijarnos podemos ordenar todos los test por una misma métrica y elegir la mediana («median run»). La métrica por defecto es «document complete time».
En esta imagen se observa un análisis basado en 3 test, tal y como se comenta:
Truco: se puede cambiar el parámetro en la url para ordenar por la métrica deseada medianMetric=bytesIn. (Ver Details Of Request In Test Results)
Después del test con WebPageTest
Después del análisis hay que tener presente que el valor real de las métricas viene de comparar con otros test configurados de forma similar. Comparar es la clave para determinar si las diferencias entre test tienen impacto positivo o negativo.
Por tanto el primer test no nos dirá demasiado, sino hacemos cambios en la web y volvemos a repetir el test.
En siguientes post seguiremos avanzando en otros conceptos como:
- Qué es un waterfall y cómo leerlo correctamente
- Cómo elegir métricas de valor
- Cómo comparar entre varios test
- Cómo simular usuarios reales
- …
Para peticiones y otras sugerencias, ¡esperamos vuestros comentarios!
Hola MJ
Quizás la complejidad de la herramienta esté en la interpretación que hagamos de los datos, es decir, cuándo es óptimo un dato y cuándo habría que mejorarlo.
Espero los siguientes capítulos a ver si nos sacas de dudas.
Por otro lado, ¿hay alguna forma de analizar toda la web y determinar las páginas que están generando mayores problemas de carga?
Saludos!
Eso es David, esta tool hay que saber entenderla y ajustar los parámetros y kpis, al proyecto en el que te encuentres. Seguiré avanzando en más claves, espero que te resulten de interés.
Respecto a analizar todo el site, yo suelo usar la api de Page Speed con Urlprofiler https://www.mjcachon.com/blog/mobile-friendly-page-speed-checker/