¿Cómo afecta el Critical Rendering Path a tu WPO?

Una de las métricas que se utilizan para decir si una página es rápida o no es la que mide el tiempo total de carga de la página web.

Aunque válida, esta métrica, desde el punto de vista del usuario, no es realmente importante.

Nuestros usuarios lo que quieren es que cuando acceden a nuestra página, ésta cargue el contenido visible rápidamente y pueda interactuar con sus elementos lo antes posible.

No es necesario para el usuario que absolutamente todo el pie de la página esté cargado para que pueda añadir un producto a su carrito por ejemplo.

¿Qué es el Critical Rendering Path?

Sencillamente es la secuencia de pasos que sigue nuestro navegador para convertir los elementos html, css y javascript en la página renderizada final.

Entonces, si nos centramos en optimizar estos pasos, conseguiremos mejorar sobremanera el desempeño de nuestra web.

¿Qué pasos son?

Cuando el navegador solicita una página a nuestro servidor, este le devuelve el documento html. El navegador inicia el primer paso con el procesamiento documento que ha recibido para primero de todo construir el árbol DOM (Document Object Model).

Convierte las etiquetas de HTML en nodos de un árbol. Cuanto mayor es este árbol mayor será el tiempo de proceso en general. Una métrica que vemos tanto en Page Speed Insight como en WebPageTest es el número de nodos. Demasiados nodos incrementa la complejidad y tiempo de visualización.

A su vez va obteniendo todos los recursos derivados, CSS, Javascripts, imágenes, etc. Cuando acaba de procesar el HTML y finaliza el DOM, comienza el segundo paso. Generar el CSS Object Model. Esto es lo mismo que un DOM pero para los estilos también en forma de árbol.

Cuando tiene ambos, el navegador avanza al tercer paso. Genera el Render Tree, calculando el estilo final de todos los elementos visibles. Utiliza el DOM y el CSSOM calculando qué estilos aplican a cada uno de los nodos visibles. Los invisibles no están dentro del Render Tree.

El cuarto paso, Layout, consiste en, una vez completo el Render Tree y en base a la pantalla dispositivo, ver donde ha de colocar los elementos, que altura, que ancho, que relación entre los elementos, (arriba, por debajo, etc.)

Este punto es el más complejo de todos y en el que si tenemos demasiados elementos en la página puede ser el que provoque el mayor retardo.

Finalmente el último paso, el quinto. Una vez calculado el layout, simplemente comienza a pintar los píxeles la página en la pantalla del dispositivo.

¿Cómo podemos optimizar este proceso?

Tenemos que intentar enfocarnos en tres puntos concretos.

1. El número de elementos críticos
2. La longitud del Critical Path
3. El número de bytes críticos

Un elemento crítico es aquel que bloquea el renderizado del html. Por ejemplo el javascript. Haciendo estos cargar en modo async o si es posible eliminandolos. No siempre se usan todos los Javascript en todas las páginas.

Elementos que dependen unos de otros para generar la página hacen que no sea posible la paralelización. Intentemos minimizar este efecto reorganizando el código de la página haciendo que primero cargue todo el contenido crítico.

Reducir el número de bytes críticos haciendo que los elementos críticos dejen de serlo, ej. async de script, o bien reduciendo el código para que descargue antes.

Conclusiones

Sabiendo como el navegador convierte el texto en el resultado final podemos atacar los puntos críticos para conseguir que nuestro usuario perciba una mejora en la carga de la página.

Reducir el total de elementos, el tamaño de los mismos y controlando el orden de carga conseguiremos grandes resultados.