El Viaje de un Píxel en una Aplicación React

Hola a todos, y gracias por unirse a mi charla, El Viaje Sobre el Pixel en Aplicaciones de React. Antes de hablar sobre el tema, quiero presentarme. Soy Sze Magnezy, soy el co-fundador y CTO de Wilco. Antes de Wilco, estuve en un par de startups, pero luego en una corporación más grande, como WeWork y Meta. Hoy, vamos a hablar un poco sobre el desarrollo web y un sitio web, y cómo se pintan en la pantalla.

Y esto es importante porque el desarrollo web se ha vuelto muy fácil en estos días, ¿verdad? Abres tu agente de codificación favorito, ya sea Base44, o Lovable, o incluso Cursor. Y con un solo aviso o un solo tema, obtienes una aplicación completa. Eso es magia, ¿verdad? Es tan increíble que tengamos estas herramientas en contraste con lo que teníamos hace unos años, o incluso más, que necesitabas crear todo desde cero, entender todo lo que funciona detrás de escena, y lo que hace cada pieza de código, y cómo configurarlo, y servidores, y redes, y etcétera. Así que, esto es muy, muy fácil.

Eso es positivo, ¿verdad? Es algo que ayudó a mucha gente y trajo el desarrollo web a todos. Pero tal vez se ha vuelto demasiado fácil para una fuente. Porque cuando se vuelve demasiado fácil, realmente no sabemos qué sucede detrás de escena.

Y a veces da miedo e incluso puede que no sea tan bueno. Y por esto, quiero hablar hoy sobre lo que sucede realmente detrás de escena, cuando estás construyendo un sitio web, y lo entregas, y la gente lo está usando. ¿De acuerdo? Entonces, una vez que entiendas lo que sucede detrás de escena, podrás luego profundizar en esos temas, y tal vez corregir algunos errores que ocurrieron en el camino. Tal vez hay algunas áreas en tu aplicación que no están bien optimizadas. Y necesitas corregirlas. Para corregirlas, necesitas entender específicamente cómo funcionan las cosas. Tal vez quieras mejorar tu accesibilidad y SEO. Entonces, necesitas entender cómo esas aplicaciones web se pintan en la pantalla, y qué es un HTML, y CSS, etcétera.

A veces quieres dar una mejor experiencia de usuario para lo que obtuviste desde cero, lo que obtuviste gratis, y luego llegas a páginas específicas, y tal vez intentas mejorarlas. Tal vez necesitas... escuchaste un poco sobre algo llamado React, o HTML5, o incluso WebSocket, y cosas así, y quieres mejorar tu sitio web. Y tal vez tu sitio web es muy exitoso, y luego el sitio web se vuelve un poco más pesado, un poco más lento, o simplemente cuesta toneladas de dinero entregar todas esas imágenes, y HTMLs, y archivos, y necesitas mejorarlos. Y en general, quieres entender lo que sucede detrás de escena. Quieres entender lo que ocurre detrás de esto. No es solo magia.

Por eso quiero adentrarme en el motor que ejecuta tu aplicación web, y lo que sucede una vez que ingresas a un sitio web específico, hasta que realmente puedes usarlo e interactuar con él. ¿De acuerdo? Entonces, quiero comenzar dando un ejemplo de nuestro sitio web, el sitio web de Wilco, porque no quiero avergonzar a otras personas, y solo quiero mostrar que incluso para alguien que sabe lo que realmente sucede detrás de escena, y para nuestro equipo que son muy experimentados, incluso para nosotros, entregar un sitio web perfecto es muy, muy difícil. Primero, es difícil, y necesitas entregar muchos recursos, y tiempo, y dinero, invertir muchas cosas allí para dar un sitio web perfecto, y a veces no funciona. Siempre hay pros y contras, y a veces te perdonas por algo que omites.

Entonces, esta es una versión de nuestro sitio web, como puedes ver, apple.co.gg, que abrí con una pestaña de red, y más importante, habilité en Chrome una opción de depuración donde la red es muy, muy, muy, muy lenta, y el caché está deshabilitado, y esto es conceptualmente cómo las personas con internet muy, muy lento acceden al sitio web en el primer intento. Esto obviamente no refleja a todos nuestros usuarios, la mayoría de nuestros usuarios usan escritorio, y tienen conexión a internet, y inalámbrica, o cableada, y lo obtienen muy, muy rápido, y si llegas al sitio web, ves que en un par de milisegundos, accedes al sitio web, pero una vez que lo abro, y en esta versión, ves cuánto tiempo toma, cuántas cosas están sucediendo allí, cuánto tiempo toma hasta que realmente el sitio web es interactivo y los usuarios pueden usarlo. Aceleré el tiempo, pero tomó algo como unos minutos. Esto es algo inaceptable en cualquier aplicación, pero quiero mostrarte que incluso en nuestra aplicación, en la que invertimos mucho, y sabemos exactamente qué sucede allí, incluso allí, es muy, muy difícil entregar un sitio web perfecto, ¿de acuerdo?

