Una introducción al rendimiento web y la ruta de representación crítica

La mayoría de nosotros trabajamos con la web todos los días. Se ha vuelto normal para nosotros recibir toda la información que necesitamos casi al instante. Pero cómo esa página web está realmente construida y entregada a nosotros es un misterio.

A veces, las páginas web son increíblemente rápidas y, a veces, tenemos que esperar mucho tiempo para ver el contenido, lo que a menudo nos hace sentir bastante frustrados y abandonar la página. En el siguiente artículo intentaré aclarar un poco las cosas.

Descargo de responsabilidad : Toda la información que estoy compartiendo en esta publicación es lo que he aprendido a través de los cursos gratuitos mencionados en la parte inferior y resumidos aquí para cualquier persona interesada.

La ruta de renderización crítica

En primer lugar, sería útil comprender los pasos que realmente está siguiendo el navegador. Comienza con archivos HTML, CSS y JavaScript sencillos, pasa por la representación y pintura de una página, y al final llega para convertirse en lo que ve el usuario.

Estos pasos, desde sus diferentes archivos HTML, CSS y JS hasta una página pintada, se denominan comúnmente Ruta de procesamiento crítica (o CRP para abreviar).

La ruta de procesamiento crítica consta de cinco pasos diferentes, que se explican mejor en un gráfico.

Construyendo el DOM y el CSSOM

La mayoría de las páginas web constan de HTML, CSS y JavaScript, que forman una parte fundamental del CRP. Para leer y procesar su HTML, el navegador construirá el Modelo de objetos de documento (DOM). El navegador está mirando las etiquetas HTML (

,

,

y

etc.) en su marcado y los convierte en tokens que a su vez se crean en nodos en paralelo. Al procesar estos tokens de StartTag y los tokes de EndTag en orden, y ver cuáles vienen primero, el navegador puede establecer su jerarquía y establecer padres e hijos.

Sin embargo, no dejes que esta terminología te asuste. Imagine el DOM como un gran árbol con ramas que representan los nodos padres y que, a su vez, contienen hojas, los nodos secundarios. Este árbol representará las dependencias de los nodos en nuestro HTML y se parece un poco a esto:

En la imagen de arriba, podemos ver el elemento raíz que engloba a todos sus hijos, que a su vez son padres que también contienen hijos. ¡Pon eso boca abajo y se verá casi como un árbol!

El DOM representa así nuestro marcado HTML completo. Como vio, se construye de forma incremental procesando los tokens y convirtiéndolos en nodos. De hecho, podemos usar eso para nuestra ventaja devolviendo HTML parcial y dándole a nuestro usuario la indicación de que algo está sucediendo y representando en la página.

Después de construir el DOM, su navegador procesará el CSS y creará el modelo de objetos CSS (CSSOM). Este proceso es muy similar a la construcción del DOM. Pero en este proceso, a diferencia de antes, los nodos secundarios heredan las reglas de estilo de sus nodos principales, de ahí el nombre Hojas de estilo en cascada (CSS).

Desafortunadamente, no podemos procesar CSS parcial de forma incremental como podríamos hacerlo con el DOM, ya que fácilmente podría llevar a la aplicación de estilos incorrectos si un estilo predominante aparece más adelante en el proceso. Esta es la razón por la que CSS bloquea el procesamiento, ya que el navegador debe dejar de procesar hasta que reciba y procese todo el CSS.

Nuestro árbol DOM y CSSOM contendrá todos los nodos y dependencias que tenemos en nuestra página.

Clasificación de todo el contenido visible: el árbol de renderizado

El navegador necesita saber qué nodos representar visualmente en la página. El Render Tree logra exactamente eso, y es una representación del contenido visible del DOM y CSSOM.

