Representación del navegador: del texto a las imágenes

📖 10min read

La pantalla que se dibuja no es mágica

Cuando comencé con el desarrollo front-end (Vue.js), pensé en el navegador simplemente como un «marco para mostrar código». Era natural que si usabas

, aparecía un cuadrado, y si usabas color: red, se volvía rojo.

Sin embargo, mis pensamientos cambiaron cuando experimenté en la práctica la animación entrecortada o las sacudidas de la pantalla al desplazarme (jank). «¿Por qué el mismo código se ejecuta sin problemas en Chrome pero falla en Internet Explorer (IE)?» “¿Por qué mi CPU se dispara cuando cambio un poco el estilo con JavaScript?”

Resulta que el navegador no es sólo un marco de imagen. El navegador era un enorme ‘pintor’ y ‘arquitecto’ que interpretaba el texto (HTML/CSS) que enviamos, calculaba matemáticamente cada píxel y lo imprimió.

La última vez, entregamos datos de forma segura a través de caminos de red en mal estado. Esta vez, abramos el cuadro de datos (paquete) que llegó y descubramos cómo el navegador dibuja una imagen llamada pantalla. Esta es la última historia de la serie Re: Conceptos básicos de arranque de CS.

El navegador es un sitio de construcción donde se lee, construye y pinta el código.

Llegó la carga, comienza el montaje

En nuestra visión del mundo de “centro logístico digital”, el producto (archivo HTML) ya ha llegado a casa del cliente (navegador). Sin embargo, lo que llegó no fue un producto terminado, sino un “manual de montaje”. El equipo de trabajo llamado motor de navegador (motor de renderizado) lee este manual e inmediatamente comienza el montaje. Este proceso se llama proceso de renderizado.

Paso 1: Análisis del plano (análisis y árbol DOM)

Lee el texto HTML que llega primero y crea un ‘esqueleto’.

Paso 2: Diseño de interiores (árbol CSSOM)

Luego, lee el archivo CSS y crea ‘reglas de estilo’.

Paso 3: Crear una orden de trabajo (árbol de renderizado)

Ahora combinamos el esqueleto (DOM) y el diseño (CSSOM). El punto importante aquí es que sólo se seleccionan «las cosas que realmente aparecerán en la pantalla».

El árbol de renderizado es una lista final de sólo «aquellos que se pueden dibujar de verdad».

[Verificación de código] Reflujo y repintado

Ahora es el paso realmente importante. La clave para la optimización del rendimiento radica aquí. Una vez creado el árbol de renderizado, el navegador realiza dos tareas pesadas.

Sentimos la diferencia de costo con el código.

const box = document.getElementById('box');

// Case 1: Codigo que provoca layout (Reflow) (caro)
// Si cambia el tamano o posicion, hay que recalcular los elementos cercanos.
box.style.width = '200px'; 
box.style.height = '200px';
box.style.margin = '20px';

// Case 2: Codigo que solo provoca paint (Repaint) (relativamente barato)
// Posicion igual, solo cambia el color. Sin recalculo, solo repintado.
box.style.backgroundColor = 'blue';
box.style.color = 'white';
box.style.visibility = 'hidden';

Análisis:

En la práctica, la mayoría de los casos de «animación entrecortada» se producen porque las propiedades de diseño como ancho, left y top se tocan en tiempo real. En este caso, se necesita una técnica para omitir el cálculo del diseño mediante el uso de propiedades como transform.

Consejos prácticos: no intimides a tu navegador

No sabía esto cuando estaba en la universidad, así que manipulé aleatoriamente el DOM con JavaScript. Al revisar la declaración for, cambié el tamaño y el estilo de cada elemento. Desde la perspectiva del navegador, es como ser torturado destruyendo y reconstruyendo un edificio docenas de veces por segundo.

Consejos para garantizar el rendimiento:

Cambiar la ubicación (Reflujo) es una operación mucho más costosa que cambiar el color (Repintar).

Serie final 1: Mi CS reiniciado

Con este artículo, la serie [Re: Arranque] Conceptos básicos de CS ha llegado a su fin.

Hicimos un largo viaje juntos.

Al principio, era sólo conocimiento que memorizaba para conseguir un trabajo. Sin embargo, después de encontrar errores en la práctica y volver a mirar, CS (ingeniería informática) no era letra muerta, sino una tierra sólida que respaldaba mi código.

El trabajo de cimentación ya está completo. Es hora de construir tu propio castillo sobre tierra firme. En la próxima serie [Monolith Builder], cubriré la creación de aplicaciones web utilizando Spring Boot y Vue.js, que he experimentado en la práctica. Esperen con ansias el proceso de convertir la «teoría» en «práctica».

Deja un comentario