Enfoques Modernos para Crear Sitios Web Extremadamente Rápidos

Hagamos cosas interesantes. Se me ocurrió esta charla, como a muchos oradores, tienes una idea general y realmente no sabes exactamente cómo la vas a hacer o en qué dirección va a ir, pero sabía que quería hablar sobre el rendimiento. No sabía si iba a hablar sobre el rendimiento del renderizado del DOM, o tal vez sobre las animaciones, o todo lo anterior, y hacer un gran desorden de todo.

Comencé a preguntar a mi alrededor, le pregunté a algunos amigos y algunas personas en Twitter y cosas así, ¿en qué piensas cuando piensas en el rendimiento de un sitio web? Esta es una de las respuestas más comunes que recibí. Las solicitudes más rápidas que puedes hacer son las que no haces en absoluto. ¿Alguna vez has escuchado eso? Cuando escucho esto, me quedo un poco como, ¿qué? Vale, eso es un poco filosófico, ellos hacen su punto y se van, como, ahí lo tienes, ahí está el rendimiento. Pero estamos en el negocio de hacer sitios web. Que hacen solicitudes. No puedo eliminar todas mis solicitudes. No es realmente práctico.

Así que, comencé a pensar en esto y pensé, está bien. Si eso funciona, si eso ayuda. Pero, ¿qué pasa si necesitas hacer una solicitud? Porque todos vamos a necesitar hacer eso. Entonces, de eso trata esta charla. Tal vez obtengamos solo lo que necesitamos. Bastante simple, ¿no? Suena bien. Ok. Consejo. Sigamos adelante. Tal vez anticipemos las necesidades futuras. Por ejemplo, obtengamos las cosas por adelantado cuando creamos que las vamos a necesitar. A veces puede parecer que estos dos están un poco en desacuerdo entre sí. Pero elige el que funcione para ti en esta situación. Por supuesto, querrás obtenerlo cerca. Como desde una caché. Eso sería genial.

A veces necesitas solicitar dos cosas a la vez. Y si haces eso, creo que deberíamos intentar hacerlas en paralelo. Y no permitas que lo lento detenga a lo rápido. Así que empecemos aquí mismo.

Si necesitas hacer una solicitud, obtén solo lo que necesitas. Comencemos con algo más estándar y no tanto React. Con las imágenes, estoy seguro de que la mayoría de ustedes saben, esto ha estado presente por un tiempo. Podemos hacer carga perezosa, lo cual es realmente genial. Así que debajo del pliegue, si puedes identificar ciertas imágenes como algo que no necesariamente necesita ser cargado. Tal vez la solicitud más rápida que puedes hacer es la que no haces en absoluto, tal vez. Pero obtén solo lo que necesitas. Cosas que solo necesitan ser cargadas cuando el usuario las necesita. Entonces, cuando el usuario se desplaza, obtienen la imagen, muy bien. Ok. Eso es de lo que estoy hablando. Cosas que puedes hacer para que un sitio web sea un poco más rápido.

Anticipa las necesidades futuras. Un ejemplo estándar de eso sería tal vez uno que no hayas visto. Link, pre-render, en minúscula. Esto no es un componente React. Es una cosa estándar de HTML. Lo sé, gracioso, ¿verdad? Ok. Esto es algo que tal vez puedas usar. Si un usuario visita tu sitio, sea cual sea la página en la que aterricen, imagina anticipar de manera muy fácil a qué página van a ir a continuación, porque probablemente tengas una idea, y estás descargando esas páginas en segundo plano antes de tiempo. Y luego el usuario visita la segunda página y luego descargas la tercera y cuarta páginas posibles a las que podrían querer ir. Esto es realmente agradable. MDN describe esto como cuando el usuario navega hacia el contenido pre-renderizado, el contenido actual es reemplazado instantáneamente por el contenido pre-renderizado. Esto es agradable. ¿Sabes por qué? Porque me hace sentir como si el usuario estuviera obteniendo una experiencia como la de desarrollo local. Como si todos obtuviéramos la mejor versión de nuestros sitios web, ¿verdad? Porque estamos haciendo desarrollo local.

Es súper rápido. Y luego lo pones en la red, en Internet, y es un poco más lento, y te dices a ti mismo, bueno, es Internet. Así es, ¿verdad? Pero sería realmente agradable, idealmente, si pudiéramos tener una experiencia súper rápida para nuestros usuarios como la que tenemos localmente. Eso sería lo ideal, creo.