Comenzamos a construir el árbol de renderizado identificando el nodo raíz y luego copiando toda la información visible del DOM y CSSOM. Para ello también comprobamos que buscamos etiquetas que tengan el mismo selector. Los metadatos, enlaces, etc. no se copian en el árbol de renderizado. Lo mismo se aplica a CSS que contiene "display: none;" ya que también es un elemento no visible.

Una vez que completamos este proceso, obtenemos algo similar a lo que se muestra a continuación (observe cómo no se copia el 'rendimiento web').

El árbol de renderizado es una descripción bastante precisa de lo que realmente se le muestra en la pantalla, capturando tanto el contenido como los estilos asociados. Por supuesto, esto parecería mucho más complejo en ejemplos de la vida real.

Haciendo que encaje bien - Diseño

Si bien ahora sabemos lo quenecesitamos mostrar y renderizar en la página, es importante saber cómo se renderiza. Para que el diseño se vea correcto, necesitamos saber el tamaño del navegador. Nuestro diseño depende de ello para calcular las posiciones y dimensiones correctas para todos nuestros elementos en la página.

Todo esto sucede durante el paso Diseño. Tener en cuenta el paso de Diseño es especialmente importante para dispositivos móviles, donde nuestro punto de vista puede cambiar cuando cambiamos entre horizontal y vertical cuando giramos nuestros teléfonos. Esto significa que el navegador necesitaría volver a ejecutar el paso de diseño cada vez que giráramos nuestro teléfono, lo que podría ser un cuello de botella de rendimiento.

Pintar los pixeles

Este paso implica pintar los píxeles en la pantalla, especificado por qué (Árbol de renderizado) y cómo (Diseño). El paso de pintura incluye la pintura real de píxeles (por ejemplo, al cambiar el tamaño de una imagen) en lugar de simplemente colocarla. Es lo que finalmente ves en tu pantalla.

Resumamos

Ahora juntemos toda esta información nuevamente para que podamos ver que comprendemos todos los pasos que debemos seguir en la Ruta de procesamiento crítica (CRP).

  1. El navegador comienza construyendo el DOM analizando todo el HTML relevante.
  2. Luego procede a mirar los recursos de CSS y JavaScript y los solicita, lo que ocurre generalmente en la cabeza donde comúnmente colocamos nuestros enlaces externos.
  3. Luego, el navegador analiza el CSS y construye el CSSOM seguido de ejecutar JavaScript.
  4. Luego, DOM y CSSOM se fusionan en el árbol de renderizado.
  5. Luego ejecutamos el paso Diseño y pintura para presentar la página al usuario.

Está bien, es bueno saberlo, pero ¿por qué importa?

Ahora bien, todo esto es bueno de saber, y hemos obtenido una mejor comprensión de lo que el navegador está haciendo realmente en segundo plano. Pero, ¿por qué importa exactamente? ¿Todos necesitamos saber qué sucede debajo del capó?

¡Sí!

Si seguimos aumentando el tamaño de nuestros archivos y no prestamos atención a lo que le pedimos al navegador que muestre y pinte en la página, el navegador necesitará más tiempo para procesar todos los recursos. Por lo general, esto da como resultado una experiencia de usuario más lenta y menos agradable, lo que significa que las páginas no se podrán usar y no se mostrarán correctamente, lo que generará frustración en el lado del usuario.

Esto es especialmente cierto si solicita una página de un área rural donde la banda ancha rápida no es necesariamente la mejor.

Pero afortunadamente, hay algunas formas de evitar esto y podemos hacer que nuestras páginas sean más rápidas.

Optimización del rendimiento

Hay una serie de estrategias que podemos aprovechar para hacer que nuestras páginas sean más rápidas y mejores para nuestros usuarios. Esto es especialmente importante para los usuarios que pueden estar en ubicaciones más remotas donde Internet más rápido no es la norma o donde comúnmente se accede a las páginas a través de Internet móvil.

Cuando hablamos de estrategias de optimización, aproximadamente tenemos tres técnicas a nuestra disposición.

