DEV Community: gonzalo

Qué es el Critical Rendering Path y cómo optimizarlo

gonzalo — Mon, 02 Dec 2024 17:54:41 +0000

¿Qué es el Critical Rendering Path?

El Critical Rendering Path es la secuencia de fases por las que pasa el navegador para convertir el HTML, CSS y JavaScript en píxeles en la pantalla:

Parsea el HTML en el DOM (Document Object Model).
Parsea el CSS en el CSSOM (CSS Object Model).
Ejecuta scripts.
Calcula el tamaño y posición de los elementos en la pantalla.
Renderiza la página.

Estos pasos afectan directamente al rendimiento de nuestra web, por lo que habrá cosas que tenemos que tener en cuenta si queremos optimizar este proceso.

Construyendo el DOM

El navegador recibe el HTML a través de una llamada HTTP. En cuanto lo recibe empieza a construir el DOM con esos datos.

Este DOM se construye a base de nodos, cada etiqueta de HTML equivaldría a un nodo, y elementos hijos en el HTML también serían nodos hijos en el árbol del DOM.

A mayor número de nodos, más tardará en completarse el proceso de renderizado de la página.

CSS Object Model

Mientras el DOM contiene toda la información del contenido de la página, el CSSOM contiene toda la información sobre cómo se va a ver ese contenido.

El procesado de CSS bloquea el renderizado. Es decir, que hasta que no se procese por completo no se puede continuar con futuros pasos para mostrar finalmente el contenido en la pantalla. Esto se debe a que puede darse el caso de que en un archivo de CSS se sobreescriban los estilos que se han aplicado unas líneas más arriba.

Render tree

Una vez tenemos el DOM y el CSSOM listos, estos se combinan dando como resultado el "Render tree", que tendrá toda la información necesaria de los elementos que aparecerán en pantalla. En este árbol quedarán excluidos aquellos elementos como todo lo que tenga display: none; y sus descendientes o todo aquello que se encuentre en la etiqueta <head>.

Layout

En la fase de "Layout" se define el tamaño de los elementos del render tree y su relación con otros elementos. Este proceso es dependiente de la pantalla en la que se esté visitando la página web.

Si no se especifica, los elementos ocuparán por defecto el 100% del ancho del padre, que en algunos navegadores es un ancho fijo. Es por eso que es necesario incluir este elemento en la etiqueta <head> de nuestro documento:

<head>
    <meta name="viewport" content="width=device-width" />
</head>

Cada vez que un usuario rota su dispositivo móvil, el proceso de Layout se vuelve a ejecutar, ya que los elementos y su disposición en la pantalla pueden potencialmente cambiar.

El Layout puede afectar al rendimiento de una web, ya que a mayor número de nodos, más tardará este proceso en finalizar. Un proceso de Layout lento puede ocasionar que algunas animaciones no se vean bien, además de provocar que la primera carga de la página sea más lenta.

El pintado de la página

El pintado de los píxeles en la pantalla es el último paso del proceso de renderizado. Es un paso rápido, ya que después de la primera carga (onload) ya solo se repintarán aquellas zonas de la página que hayan sufrido cambios, los navegadores ya están optimizados para evitar realizar este proceso de manera innecesaria.

Optimización del CRP

Este proceso puede optimizarse de distintas maneras, pero cada caso es único y al final lo importante es que apliques en tu proyecto aquellas medidas que mejor le vengan.

Carga de recursos críticos tan pronto como puedas

La idea es que el navegador descargue recursos como imágenes, estilos, scripts, etc que sean cruciales para la página tan rápido como sea posible, por lo que convendría poner esos elementos lo más arriba posible en el <head>.

Incluso si son scripts o estilos más pequeños pueden ir en etiquetas en línea.

<head>
    <style>
        .foo {
            color: red;
        }
    </style>
</head>

Por otra parte, si lo que estás cargando es un script que modifica algún elemento del DOM, la idea sería cargarlo una vez ya se ha construido el árbol con todos sus nodos. Es en esos casos en los que sería necesario cargar ese script al final del todo en la etiqueta body.

<html>
    <body>
        <!-- My content -->
        <script src="./path/to/my/script.js"></script>
    </body>
</html>

Posponer carga de scripts

Posponer la carga de scripts que no modifican el DOM es una muy buena práctica para reducir el tiempo de carga de la web. Esto se puede hacer a través de los atributos "async" y "defer".

Poniendo un script como async hará que este script se descargue y ejecute de manera independiente, por lo que no bloquearía el proceso de renderizado y el momento de la ejecución es arbitrario.

Un script con el atributo defer se descargará de manera asíncrona, pero respeta el orden en el que se ubica en el documento. Es también una buena forma de controlar que un script pequeño se ejecute después de un script más grande.

<html>
    <body>
        <script src="./very-big-file.js" async></script>
        <script src="./big-file.js" defer></script>
        <script src="./small-file.js" defer></script>
    </body>
</html>

En el ejemplo de arriba los tres scripts se descargarán de manera asíncrona. Asumimos que el último script se descargará primero, ya que es más pequeño. El primer script se descargará y ejecutará de manera totalmente independiente, ni espera a otros elementos para que estén listos ni bloquea el proceso de renderizado. En cualquier caso, el último script se ejecutará después del segundo, ya que el atributo defer respeta el orden.