De acuerdo. Así que estas dos cosas. Comparemos cómo es construir una aplicación clásica de múltiples páginas versus una aplicación de página única. Estoy seguro de que muchos de ustedes están familiarizados con las aplicaciones de página única porque eso ha sido lo popular durante unos 10 años. Pero he estado aquí el tiempo suficiente para recordar cómo era construir las aplicaciones de múltiples páginas y las dificultades que tenían. Hay un compromiso entre estas dos cosas. Construyamos esto en capas. Así que podríamos tener un diseño principal, como un subdiseño, y una página, como muchas de estas aplicaciones tendrían.

De acuerdo. Así que imaginemos cómo serán las solicitudes de red para los diferentes usuarios que visitan la misma aplicación. Lo primero que podría suceder es que el usuario de la aplicación de página única obtenga una respuesta inmediata del servidor, pero será principalmente una estructura básica de un archivo HTML. Mientras tanto, el usuario de la aplicación de múltiples páginas no ha obtenido ningún HTML porque todo se está construyendo en el servidor. Entonces, ¿qué es mejor? No lo sé. Tal vez sea subjetivo. Tal vez sea demasiado pronto para decirlo, pero si tenemos que entregar un trofeo en este punto, tal vez porque la aplicación de página única respondió un poco más rápido, tal vez le otorguemos el trofeo a la aplicación de página única.

Lo siguiente que probablemente suceda es que la aplicación de múltiples páginas obtenga un archivo HTML completamente formado mientras que la aplicación de página única todavía está obteniendo JavaScript, y luego tenemos que construir el HTML. Pero ¿son estas dos cosas iguales en este punto? No realmente, porque el usuario de la aplicación de múltiples páginas está experimentando un archivo HTML completamente formado mientras que el usuario de la aplicación de página única está viendo los indicadores de carga. Así que tal vez invertimos esto. Tal vez la aplicación de múltiples páginas sea un poco mejor en este momento. Ahora, la aplicación de múltiples páginas tiene que obtener JavaScript, pero esto probablemente sea solo para eventos. Y realmente no disminuyó demasiado la experiencia del usuario. Y al mismo tiempo, la aplicación de página única está obteniendo datos. ¿Notas la distancia aquí? ¿Dónde se obtuvieron los datos cuando estábamos en la aplicación de múltiples páginas? Estaba en un servidor hablando con otro servidor. Podrían haber estado uno al lado del otro, ¿verdad? Idealmente, podrían estar cerca uno del otro. Con la aplicación de página única, probablemente estén muy separados y debas hacer el mismo número de solicitudes, probablemente, si estás utilizando un backend de tipo RESTful. Algunas de estas solicitudes se pueden hacer en paralelo, a veces.

Pero a menudo se hacen en serie, creando la clásica cascada. Entonces, las aplicaciones de página única son propensas a cascadas porque estamos obteniendo datos dentro de los componentes. Idealmente, nos gustaría hacer esto en paralelo entre sí, lo cual es posible. Hay cosas como React Query que pueden ayudar con esto. También hay cosas como el nuevo enrutador de React, que se pueden usar en combinación entre sí, que probablemente es la mejor manera de hacer aplicaciones de página única, creo, para obtener datos. Pero puedes obtener datos en paralelo con el nuevo enrutador de React, porque no se obtiene desde dentro del componente. Así que eso es bueno para las aplicaciones de página única. Pero en última instancia, requiere más trabajo construir una aplicación de página única en términos de tráfico a través de la red que una aplicación de múltiples páginas.

Vale. Entonces, las aplicaciones de múltiples páginas ganan hasta que queremos ir a la página 2. Esta es la razón por la que nos gustan las aplicaciones de página única, porque con una aplicación de múltiples páginas, JavaScript se cierra. Es muy triste. No podemos mantener el estado, el estado persistente, en el cliente cuando esto sucede. Por eso, en los días de jQuery, ¿dónde pondríamos nuestro estado? No había Redux o bibliotecas de gestión de estado en ese entonces. ¿Alguien hizo alguna vez esos sitios de jQuery de los años 2000? Pondrías el estado en el DOM.