Minificar, comprimir y almacenar en caché

Todas estas técnicas se pueden aplicar a nuestro HTML, CSS y JS. Luego, a través de su tamaño más pequeño, reducirán la cantidad de datos que enviamos entre el cliente y el servidor. Cuantos menos bytes tengamos que enviar, más rápido obtendrá los datos el navegador y comenzará a procesar y renderizar la página.

Minimizar el uso de recursos de bloqueo de renderizado (CSS)

El CSS en sí mismo bloquea el procesamiento, como comentamos anteriormente, lo que significa que el navegador dejará de mostrar la página hasta que el CSS se haya cargado y procesado por completo.

Sin embargo, podemos mitigar archivos CSS grandes desbloqueando la representación para ciertos estilos y ventanas gráficas. Hacemos esto mediante el uso de reglas de impresión en nuestras consultas de medios, análisis y orientación del dispositivo (si desea saber cómo, le sugiero que consulte los recursos a continuación). Además, podemos reducir la cantidad de recursos que deben cargarse insertando algunos de nuestros CSS en determinadas circunstancias.

Minimizar el uso de recursos que bloquean el analizador (analizador de documentos JS)

También podemos aplazar la ejecución de nuestro JavaScript y usar atributos asíncronos en nuestro script para lograrlo. Esto significa que el resto de la página puede procesarse y, mientras tanto, el usuario ve una indicación de que algo está sucediendo en la página. También significa que no necesitamos esperar a que se cargue JavaScript.

Hablando en términos generales, eso nos deja con 3 patrones de optimización:

  1. Minimice la cantidad de bytes que envía
  2. Reducir la cantidad de recursos críticos en la ruta de representación crítica (es posible que no sea necesario cargar los análisis desde el principio cuando se crea la página)
  3. Acorte la longitud de la ruta de renderización crítica (lo que significa reducir la cantidad de viajes de ida y vuelta entre su navegador y el servidor que necesitamos para renderizar la página)

Inténtalo tú mismo

Si está interesado en probar esto y comenzar a optimizar, puede medir el rendimiento de su sitio web o de otros con varias herramientas. Los más fáciles son probablemente los productos de Google como PageSpeedInsights o Google Lighthouse, una pequeña y práctica extensión de Google Chrome que puede instalar fácilmente a través de la tienda de aplicaciones de Chrome.

Simplemente haga clic en la extensión y luego genere un informe y obtendrá un informe que incluye lo siguiente:

Luego, puede comparar su rendimiento con una serie de métricas, como First Pixel Painted to the Screen, First Interactive, Visual Completeness of your site, y muchas otras.

Las herramientas de desarrollo de su navegador favorito también son un gran lugar para buscar en términos de averiguar los tiempos de carga y los cuellos de botella de rendimiento. Mantener bajos los tiempos de carga generales definitivamente aumentará la velocidad general a la que se ofrece su sitio a los usuarios finales.

Conclusión

Con suerte, esto ha arrojado algo de luz sobre el funcionamiento interno de cómo su navegador le muestra una página y el trabajo pesado que necesita completar en segundo plano para asegurarse de que su HTML, CSS y JavaScript se estén transformando correctamente.

Ser consciente de estos pasos nos ayuda a mejorar el rendimiento de las páginas existentes. Pero también nos permite ser conscientes de cómo desarrollamos aplicaciones y sitios web y considerar cómo lucen nuestras páginas para los humanos en otras áreas del mundo.

Recursos

La mayor parte de mi conocimiento que he compartido aquí lo he adquirido a través de lo siguiente:

  1. Optimización del rendimiento del sitio web en Udacity
  2. Por qué es importante el rendimiento en los desarrolladores de Google
  3. Redes de navegadores de alto rendimiento de Ilya Grigorik (//hpbn.co/)
  4. Sitios web de alto rendimiento: conocimiento esencial para ingenieros de front-end por Steve Souders