Separación de estilos con media queries

La idea sería cargar únicamente los estilos que se vayan a necesitar en pantalla, por lo que una técnica que podría ayudar a la optimización del rendimiento sería separar los estilos de la página en distintos archivos en función de si van a aplicar a móviles, tablets, escritorio, etc. En el HTML se cargarían estos archivos con media queries, evitando la carga innecesaria de estilos.

<html>
    <head>
        <link rel="stylesheet" type="text/css" media="screen" href="sans-serif.css" />
        <link rel="stylesheet" type="text/css" media="print" href="serif.css" />
    </head>
</html>

Minificar recursos

Aunque parezca una tontería, minificar los archivos puede ayudar considerablemente a la mejora del rendimiento de una página, ya que eliminando espacios en blanco, comentarios, etc puede reducir el trabajo que tiene que hacer el navegador para construir el render tree.

Conclusiones

Esto son solamente unas pocas cosas que se deben tener en cuenta para optimizar este proceso. Teniendo esto en mente es más viable poder escribir código de calidad que ya esté pensado para optimizar el Critical Rendering Path.

Import aliases en tu aplicación de NodeJS

gonzalo — Thu, 04 Apr 2024 15:26:57 +0000

Hay ocasiones en las que nuestra aplicación crece y los imports acaban siendo algo feos y liosos, como estos:

import GenericRepository from '../../../shared/generics/generic.repository'

Esto puede llevar a confusiones si crece demasiado. Afortunadamente hay medidas que se pueden tomar para evitar que esto ocurra y que nos queden unos imports así de claros y bonitos:

import GenericRepository from '@generics/generic.repository'

¡Mira que bien se ve! Ahora te explico cómo usar correctamente estos imports.

Implementación

Asumiendo que estás utilizando TypeScript en tu aplicación, tendrás un archivo llamado tsconfig.json en el root de tu proyecto. Este archivo lucirá de una forma similar a esto:

{
    "compilerOptions": {
        // tu configuración
    }
}

Dentro de las compilerOptions vamos a definir nuestros path aliases. ¿Cómo? Pues lo primero que necesitamos es saber cuál es nuestra baseUrl. A mí personalmente me gusta meter toda la chicha en la carpeta src , por lo que mi baseUrl será así:

{
    "compilerOptions": {
        "baseUrl": "./src"
    }
}

Si no tienes o no utilizas la carpeta src de esa manera no te preocupes, puedes configurar la baseUrl a un punto sin más, o a cualquier otro valor que aplique a tu proyecto. Aquí un ejemplo que muestra cómo sería la baseUrl basándose en el root del proyecto:

{
    "compilerOptions": {
        "baseUrl": "."
    }
}

Una vez tenemos la baseUrl, ya podemos definir nuestros path aliases. ¡Olé!

Path aliases

root
- src
- api
- shared
  - generics
  - utils

Dentro de la carpeta src están las carpetas api y shared . Los import aliases que quiero configurar son para poder importar los archivos que estén dentro de la carpeta de generics y utils.

Venga, ya lo importante. Aquí te muestro cómo quedaría nuestro tsconfig.json:

{
    "compilerOptions": {
        "baseUrl": "./src",
        "paths": {
            "@utils/*": ["shared/utils/*"],
            "@generics/*": ["shared/generics/*"]
        }
    }
}

De esta forma podremos importar nuestros archivos de una forma mucho más limpia. Así nos quedarían los imports ahora:

import GenericRepository from '@generics/generic.repository'

Solución de problemas

¿Cómo? ¿En el editor parece que te va todo bien pero en la consola te salta el siguiente error?

Error: Cannot find module '@generics/generic.repository'

¡No te preocupes! Aún nos queda un paso extra. Principalmente si estás utilizando la librería ts-node .

El editor sabe que estás usando estos import aliases, pero para que funcione correctamente tenemos que ir poco más allá. Gracias a la librería tsconfig-paths podemos hacer que nuestros bonitos imports funcionen a la perfección.

Solo tendríamos que instalarla corriendo el siguiente comando:

npm install--save - dev tsconfig - paths

Y luego tendríamos que incluir esto en el script de ejecución de nuestra aplicación en el package.json:

-r tsconfig - paths / register

En mi caso, el script quedaría así:

{
    "scripts": {
        "dev": "ts-node-dev -r tsconfig-paths/register --env-file=.env.development index.ts"
    }
}

Conclusión

Es bastante útil tener unos imports bien claros y lo más limpio posible. ¿Por qué? Pues porque ayuda a la lectura del código y evita tener ruido en nuestros archivos. Tanto tú como la gente que trabaje contigo lo agradeceréis.

Además, creo que la ganancia de hacerlo en relación al esfuerzo que supone hace que merezca mucho la pena.

¡Si tienes cualquier pregunta o comentario, no dudes en ponerlo por abajo!

¡Saludos!

My first Angular Project!

gonzalo — Fri, 24 May 2019 09:06:42 +0000

A year ago, I started to study code online, and now I'm working in an English Academy as developer.

After three months of hard work, we finally achieved our main goal, what was release the first viewable version. The next step is keep improving the website, as it still has some errors.

The point is, this is my first Angular project and my first big project as well, so I'm very happy and I just wanted to share it with you!

Here's the link in case you want to check it out: https://www.americanlanguage.es/

Thanks!