Qué es un waterfall y cómo leerlo correctamente en Webpagetest

Continuamos la serie de post sobre Webpagetest, ya hemos visto la parte introductoria sobre qué es y para qué sirve Webpagetest y seguimos adentrándonos en la tool, explicando más a fondo la parte de cascada o waterfall.

El gráfico de cascada es cualquier diagrama que representa los datos que se generan de forma acumulativa y secuencial en todo el proceso de carga de una web, el cual, nos ofrece el rendimiento específico de los recursos necesarios entre navegador y servidor para que el usuario pueda ver una página específica.
Cada recurso de página, desde HTML a imágenes, CSS, JavaScript y otros scripts, está representado en su propia línea en el gráfico, por tanto la cascada muestra el momento en que cada recurso se llama desde el servidor, hasta el momento en que se ha descargado y procesado en el navegador.

Podemos hacer una analogía con el típico gráfico de Gantt, con un efecto que encadena unos recursos a otros, con esa forma secuencial, por lo que, por ejemplo, una página no puede comenzar a descargar recursos hasta que haya completado su conexión DNS  y haya establecido una conexión TCP.

Si nos dedicamos a SEO o al menos, nos interesa el SEO Técnico o lo relativo a Web Performance, es necesario tener un conocimiento básico de las cascadas, ya que podremos usarlas como herramienta de diagnóstico para detectar errores y aplicar mejoras.

Lo rápido o lento que carga una web es un aspecto clave en un proyecto, más aún de cara a garantizar la mejor experiencia de usuario posible y fomentar que el contenido de la web se sirva rápido para ser consumido, tanto por usuarios, como por rastreadores web como Googlebot.

Por otro lado, los aspectos relativos a rendimiento y velocidad de carga, inciden de forma directa en otros canales, como puede ser el de Pago y métricas relevantes como el quality score de Adwords.

Innegablemente el diagrama waterfall o cascada, es un informe muy valioso en web performance, ya que obtenemos visualizaciones de la actividad de la red y estas peticiones individuales, las vamos a explicar en 5 fases, que son las que tienen lugar desde que un usuario hace una petición y visualiza el contenido a través del navegador:

El tiempo en traducir el hostname a su ip. Esto suele ser corto, sería algo similar a buscar un teléfono en la guía

El tiempo del navegador en establecer una conexión con el servidor. Esto sería como llamar a un número de teléfono y esperar a que respondan.

El tiempo en ponerse de acuerdo, navegador y server, de la forma segura de comunicarse. En casos http se salta este paso, en casos https y spdy, es obligatorio.

El tiempo para que el servidor prepare la respuesta a la petición. Si seguimos con la metáfora, el tiempo que tarda en dar la primera señal. Sin duda es una de las métricas clave en performance. En palabras de Google debería estar entre 100 y 500ms, siendo 200ms una muy buena métrica.

Tiempo para que el servidor envíe el contenido de la respuesta. Es directamente proporcional al tamaño de la respuesta y a la velocidad de conexión.

Como ejemplo, en Webpagetest tenemos una visualización en la primera parte del Waterfall:

Las barras finitas al inicio de cada fila, son las que marcan qué tiempo tarda en buscar la conexión dns, conectar con el server y negociar el protocolo.

Las barras más anchas, como se ve en la imagen, hacen referencia a la tipología de contenidos de los recursos que se solicitan de cada host.

Respecto a los eventos que tienen lugar al cargar una página, consideramos 4 a nivel de página, relevantes, que serán en los que nos fijemos para hacer nuestros análisis del gráfico:

Como ejemplo, en Webpagetest tenemos esta visualización en la segunda parte del Waterfall:

Franjas horizontales

1. Los status code, errores o ineficiencias, se visualizarán con un color constante en la fila implicada.
2. Las fases de la conexión, se visualizarán con barras horizontales en distintas tonalidades, secuenciales como un flujo, junto a una simbología del tiempo transcurrido.
3. Las fases de la carga de la web analizada, se visualizarán con columnas o barras verticales de colores, que se iniciarán en distintas fases, junto a una simbología del tiempo transcurrido.

Un ejemplo de los colores, donde las líneas amarillas son las redirecciones y las franjas anchas moradas, son imágenes susceptibles de ser optimizadas. También el alto volumen de ficheros js, va retrasando la carga y sumando muchas peticiones que deben realizarse cada vez.
La franja vertical morada, marca el momento en el cual se ha cargado el contenido del DOM, en este caso tiene lugar a los 8 segundos, para acabar cargado el documento completo casi a los 12 segundos.

Análisis básico de un Waterfall

Como regla general, una buena cascada tiene pocas barras y estas son relativamente cortas, lo cual nos indica que la página es «delgada» y que cada recurso se descarga y procesa con bastante rapidez.

Nos fijaremos pues en:

• la latencia que experimentan los recursos
• el orden en el que se cargan los recursos
• si un recurso bloque la carga de otros recursos

Una mala cascada por tanto, puede ser la que origina muchas peticiones de recursos, además de cargar los recursos de forma más lenta.
Algunos ejemplos:

 
Concluyendo:

• las líneas «start render» y «document complete» verticales deben producirse lo antes posible y deben estar tan cerca una de la otra como sea posible.
• que existan cuantas menos filas posibles.
• que existan cuantas menos barras naranjas posibles.
• el ttfb va más allá de las configuraciones del server, también tienen que ver con servir de forma eficiente contenido dinámico y tener las bbdd bien optimizadas.

Trucos finales con Webpagetest

Para acabar el post, hay algunas características que nos ayudarán a continuar con nuestros análisis:

• Exportar

• Customizar

• Tabla de detalles: es la versión numérica de lo que hemos visto en el  waterfall

• Pinchar en una fila para obtener detalles concretos

• Puntuación o Grados de Webpagetest: donde se asocian las carencias del análisis con recomendaciones a llevar a cabo respecto a compresión, caches, cdns y otros aspectos.

¡Esto es todo por hoy!
En el próximo post ya hablaremos sobre comparar test con Webpagetest