Así que en la página 2, tenemos que construir todo de nuevo, todo lo que ya teníamos. Ya teníamos todas estas cosas, y sin embargo las estamos construyendo de nuevo ahora, es casi como un actualización de página. Quiero decir, realmente lo es. Una actualización de página. ¿De acuerdo? La aplicación de página única simplemente dice, oh, ¿quieres ir a la página 2? De acuerdo, bam, bam, vamos a buscar la página 2. Así que creo que esto es una ventaja para las aplicaciones de página única. Nos gustan aspectos de ambas, ¿verdad? Nos gusta el contenido inicial rápido. Nos gustan las navegaciones del lado del cliente por aquí. Pero por aquí, nos gustan menos cascadas, y por aquí, nos gusta escribir la lógica de la interfaz de usuario una vez. Quiero decir, dependiendo de cómo estés construyendo tu aplicación de múltiples páginas, si estás utilizando una tecnología en el backend y luego JavaScript en el frontend, a veces eso puede ser diferente a hacerlo en JavaScript en ambos lados. ¿Recuerdas esas cosas de precarga de enlaces o pre-renderización de las que estábamos hablando? La razón por la que tal vez algunos de ustedes no han oído hablar de esto es porque no se puede usar realmente esto en una aplicación de página única. Ni siquiera tendría sentido porque vas a hacer transiciones del lado del cliente. Así que eso es algo que obtenemos por aquí. ¿Qué tal construir solo la interfaz de usuario necesaria? Tuvimos que volver y reconstruir todo de nuevo, ¿verdad, cuando hicimos la aplicación de múltiples páginas? Y finalmente, estados en el frontend. A veces necesitas un estado consistente y persistente. Y así es agradable poder hacer JavaScript y no tener que reiniciarlo entre las transiciones de página. De acuerdo. Así que durante diez años, al menos para mí, parecía que tenías que estar en un mundo o en el otro. Y hoy no es así. Puedes hacer una combinación de lo mejor de ambos. Eso es realmente de lo que trata esta charla. Vamos a hablar de Remix.

Pero en realidad no se trata solo de Remix, porque muchos de estos conceptos híbridos también se aplicarían a Next o cualquier otro framework de JavaScript que también esté haciendo híbridos.

De acuerdo. Así que vamos a incorporar el framework. Construyamos esta página con Remix conceptualmente. Veamos. Está compuesta por tres capas. ¿Correcto? Tenemos un diseño principal. Tenemos un subdiseño. Y tenemos la página. Por lo tanto, construyes diferentes archivos para esto, al igual que lo harías en Next. Y hay una función de carga, algo así como el get server side props, que se ejecutaría solo en el servidor.

Entonces, esto es nosotros haciendo la solicitud a la página de inicio, y se necesitaron tres componentes para hacer la página de inicio. Estos tres cargadores se ejecutan en paralelo entre sí, obteniendo datos, proporcionando su contenido a sus respectivos componentes, todo junto para crear colectivamente un archivo HTML y devolverlo. Por lo tanto, en este punto, realmente no es tan diferente a... Bueno, realmente no es diferente a una aplicación de múltiples páginas. Todavía tenemos que obtener JavaScript, ¿verdad? Pero, ¿qué hay en este JavaScript? Aquí es donde las cosas comienzan a cambiar. ¿Son solo eventos como en la situación clásica de una aplicación de múltiples páginas? No realmente. ¿Es cada posible interfaz de usuario a la que podríamos querer ir, como en una aplicación de una sola página? No realmente. Porque ninguno de los dos es realmente ideal. Entonces, ¿qué hay aquí? Lo llamamos un archivo de manifiesto. Y sabe todo sobre la página en la que estamos, incluidos los diferentes componentes que construyeron esta página y si quisiéramos ir a la página 2, porque tenemos los enlaces que usamos para construir la página 1. Sabe que si hiciéramos la transición a la página 2, no necesitaríamos todo de nuevo, porque la página 2 usa el mismo diseño principal y subdiseño, por lo que teóricamente solo necesitaría la información de la página 2. ¿Significa eso que tenemos que hacer una actualización de página completa, como en una aplicación de múltiples páginas, y simplemente obtener eso? Bueno, no, no realmente. Ahora ese cargador que se usaba en conjunto con el componente en el servidor para construir HTML, ahora ese cargador también se puede usar como un punto final RESTful. Cuando quieres hacer clic para ir a la página 2, esta será una transición del lado del cliente donde enviamos... Haremos dos solicitudes en paralelo. Enviamos datos desde el cargador y el código JavaScript para crear ese componente.