Así que tomó dos minutos, incluso más, y acelerado, y ahora vamos a saltar al flujo, y ver qué está sucediendo realmente detrás de escena, porque muchas cosas están sucediendo. Muchas cosas, pero para nosotros, todo se da por sentado, y es preciso. Entonces, lo primero que sucedió es que hago clic en app.willco.gg, ¿de acuerdo? En la barra de direcciones, y detrás de escena, nadie, como el internet, no sabe qué es app.willco.gg. El internet funciona con IPs, ¿verdad? Así que alguien necesita traducir este app.gg en una IP específica donde nuestro sitio web se encuentra. Al final del día, una IP es un servidor que simplemente te da archivos. Así que alguien necesita traducirlo, y este algo o alguien, se llama DNS, ¿de acuerdo? Así que este proceso de mover de app.willco.gg o cualquier otro texto o dirección a IP se llama resolución de DNS. En realidad, no hay muchas cosas que podamos hacer aquí, y al final del día, esta es la máquina del usuario, pero algo con lo que podemos ayudar es si tenemos todo tipo de otros recursos en el HTML, porque al final del día, no solo entregas un HTML. Tu HTML carga muchos otros recursos, por ejemplo, fuentes o cosas así.

Puedes pedirle al navegador que haga un prefetch de DNS, lo que significa que vamos a cargar todo tipo de recursos desde esta dirección, tal vez prefetch esos para ahorrar esos viajes a, de acuerdo, ¿cuál es la IP para esta dirección?, y podemos ahorrar un par de milisegundos o menos. Pero es importante saber que el viaje que el paquete está haciendo. Así que lo primero siempre es la resolución de DNS. Una vez que tenemos esta IP, necesitamos obtener este archivo index.html, ¿verdad? La entrada raíz para nuestro sitio web, y esto ha sucedido solo por una solicitud GET. Vamos a la IP que acabamos de obtener y les pedimos, oye, ¿puedes darme el sitio web, el sitio web raíz, de acuerdo?

Así que esto debería ser muy, muy rápido, como una solicitud aquí. Aquí va, como continuar desde allí. Ya sea guardando y omitiendo todo tipo de lógica, ya sea para la implementación, tal vez usando CDNs, esos son servidores que son muy, muy eficientes en entregar contenido. Podemos aprovecharlos, así que podemos ver una aplicación simple de Node.js y tú ves que tenemos todo tipo de middleware que estamos haciendo mientras recibimos una solicitud. Y luego para la solicitud raíz, simplemente, está bien, estos son los activos estáticos, entrégalos, y tú puedes ver que la solicitud actual está dando para esta IP, solo danos el HTML simple. Y usualmente debería ser un HTML, ¿verdad? El HTML que el navegador puede manejar y ver qué está sucediendo desde allí, porque hay una cascada ahora mismo, justo después de esto, para obtener todos los otros recursos. ¿De acuerdo? Así que obtuvimos un HTML de vuelta al navegador, y el navegador comienza a analizar y entender cómo manejar esto. ¿De acuerdo? Así que primero es inicial el documento HTML aquí. Necesitamos entender que HTML es una especificación que puede ser muy, muy confusa o muy compleja, y necesitamos mantenerlo muy simple. ¿De acuerdo? Porque esta es la primera cosa que el navegador está haciendo y no permite hacer otras cosas hasta que se analice. ¿De acuerdo? Así que el HTML debería ser muy simple, sin muchos scripts en el head o cosas que bloqueen al navegador de comenzar a cargar todos los otros recursos. Y también, si hay recursos críticos y elementos agradables de tener en el HTML, intenta diferenciar esos y el contenido crítico estará justo al inicio, y lo agradable de tener o cosas que necesitas cargar sin romper el flujo e interactuar con el usuario pueden ser de manera asíncrona después de esos bloques. ¿De acuerdo? Así que una vez que estamos cargando y analizando, necesitamos optimizarlos. Y si el HTML es muy, muy complejo, el análisis de HTML tomará tiempo que no es necesario. Pero si estamos dando uno muy simple, esto será muy, muy rápido, y podemos comenzar a cargar otros recursos. ¿De acuerdo? Así que una vez que tenemos el HTML y una vez que se analiza y una vez que tenemos el encabezado, necesitamos obtener muchos otros elementos porque en la web moderna, no es solo un HTML. Y no importa si estamos hablando de renderizado del lado del servidor, renderizado del lado del cliente. Obviamente con el renderizado del lado del cliente, hay mucho más JavaScript, pero también con el renderizado del lado del servidor. Vamos a cargar archivos CSS, imágenes, JavaScript, SVGs, todo tipo de recursos porque queremos dar una experiencia muy rica al usuario. Los usuarios están acostumbrados a un sitio web agradable y interactivo, y tenemos que hacerlo con otros recursos como CSS, JavaScript, fuentes, otras bibliotecas de terceros, scripts que necesitamos cargar. Estos usualmente se añaden en el encabezado. Todos los recursos que necesitamos, pero algunos se cargan en el cuerpo en otras versiones. Así que primero que todo, esto es por defecto. No lo veo más, pero HTTP 2 usaba carga secuencial. Así que cargas el primer CSS, luego el segundo CSS, tercer CSS. No lo veo muy a menudo, pero a veces hay algunos errores. Y de nuevo, necesitas entender cuál es la diferencia y qué sucedió detrás de escena. Pero con HTTP 2, esos recursos suceden en paralelo, así que cargamos un par de CSS juntos, archivo JavaScript, y ahorra mucho tiempo. Esos archivos, esos JavaScript CSS, pueden ser muy pesados. Al final del día, esos son sintaxis que escribes con todas las clases y todas las funciones y todo el código que escribes.

