Qué es un waterfall y como leerlo 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.

¿Qué es un 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.

Partes de una petición

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:

1. DNS lookup

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

2. Inicial connection

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.

3. Negociación SSL

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.

4. TTFB

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.

5. Content download

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.

Partes de un Waterfall

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:

1. Star render (first paint)

El tiempo que tarda el navegador en mostrar el primer Pixel de contenido en pantalla.

Básicamente cuando el contenido empieza a mostrarse en el navegador del usuario, pero no implica que el primer contenido que aparece en primer lugar en pantalla es útil o importante, o simplemente anuncios u otros recursos.

2. Dom Content Loaded

Después de que el navegador haya recibido el html se parsea al DOM, que es una representación virtual de la estructura de la página.

3. On load

El tiempo entre el inicio y el final de la carga. El navegador finaliza el evento cuando el DOM este listo y todas las imágenes cargadas. Esta info puede ser útil para ver cómo se carga contenido below the fold.

4. Document Complete

El tiempo que tardan la mayoría de los recursos de la página en renderizar en el navegador, se tiene en cuenta el "onLoad" que activa el navegador después de que la mayoría de los recursos de la página se han cargado completamente. En otras palabras, el tiempo de la carga completa, aunque es una métrica inexacta y por eso se usa Fully Loaded, que es el momento en que se han cargado todos los recursos de la página, incluidas las etiquetas de terceros que no son visibles y la página está completa.

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

Lo que vemos aquí es que el DOM se ha cargado tras los 0,8 segundos y el documento completo, transcurrido los 2,0.

Solo se observa un recurso js que se demora más en cargar.

Colores del Waterfall

Sobre los colores del diagrama, tenemos que diferenciar varios aspectos.

Por una parte, los recursos resultantes del análisis, en las filas, pueden arrastrar errores o tener status codes diferentes.

Errores en rojo

Por ejemplo cuando la url o recurso responde 404 o 500, la fila entera se marcará en rojo, para su rápida identificación.

Redirecciones en amarillo

La url alternativa se muestra y el navegador ha de intentar de nuevo la petición , retrasando el tiempo de carga del recurso. Como todos sabemos, cada redirección añade un tiempo de procesamiento que influye de forma directa en el rendimiento, por lo que tanto recursos internos como externos, que sufran redirecciones, nos impactarán.

Caché en amarillo

En segundos test con repeat view, algunos elementos pueden no incluir info sobre su validez, esos recursos sin cambios a veces ofrecen un 304, aunque no sea necesario, ya que la primera vez la info de cache debe es pertinente.

Por otro lado, las barras usa la herramienta, pinta distintos colores en base a los dos puntos anteriormente explicados: la conexión en franjas horizontales (además de las tipologías de contenido como html, css, js....) y las fases de la carga mediante barras verticales.

Franjas horizontales

Azul verdoso es la búsqueda DNS
Naranja es Connection
Morado es la negocación SSL

Franjas verticales

Línea verde, el Start render
Línea morada, el DOM Content Loaded
Línea azul fuerte, el Document complete

En resumen:

Los status code, errores o ineficiencias, se visualizarán con un color constante en la fila implicada.
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.
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:

número de peticiones
el tiempo que trascurre hasta el primer byte (TTFB)
el tiempo que transcurre hasta iniciar el render
el tiempo que transcurre hasta completa el documento

Para analizar de forma completa estos diagramas tenemos que tener en nuestra mente 3 puntos interesantes, que nos harán hacer una correcta lectura de estas cascadas de información, yendo más allá de los datos cuantitativos:

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.