Lo cual es solo un archivo, por lo que es almacenable en caché. Y ahora estás en la página 2. Entonces es como una aplicación de página única en ese punto. Una aplicación de página única que ya está haciendo la división de código por ti, y ni siquiera tienes que pensarlo. Sin mencionar que está haciendo la división de código de una manera en la que obtiene ambas cosas en paralelo. ¿Qué sucedería en teoría si estuvieras haciendo una aplicación de página única y quisieras dividir el código de una de tus rutas? Tendrías que ir al servidor para obtener ese archivo, traerlo de vuelta, ahora quiere hacer algunas cosas de efectos de uso, lo cual requeriría una solicitud en serie de vuelta al servidor para obtener data. Todo esto sucede en paralelo, porque conocemos toda la historia. Remix está construido sobre React Router, y React Router conoce todo el panorama. Lo cual es realmente agradable.

Bien, anticipa las necesidades futuras y obténlas por adelantado. Bien, todo lo que he explicado hasta ahora es bastante bueno. Pero, ¿qué sucede si pasamos el cursor sobre un enlace? Simplemente pasar el cursor sobre él, React... Perdón, Remix puede hacer un intento de precarga de enlace, y al pasar el cursor sobre él, esto ya se iniciará. Por lo tanto, te dará solo unos pocos milisegundos de ventaja. Y eso es bastante genial, pero ¿sabes qué lo haría realmente rápido? También puedes hacer una renderización de precarga. Y estando en la página 2, ya estamos descargando en segundo plano todo el contenido para la página 2, 3 y 4. O 3, 4 y 5, debería decir. Pero esto no es como el estándar que te mostré hace un segundo, que habría... Para una aplicación de varias páginas, habría vuelto y obtenido cargas completas de HTML y las habría preparado y listo. Esto solo obtiene las partes que necesitamos. Esto puede ser más rápido que los sitios web estáticos. En este punto. ¿Puede ser más rápido? Bueno, si obtienes estos datos precargados desde el otro lado del mundo, eso es una cosa. Pero, ¿qué sucede si lo almacenamos en caché un poco más cerca? Ahora puedes obtener estos datos precargados cerca. ¿Podríamos mejorarlo aún más? Una cosa que Remix puede hacer es alojarse en cualquier entorno de servidor JavaScript. Específicamente no dije node. Lugares como CloudFlare y WebWorkers están haciendo cosas como V8 en los servidores en el borde. Puedes alojar Remix allí. Ni siquiera necesitas un CDN en ese punto porque ya estás tan cerca como estaría un CDN pero con JavaScript en ejecución. ¿Podríamos hacerlo aún más rápido? Entonces, estos cargadores, digamos que estamos trabajando con el cargador de página, bueno, el cargador de página podría necesitar dos o tres solicitudes diferentes a la base de datos para crear la página.

Entonces, digamos que hay obtener usuario, obtener productos y obtener comentarios. Normalmente los ejecutarías en paralelo, lo que significa que estás esperando al más lento para terminar antes de construir la página HTML y devolverla, ¿verdad? Pero una de las cosas nuevas que puedes hacer con Remix es designar uno de estos como no tan importante como el otro. Entonces, ¿qué pasa si obtener usuario y obtener productos son más importantes y se resuelven antes? ¿Por qué deberíamos detener lo que el usuario ve hasta que obtengamos los comentarios cuando los comentarios no son tan importantes? Estaría bien si tuviéramos un indicador de carga solo para los comentarios, pero teníamos los datos reales data mostrando para estos otros dos. Entonces, lo que puedes hacer es designar estos dos y puedes comenzar la respuesta temprano. Luego, el usuario está viendo un archivo HTML que está completamente formado, habilitado para SEO y todo eso, y luego, cuando los comentarios se resuelven un momento después, se pueden transmitir a la posición que habrían ocupado en esa página con un indicador de carga.

Luego, el usuario está viendo un archivo HTML completamente formado, habilitado para SEO y todo eso, y luego, cuando la obtención de comentarios se resuelve un momento después, se pueden transmitir a la posición que habrían ocupado en esa página con un indicador de carga.