Puede ser muy grande y pesado, pero al navegador realmente no le importa tu convención de nombres o nombres de funciones legibles o comentarios o cosas así. Así que realmente tienes que comprimir esos usando todo tipo de herramientas que tenemos disponibles. Todos esos recursos deben ser reducidos y comprimidos para que se entreguen lo más rápido posible, y no tomen demasiado tiempo en entregarse en la red y luego con el ahorro.

Cuando cargas esos recursos, prioriza esos. Apuesto a que el CSS para el tema es más importante que la imagen que pones allá abajo en el pie de página o el JavaScript que para darte una interacción en el encabezado es más importante que el JavaScript de analíticas que cargas. Así que piensa en eso y prioriza esos, y los imprescindibles deberían estar en el encabezado o scripts bloqueantes y los agradables de tener pueden estar después de manera asíncrona.

Aquí puedes ver abrir una red para cualquier sitio web y ver cuántos recursos carga fuera de tu HTML. Se ha convertido en algún tipo de estándar, está completamente bien, y HTML y el navegador web pueden manejarlo. Solo asegúrate de hacer las cosas bien. Una vez que tenemos el JavaScript, necesitamos ejecutarlo, porque esto es un JavaScript, necesitamos ejecutarlo. El navegador lo toma y comienza a ejecutar todo allí. Nuevamente, ya vimos que necesitamos comprimirlo, pero no solo comprimirlo, también necesitamos eliminar el código innecesario, porque escribes mucho código y cargas toneladas de bibliotecas, pero muchas de ellas no son relevantes.

Si, por ejemplo, tienes un archivo JavaScript para el mecanismo de administración y esos son usuarios regulares, ¿por qué los usuarios necesitan tu lógica de JavaScript? Puedes eliminar esos, puedes eliminar código no utilizado para polyfills o cosas así. Todas esas cosas, obviamente, no necesitas manejarlas solo a mano. Hay herramientas que lo hacen por ti, ya sea reduciendo o eliminando archivos, y necesitas usarlas.

Aquí hay un ejemplo de fragmentación de todo tipo de archivos JavaScript. En lugar de un archivo JavaScript enorme, algunos de ellos no se usan, lo fragmentas, lo mismo para el CSS, y solo tomas las partes que el usuario necesita. Tenemos el HTML, tenemos los recursos, tenemos el JavaScript, y comienza a ejecutarse, y ahora entramos en el ciclo de vida de React. Nuevamente, es muy similar para front-end y back-end, y es muy similar a otros frameworks como Vue, pero al final del día, todos esos frameworks tienen algún tipo de ciclo de vida interno para eventualmente dibujar tu sitio web.

Así que aquí, nuevamente, no hagas cosas que reinventen la rueda, solo sigue las mejores prácticas, ya sea Memorize o Effects y cosas así, y solo usa las mejores prácticas. Si te encuentras con páginas muy, muy complejas o lentas, generalmente se trata de la gestión de estado y optimízalas. ¿De acuerdo? Una vez que tenemos todo el ciclo de vida de React, React intentará fusionar esos tonos virtuales en el DOM real. Esto es algo que sucede internamente en React. Nuevamente, sigue las mejores prácticas, pero como claves y cosas así, pero en general, vi muchos...