Estas son las notas que curso de Web Performance Optimization de Udacity que ha sido publicado en Youtube y ahora forma parte del programa “Front-End Developer”.
Punto de Partida
El primer paso es tener claro el punto de partida. Necesitamos evaluar nuestra web para saber en que punto estamos y que podemos esperar de la optimización. Para ello podemos usar https://pagespeed.web.dev/
Una vez que tenemos unas métricas iniciales y el primer feedback de mejora ya podemos empezar a hacer pruebas.
Para hacer pruebas desde dispositivos moviles reales necesitamos permitir la depuración local. Dependiendo del sistema operativo debemos seguir procedimientos distintos.
No me voy a extender como conectar los diferentes dispositivos, hayq ue seguir varios pasos :
- Hay que dar permisos de desarrollador o depuración mediante USB al teléfono o dispositivo
- Conectado al ordenador, sea por cable o por wifi y confía en el dispositivo
- Desde Safari o Chrome con las herramientas de desarrollador del navegador acceder a los datos del dispositivo.
Otra opcion es hacerlo con dispositivos virtuales o con herramientas de terceros. En smashingmagazine — testing-mobile-emulators-simulators-remote-debugging tenemos una guía muy completa aunque algo desactualizada de como hacerlo. Si tienes problemas busca algún articulo mas específico para tu dispositivo.
Para hacer pruebas en IOS desde Windows puedes usar ios-webkit-debug-proxy.
Como trabaja el navegador
Para mejorar la performance de un sitio web tenemso que conocer como trabaja el navegador con los archivos que le llegan del servidor y para ello nos centramos en optimizar el “critical rendering path” que se refiere a la priorización de la visualización de contenido que hace el navegador.
The Critical Rendering Path
CRP es la secuencia que recorre el navegador para convertir HTML, CSS y JavaScript en pixeles en pantalla. Esta secuencia es lo que podemos mejorar para que las páginas se visualicen antes y esto hará que los usuarios sean mas felices.
Lo primero que hace el navegador es descargar el HTML y con ese código crear el DOM (document objects model) después busca el CSS y crea el modelo de objetos para CSS (CSSOM). Estos dos modelos se combinan para crear el árbol de renderizado (render tree). A continuación empieza la fase de diseño que es donde se decide en que zonas de la pantalla va a colocarse todo en la página (layout). Y finalmente podemos pintar los pixeles en la pantalla (paint).
El JavaScript, es la parte importante del rompecabezas del rendimiento, lo veremos mas adelante como influye en la mejora del rendimiento.
Convertit HTML a DOM
Cuando se solicita una URL en la barra de direcciones del navegador, este envía una solicitud al servidor web, el servidor web responde con un archivo HTML y por arte de magia se muestra en pantalla la página web. Pero, ¿cómo funciona realmente? ¿Que ha hecho el navegador?
El navegador lo que hace es analizar el archivo HTML y crea un árbol de objetos que representan el contenido y la estructura del documento. Este árbol de objetos se llama DOM.
El procesamiento del HTML y la construcción del DOM, esta definido en la especificación por una serie de reglas para el procesamiento de los datos.
La secuencia de pasos esta bien definida:
- Se procesa todo el HTML por secuencias
- De cada tag o etiqueta HTML el navegador genera un token que es un identificador para el elemento.
- Con cada identificador crea un objeto de nodos donde se almacena la información del elemento y cada nodo se puede relacionar con padres e hijos.
- De este objeto cuando se consumen todos los nodos se obtiene el DOM que recoge el contenido y las propiedades del HTML y todas las relaciones entre todos los nodos.
Todos los nodos del árbol DOM tendrán las mismas propiedades que atributos tiene la etiqueta HTML.
Fast Google search responses (ejemplo): El buscador de google cuando se le hace una petición el servidor lo primero que devuelve es el HTML de la cabecera para que el navegador empiece a renderizar y cuando ya tiene localizados los resultados hace el envío del HTML restante a esto se le llama “Envío Progresivo de HTML”. De esta manera le da tiempo al sevidor a buscar los resultados y al usuario le genera una sensacion de una mayor velocidad de respuesta.
Timeline traces: Explorando las trazas de la linea de tiempo: Con esto ya podemos empezar a revisar una pagina web para familiarizarnos con la consola y ver como pasan las cosas.
En las herramientas de desarrollador tenemos la pestaña “performance”, antes llamada “timeline”. Abrela haz click en el botón de grabar y recarga alguna página. Una vez grabada la carga puedes explorar la herramienta y revisa la linea de tiempo.
En la web de chrome-developer tienes una guía completa de como usar esta herramienta.
Convirtiendo CSS en CSSOM
Es similar a la conversión del DOM pero con sus peculiaridades.
- Lo primero es procesar los caracteres del CSS en busca de los identificadores, siguiendo sus reglas propias de CSS.
- Una vez localizados los identificadores o tokens es el momento en convertirlos en nodos.
— Al ir creando los nodos se irán aplicando las reglas de especificación (especificidad, herencia y cascada) de CSS.
— No se puede hacer una carga progresiva como si que podemos hacer en el HTML. Se podría hacer técnicamente, pero carece de relevancia dado que el navegador bloquea el renderizado de la página hasta que reciba y procese todo el CSS.
Puedes leer mas sobre el renderizado del CSS que bloquea la representación o sobre como Construir el modelo de objetos.
Recalculando CSS Styles en DevTools
Recuerda que puedes guardar y cargar “timelines”. Cuando quieras hacer una optimización guarda el “timeline” previo a los cambios para después poder comparar.
Para evaluar el CSS, en las herramientas de desarrollador, primero hay que encontrar la petición, en “parse HTML” encontraremos seguramente uno o varios “send Request (style.css)”. Mas abajo veremos “receive response” (style.css) y a continuación “receive data” (style.css) podemos ver un “recalculate Style” que es donde se convierte el css en el CSSOM.
El árbol de renderizado
El árbol de renderizado (The Render Tree) se podría decir que contiene todo el HTML y todo el CSS visible en la página.
El árbol de renderizado solo captura contenido visible, por lo tanto solo cuando se une el DOM y el CSSOM se puede crear el árbol de renderizado que solo contiene los nodos necesarios para representar la página, por ejemplo, un elemento que tenga definido un “display: none”, quedar fuera del árbol.
Cada nodo del árbol tendrá tanto las propiedades del HTML como del CSS que obtiene del DOM y CSSOM. Puedes leer mas en el articulo Construcción, diseño y pintura del árbol de representación.
Disposición
Aunque normalmente “layout” lo encontramos traducido como diseño yo lo veo mas claro como disposición.
El layout es el proceso de calcular la posición y las dimensiones de todos los elementos en el árbol de renderizado en la pantalla.
Un ejemplo de este calculo seria el siguiente
<meta name="viewport" content="width=device-width">Si tenemos la meta etiqueta viewport en el header el navegador calculara el ancho de la pantalla y por tanto, usando el código anterior, un body con `width:100%` medirá el ancho de la pantalla del dispositivo.
Es importante tener definido el viewport en la cabecera del HTML dado que sobre esta regla se calcula la disposición de los elementos. Podría ser, como pasaba antes, que en un momento dado un navegador tomara decisiones diferentes al resto si no esta definida esta etiqueta.
Analizando Layout
Cuando la ventana se escala, se cambia de tamaño o se gira un dispositivo. Las dimensiones de presentación cambian. El navegador debe recalcular el layout.
En el ejemplo siguiente vemos como el navegador tarda 145.324ms en calcular el layout de un total de 1483 nodos
Como se aprecia en la barra de la izquierda hay mas entradas de Layout esto es porque se ha introducido contenido nuevo o cambiado estilos y el navegador ha tenido que volver a calcular el layout.
De un modo muy general, para optimizar los cálculos de layout podemos intentar agrupar los eventos de “Recalculate Style” en menos eventos.
En este articulo puedes repasar los Conceptos básicos del diseño web responsivo o puedes leer sobre El nuevo diseño responsivo: diseño web en un mundo basado en componentes incluso puedes aprender los conceptos del diseño intrinseco en el video “Designing Intrinsic Layouts” by Jen Simmons
Pintado
Paint o pintado es el proceso de representar cada pixel en la pantalla.
No todos los pixeles cuestan lo mismo de representar en pantalla. Al igual que pasa con “Layout” cada vez que hay un cambio en el DOM o en el CSSOM el pintado se tiene que volver a calcular y el navegador va a intentar pintar la menor área posible. Pero depende de las actualizaciones que se hagan en el árbol de renderizado.
Cuando inspeccionamos vemos que hay mucho eventos de “pintado” podemos usar/jugar con la barra de tiempo para identificar los mas costosos.
En waybackmachine puedes ver una versión antigua de la web de csstriggers donde muestran que propiedades de CSS afectan al layout, paint y composite según el motor de renderizado del navegador. El repositorio de esta página es https://github.com/GoogleChromeLabs/css-triggers. Como puedes ver hay propiedades que son menos costosas en las subsecuencias como por ejemplo transform que se crea un contexto diferente al flujo normal, como si fuera un layout dentro del layout principal y esto custa menos al navegador. En el articulo ¿Qué son los layout reflow y cómo prevenirlos? podemos profundizar un poco mas sobre layout-reflow o layout thrashing.
DevTools
You can’t optimize what you can’t measure
Cuando analizamos una página lo primero que vamos a ver es la solicitud del documento HTML, después la respuesta y a continuación los datos recibidos.
Después veremos como el navegador hace el “parsing” del HTML (parse HTML), es donde convierte los bytes recibidos en el árbol DOM.
A medida que encuentra otros elementos como una imagen, comienza la petición y continua con el evento de “Parse”. Cuando llega al final, ya tiene construido el DOM y comienza con a construir el CSSOM, esto aparecerá como un evento “Recalculate Style”, si el estilo esta en el HTML lo hará directamente, si esta en un archivo externo tendrá que hacer la petición primero. Después aparecerá el evento “Layout” dado que ya ha construido el árbol de renderizado y finalmente veremos un evento de “paint”.
Continuara…
Para que no se atragante demasiado el articulo lo he dividido en dos post. Puedes continuar con la lectura de “Apuntes sobre WPO — Optimizando el Critical Rendering Path”