Así es como se ve eso. Esto es Remix y tenemos nuestro cargador y nuestro componente. Así que imagina que tenemos esta promesa que está esperando obtener usuario y obtener producto. Tenemos la palabra clave await allí. Observa la siguiente línea de código, es interesante. Obtener comentarios está devolviendo una promesa, pero no estamos esperando por ella.

Entonces, tuvimos que esperar a que la primera línea de código terminara antes de que se ejecutara la segunda línea de código, pero no estamos esperando en serie los comentarios. Simplemente estamos obteniendo inmediatamente la promesa y devolviendo esta cosa llamada defer. Normalmente en Remix se devuelve una función llamada JSON. Pero si usas defer, puedes mezclar promesas en esto, y luego es como si estuviéramos construyendo la página a partir de objetos y matrices, lo que sea que sea usuario y producto, pero también una parte que es una promesa.

Ahora, usas el usuario y los productos como de costumbre, y usas la promesa en esta cosa llamada await. Lo pones en este resolve. Una vez que esté listo. Entonces, todo esto se está construyendo en el servidor en este momento, pero se ha enviado al cliente en este punto. Y ahora el cliente está utilizando un indicador de carga mientras espera los resultados transmitidos de los comentarios. Bastante genial. Esto es en lo que he estado construyendo sitios web últimamente, y ha sido realmente fantástico. Hace que los sitios web sean increíblemente rápidos. Acabo de verificar Reacttraining.com hace unas horas para ver cuáles eran sus métricas de rendimiento. Tenían 100, lo cual es gracioso porque en los Estados Unidos tenían 98 o algo así, pero aquí tenían 100. Así que eso es genial. De todos modos, espero que hayas disfrutado. Muchas gracias. Gracias.

Oh, muchas buenas preguntas sobre prerenderizado. Con el prerenderizado real de prefetch, ¿cuánto tiempo es válida la página de prefetch? Simplemente configuras la memoria caché como quieras en esa respuesta, así que puedes decidir eso como desees. Genial. Fácil. Cachéalo como quieras.

¿Cómo ha resuelto Remix la desventaja de necesitar y compartir, cito, el estado del lado del cliente entre rutas? ¿Estado del lado del cliente entre rutas? Puedes usar proveedores de contexto clásicos. Las transiciones de página son del lado del cliente, por lo que no se descargará y volverá a cargar tu JavaScript, así es como lo hago. Seguro que hay otras formas, pero así es como lo he estado haciendo. Sí, suena bien. Hablando de rendimiento y técnicas para eso, ¿recomendarías o has utilizado la API de trabajadores para obtener datos en segundo plano? No lo he hecho, así que no sé mucho al respecto. Lo siento. Ahí lo tienes. Ya hemos hablado de eso. Ya hemos hablado de eso. Bien, si tuvieras una página de descripción general de productos, digamos, y esta página tuviera más de 100 productos y cada producto tuviera su propia página, ¿deberías pre-renderizar todo? No lo sé, si va a ser como, si va a ser así, podría experimentar con eso, pero si muestra cientos de productos por página, tal vez los separe en el servidor en ese valor diferido y cargue algunas cosas con anticipación, pero las cosas por debajo del pliegue podrían transmitirse. Tal vez experimentaría con eso, y luego probablemente experimentaría con otros enfoques. No sé la respuesta perfecta para eso porque suena como una arquitectura para la cual no deberías tener una respuesta perfecta a menos que juegues con ella. Así que jugaría con eso. ¿Quizás algo como un tipo de intersección? Sí, algo así. ¿En algún punto al desplazarse? Sí, suena bien. Creo que... Quieres devolver algo para que sea bueno para el SEO. Sí, exactamente. Pero tal vez si no puedes ver todo de una vez. Pero no puedes ver todo cuando cargas la página por primera vez, está por debajo del pliegue. Así que quiero decir, el usuario va a pensar que todo estaba ahí. Van a mirar algunas cosas. Van a empezar a desplazarse. Esas cosas simplemente estarán allí y las imágenes se cargarán de forma diferida, ¿verdad? Sí. Ahí lo tienes. Eso me parece bien.

¿El pre-renderizado al pasar el cursor se realiza en el lado del servidor o en el lado del cliente? Si es en el último caso, ¿no ralentizará todo al mover el ratón por todas partes? Bueno, se obtienen cosas en segundo plano. Así que quiero decir, si estás en cualquier sitio web grande como Twitter o Facebook, quiero decir, si quieres ir a la pestaña de red, siempre estará haciendo todo tipo de cosas en segundo plano. Así que no creo que realmente ralentice las cosas. Pero cuando pasas el cursor sobre algo, simplemente hacemos una solicitud Ajax para obtener algo. Y si al final no lo utilizas, supongo que estás consumiendo un poco más de ancho de banda. Así que úsalo con moderación porque si alguien está en un dispositivo móvil, se obtiene más data pero se obtiene una experiencia increíblemente rápida. Sí. El dispositivo móvil es uno de los interesantes. Esta no era la charla sobre ahorrar dinero. Esta era la charla sobre la velocidad.

Esto no fue el tienes un mal día. ¿Sabes si Remix adoptará Reactor o Components? Creo que sí. Si me lo hubieras preguntado hace un mes, probablemente habría dicho que no. No hablo mucho personalmente con Michael y Ryan sobre eso porque ambos están ocupados y yo estoy ocupado con la formación de React y cosas así. Pero podría preguntarle a Ryan qué piensa al respecto. Pero obtengo información sobre Remix como cualquier otra persona en Twitter. Trato de no molestarlos demasiado. ¿Cuál es tu opinión? ¿Quieres ver eso?

Bueno, parece que está experimentando con ello. Hace solo uno o dos días tuiteó que estaba realizando experimentos con ello y que le estaba proporcionando un rendimiento realmente rápido. Pero creo que es consciente de algunas limitaciones al hacerlo. Es un gran compromiso. Y no puedo imaginar que esto vaya a ser realmente controvertido. ¿Esto todavía se está grabando? No creo que los React Server Components vayan a mejorar algo que ya es extremadamente rápido. Ese es más rápido. Creo que Remix ya va a ser bastante rápido, tanto si deciden usarlos como si no. Creo que va a depender de si te gusta la arquitectura o tal vez tienes una situación en la que enviar menos JavaScript y los React Server Components podrían darte eso. Tal vez se reduzca a ese tipo de cosas. No creo que te ofrezca un beneficio de rendimiento sobre lo que ofrece Remix. Genial. Interesante.

Hay un par de preguntas que voy a agrupar en un tema, que es que no todos están completamente convencidos del prefetch y el prerender. Una persona dice que si tienes un ancho de banda limitado en una aplicación móvil, podría afectarla, o... Pensé en esta pregunta antes de que la hicieran. Lo pensé hoy mismo. Si realmente me preocupara eso, podría crear mi propio componente de enlace, donde pases los datos al componente de enlace real, y en mi componente de enlace, tal vez detectar si estás en un dispositivo móvil, tal vez tener una condición en la que no hagamos el prefetching, pero en un entorno de escritorio, sí lo haríamos. Podrías utilizar tus propios trucos habituales de React para averiguar ese tipo de cosas. Sí. Parece que vale la pena intentarlo. Sí. Y tenemos una masterclass sobre Remix, así que avísanos si quieres aprender más sobre ello.

Sí. Llámalos. Una última pregunta. ¿Podemos hacer prerenderizado usando React pero sin Remix? Supongo que eso serían tal vez los componentes del servidor. Prerenderizado. Quiero decir, siempre podrías usar esa versión estándar de prerenderizado, si estás haciendo... Lo bueno de React en el servidor es que no hay una solución para la obtención de datos, por eso todos usan un framework, porque tienes que... Por eso Next tiene las props del lado del servidor de Git y nosotros tenemos el cargador, y luego están haciendo los componentes del servidor de React, que Así que no hay... Hasta los componentes del servidor de React, realmente no hay una solución para obtener datos en el servidor, y así podrías hacer una aplicación clásica de varias páginas. Sí. O usar un framework. Sí, sin hacer... Espera. Sí. Realmente no haría eso, pero...

Genial. Bueno, muchas gracias por tu tiempo, Brad. Gracias a todos. Pueden encontrar a Brad en persona en el stand de los oradores después de esto, y si están en casa, en spatial.chat, y pueden hacer aún más preguntas. Así que gracias.