1. Introducción a los sitios web instantáneos
Bienvenidos a mi charla sobre cómo escribir sitios web instantáneos para fresh y Deno. Soy Luca, un ingeniero de software en la compañía Deno. Trabajo en el proyecto fresh, Deno deploy y estoy involucrado en la estandarización de tecnologías web en TC39, What Wig y W3C. También soy co-presidente del grupo de comunidad WinterCG, que se enfoca en estandarizar el comportamiento en los entornos de ejecución del lado del servidor en JavaScript.
Hola a todos, bienvenidos a mi charla sobre cómo escribir sitios web instantáneos para fresh y Deno. Mi nombre es Luca, soy un ingeniero de software en la compañía Deno, trabajo en el proyecto fresh en el proyecto Deno y en Deno deploy, que es nuestra plataforma de ejecución sin servidor en el borde. Hablaremos de eso en un momento. Además de eso, soy delegado en TC39 y trabajo en estándares web. TC39 es específicamente la comunidad de estándares que estandariza JavaScript, pero también trabajo con personas en What Wig y W3C para estandarizar cosas como FetchSpec, WebCrypto y otras especificaciones relacionadas. En W3C también soy co-presidente del grupo de comunidad WinterCG, que es un grupo de comunidad que se enfoca en estandarizar el comportamiento en los entornos de ejecución del lado del servidor en JavaScript. Entonces, cosas como Node.js, Deno o CloudFlow workers, quieres estandarizar el comportamiento entre ellos para poder escribir código de manera portátil y que funcione en diferentes plataformas.
2. Instant Websites and User Interaction
La idea principal de los sitios web instantáneos es minimizar el tiempo entre la interacción del usuario y desbloquear esa interacción. Cuando un usuario navega a una página, espera que el contenido se cargue rápidamente. Para que una página se sienta instantánea, debemos minimizar el tiempo entre la interacción del usuario y su capacidad para ver y actuar sobre el contenido principal que le interesa, como una receta.
Eso es lo que soy. Pasemos a la parte principal de la charla. Antes de poder hacer eso, necesitamos entender qué significa realmente el título de la charla, Sitios web instantáneos con Fresh y
Deno. ¿Qué son los sitios web instantáneos? ¿Cómo puedo hacer que un sitio web se sienta instantáneo? La idea principal es minimizar el tiempo que transcurre entre la interacción del usuario y el desbloqueo de esa interacción. ¿Qué significa eso? Si un usuario realiza alguna interacción, espera que algo suceda. Por ejemplo, cuando navegan a tu página, esperan que cierto contenido se cargue porque están interesados en ese contenido. Quieren leer o ver ese contenido. Si queremos que una página se sienta instantánea, lo que queremos hacer es minimizar el tiempo entre la interacción del usuario y su desbloqueo. Si puedo darte un ejemplo de esto, el usuario quiere visitar una página de recetas que muestra la receta de un plato en particular. Buscan esta receta en Google o buscan este plato en Google, hacen clic en un enlace. Esa es la interacción. ¿Cuánto tiempo les lleva realmente poder ver la receta, entenderla, y tal vez no entenderla, pero ver la receta y comenzar a entender qué está sucediendo? Entonces, el momento en el que el usuario está desbloqueado es el momento en el que puede ver la receta y comenzar a actuar en base a eso. ¿Cuál es el tiempo que necesitamos minimizar aquí? Es el tiempo entre que hacen clic en el enlace y el contenido principal que les interesa ver, o que les
3. Achieving Instant Interactions
Para lograr interacciones instantáneas, debemos entender qué tan rápido necesitan ser percibidas por los usuarios. Las interacciones más rápidas que 100 milisegundos son generalmente imperceptibles, por lo que apuntamos a un máximo de 100 milisegundos. Los cambios visuales pueden permitir más margen, ya que los usuarios esperan más tiempo para cambios significativos. Sin embargo, es crucial proporcionar retroalimentación al usuario rápidamente, incluso si una interacción lleva más tiempo. Mostrar un indicador de carga o un spinner para indicar que algo está sucediendo.
cuidado de ver, la receta se está cargando. ¿Cómo logramos eso en realidad? Bueno, para hacer eso, necesitamos entender qué tan rápido necesita ser realmente instantáneo. ¿Qué tan rápido deben ocurrir estas interacciones para que el usuario piense que son instantáneas? Bueno, realmente queremos que ocurran lo más rápido posible, porque A, no hay razón para hacerlas más lentas. El usuario no va a pensar, `oye, esta página es demasiado rápida`. ¿Verdad? Eso no tiene sentido. Cuanto más rápido, mejor, siempre. Pero hay límites prácticos en qué punto el usuario percibe o no se da cuenta de la diferencia entre demasiado lento o entre rápido y aún más rápido. Por ejemplo, como regla general, las interacciones más rápidas que 100 milisegundos son generalmente imperceptibles. Eso significa que si tienes una interacción que dura 60 milisegundos frente a 100 milisegundos, se sentirán iguales para el usuario. Se sentirán realmente rápidas. Por lo tanto, apuntaremos a interacciones que estén alrededor de ese tiempo máximo de 100 milisegundos. Sin embargo, eso es realmente difícil. Así que tenemos un poco de margen. Por ejemplo, los usuarios suelen ser mucho más indulgentes con su comprensión de lo instantáneo o su percepción de algo si el cambio visual que ven es grande. Esto viene de la realidad. Si un usuario mira algo en la vida real y hay un gran proyecto en marcha, como la construcción de una casa desde cero donde antes no había nada, eso es un gran cambio. Los usuarios esperan que esto lleve más tiempo. Ellos también lo trasladan al software. Si hay cambios visuales importantes, generalmente hay más margen. Para que un usuario aún perciba algo como instantáneo. Obviamente, quieres tomar esto con precaución. Aún quieres ser lo más rápido posible. Cuanto mayor sea el cambio visual, más margen tendrás. Además, es muy importante que brindes retroalimentación al usuario rápidamente de que algo está sucediendo. Si hay una interacción que llevará más tiempo y que no puedes hacer tan rápido como 100 milisegundos, avisa al usuario al respecto. Muéstrale al usuario que algo está sucediendo. Dale algo en qué enfocarse mientras sucede. Haz clic en un botón y sabes que el botón no se completará en el próximo segundo o en los próximos 100
4. Making Pages Load Faster
Ponle un temporizador. Prioriza las cosas que realmente le importan al usuario. Descubre qué está bloqueando al usuario. Carga el contenido principal rápidamente.
milisegundos. Muéstraselos. Ponle un indicador de carga. Ponle un spinner. Ponle un temporizador. Algo para indicarle al usuario que sí, se está progresando. Aquí está aproximadamente cuánto tiempo llevará. Hasta dónde hemos llegado. Dale algo en qué enfocarse. Esto hará que tu página se sienta mucho más rápida que si solo tienes un botón que haces clic y luego no sucede nada y luego no sé. Aún no sucede nada. Aún no sucede nada. En algún momento algo aparece. No es una gran experiencia de usuario. Pero ¿cómo lo hacemos realmente? Esto parece un problema muy difícil de resolver. Por ejemplo, centrémonos específicamente en la carga de páginas por ahora. ¿Cómo haces que tu página se cargue tan rápido que el usuario no se dé cuenta de que está sucediendo? Bueno, realmente tenemos que tener en cuenta muchas variables como la velocidad del dispositivo del usuario, la velocidad de la red, ¿cuál es el tiempo de ida y vuelta al servidor? Pero hay algunas reglas generales que podemos seguir que se aplicarán a cualquier red, cualquier dispositivo en el que esté el usuario, y que siempre harán que el sitio se sienta más rápido incluso si están en un dispositivo de gama alta o de gama baja.
La idea principal que siempre debemos tener en mente es que queremos priorizar las cosas que realmente le importan al usuario. Queremos priorizar las cosas que el usuario está esperando realmente. Queremos priorizar las cosas que están bloqueando al usuario porque el objetivo principal para que una página se sienta instantánea es minimizar el tiempo entre la interacción y desbloquear al usuario. Entonces, si priorizamos desbloquear al usuario sobre otras funciones auxiliares de una página, es posible que podamos aumentar el rendimiento. Permíteme demostrarte a qué me refiero con eso.
Lo primero para descubrir cómo hacer que las cosas sean más rápidas en este caso es averiguar qué es lo que realmente queremos acelerar. Descubre qué es lo que está bloqueando al usuario. Para la mayoría de las páginas esto es relativamente factible porque puedes dividir la mayoría de las páginas en diferentes tipos de contenido. Contenido principal, secundario o incluso terciario. ¿Qué son estos diferentes tipos de contenido? El contenido principal es el contenido que el usuario realmente busca, es lo que el usuario viene a tu página para ver, cosas como en una página de noticias el artículo en sí, en un sitio de cocina la receta o en una tienda de comercio electrónico el listado de productos. Estas son las cosas que el usuario necesita ver para poder desbloquearse. El usuario no viene a una página de artículo o una página de noticias para ver artículos relacionados, para ver anuncios, para ver la navegación de la página. No. Vinieron aquí o para ver un post patrocinado o algo así. No. Vinieron allí para leer ese artículo real, por lo que lo importante que desbloqueará al usuario es cargar las cosas que realmente le importan al usuario, el contenido principal. Aún puedes cargar contenido secundario y terciario, pero no hagas que la carga de ese contenido ralentice el contenido principal.
5. Optimización de la Carga de Páginas
Existen múltiples formas de optimizar el tiempo de carga de una página web. Al priorizar la carga de contenido principal, como la sección principal destacada, y retrasar la carga de contenido secundario, como un botón de búsqueda, podemos mejorar significativamente los tiempos de carga de la página. Por ejemplo, en una conexión DSL, esta optimización puede ahorrar hasta 0.3 segundos, lo que resulta en una mejora del 15 al 20% en los tiempos de carga. Esto es especialmente importante para dispositivos móviles con alta latencia. Al optimizar para los escenarios más desfavorables, podemos proporcionar una experiencia de usuario más rápida.
Hay varias formas de hacer esto. Algunos ejemplos del mundo real aquí de sitios web reales. El primero es la página de inicio de
Deno en sí. Puedes dividir esto en dos contenidos principales. Esta es la página de inicio del proyecto
Deno. El contenido principal es la sección destacada con un título, un subtítulo y una instalación, y luego tienes una serie de puntos de conversación que explican qué es
Deno y por qué querrías usarlo. Y luego está el contenido secundario, como la barra de navegación, que contiene un botón de búsqueda. El botón de búsqueda es útil, pero no es la razón por la que la mayoría de las personas visitan la página de inicio de
Deno. Van a la página de inicio de
Deno para obtener más información sobre
Deno, no para buscar algo de inmediato. Por lo tanto, la búsqueda es un contenido secundario. El resto de la página, las cosas que el usuario realmente quiere ver, son contenido principal. Entonces, lo que podemos hacer es asegurarnos de que el contenido principal se cargue primero y solo después de que se haya cargado el contenido principal, comenzamos a cargar el contenido secundario, como el botón de búsqueda. Y puedes ver esto en acción. Tengo un pequeño gif aquí que muestra la carga de la página de inicio de
Deno y si te fijas en esa flecha roja, puedes ver que el botón de búsqueda aparece ligeramente después de que se haya cargado toda la página. Pongamos algunos números reales en esto. La página real se carga en 0.3 o 1.3 segundos, pero el botón de búsqueda se carga solo en 1.6 segundos, hay una diferencia de 0.3 segundos en la que la página está cargada pero el botón de búsqueda aún no. Esto está obviamente muy exagerado en lentitud aquí porque lo que te estoy mostrando es en realidad una conexión DSL de 1.5 megabits por segundo y la mayoría de los usuarios de escritorio en América del Norte ya no tienen conexiones tan lentas. Pero esto ilustra realmente el problema que estás tratando de resolver porque muchas personas todavía están en conexiones como esta, no en su escritorio, sino en sus dispositivos móviles. Es muy común que los dispositivos móviles tengan una latencia muy alta, incluso si la velocidad máxima real es relativamente alta, muchas veces la latencia puede ser bastante grande. Entonces, lo que quieres hacer es minimizar y optimizar para los casos más desfavorables, lo que automáticamente también mejorará los casos mejores. A través de esta optimización, donde cargamos primero el contenido principal y luego cargamos el contenido secundario, el botón de búsqueda más tarde, en realidad ahorramos alrededor de 0.3 segundos en esta conexión DSL, lo que supone una mejora del 15 al 20% en los tiempos de carga de la página.
6. Ejemplo de Contenido Secundario
Tengo un ejemplo diferente de esto donde no es tan obvio lo que está sucediendo. La página de inicio fresca del proyecto fresco tiene contenido principal y contenido secundario. El contenido secundario es una animación que no es crítica para que el usuario vea la página. Se carga de forma perezosa después de la carga inicial de la página.
Esto desbloquea al usuario más rápido. Tengo un ejemplo diferente de esto donde no es tan obvio lo que está sucediendo, ¿lo cual puede ser bueno, verdad? No quieres que sea súper obvio que tu página se está cargando lentamente en partes. Si puedes ocultarlo, es genial. Entonces, esta es la página de inicio fresca para el proyecto fresco y también tiene contenido principal y contenido secundario, pero si te fijas de cerca, no hay nada que aparezca en esta página después de la carga inicial. La carga inicial está completa en términos de diseño. Carga todos los componentes de la página y si no lo supieras mejor, en realidad no te darías cuenta de cuál es el contenido secundario aquí. Así que déjame decirte que el contenido secundario aquí es en realidad una animación. No es un componente específico en la página, es una animación que es algo agradable de tener, pero no es crítico para que el usuario vea esta página. Entonces no es algo en lo que bloqueemos la renderización de la página porque no es algo que realmente bloquee al usuario. Cuando el usuario visita esta página, quiere ver información sobre el proyecto fresco. Las
animations son agradables de tener, pero no es algo que realmente los bloquee. Entonces, si realmente quieres ver la animación aquí, está justo aquí en el banner principal para la página, el logotipo fresco cae y salpica en el resto de la página. Es una animación realmente agradable, pero no es crítica para que la página se cargue, por lo que la cargamos
7. Beneficios de la Renderización en el Lado del Servidor
Una vez más, la renderización en el lado del servidor suele ser mucho más rápida que la renderización en el lado del cliente debido a la minimización de la dependencia de las rondas de viaje en la red. La renderización en el lado del cliente generalmente requiere al menos tres rondas de viaje en la red antes de la renderización, mientras que la renderización en el lado del servidor puede reducir el número de subpeticiones. Al obtener los datos en la solicitud HTML inicial, la renderización en el lado del servidor evita la necesidad de rondas de viaje adicionales desde el cliente hacia una API. Esto es beneficioso porque los servidores suelen tener una mejor latencia hacia otros servidores, lo que resulta en una latencia reducida.
de forma perezosa después de que la página inicial se haya cargado. Nuevamente, esto es muy lento porque está en una conexión DSL. Solo menciono un punto a un streamer. Lo siguiente que debes hacer es probablemente quieras hacer la renderización en el lado del servidor. Estoy en una conferencia de
react aquí y probablemente todos ustedes estén muy familiarizados con
react y
react es muy pesado en la renderización en el lado del cliente, pero aún así quieres hacer la renderización en el lado del servidor porque la renderización en el lado del servidor puede ser y a menudo es mucho más rápida que la renderización en el lado del cliente. Permíteme explicar por qué. Uno de los mayores factores de costo para la velocidad de carga de tu aplicación son las rondas de viaje en la red. La cantidad de veces que cada vez que haces una solicitud en la red hay un tiempo fijo que esto simplemente tiene que tomar debido al equipo de conmutación de red entre el cliente y el servidor. Entonces hay una velocidad máxima a la que
data puede viajar entre tu cliente y el servidor. Esto está relacionado con tu ISP, tu dispositivo, tu tipo de conexión, entre otras cosas, pero es algo sobre lo que no tienes influencia. Es algo que está fijo. No puedes cambiar esto mucho. Entonces lo que quieres hacer es minimizar tu dependencia de este tiempo fijo que cada solicitud toma.
Una forma de hacer esto es asegurarte de no tener el escenario en el que cargas una solicitud. Luego, una vez que se haya cargado esa solicitud, comienzas dos o tres solicitudes más o lo que sea. Una vez que se hayan cargado esas solicitudes, comienzan aún más solicitudes. Y solo después de que todas esas solicitudes se hayan completado, realmente cargas la página. Pero idealmente, lo que quieres hacer es hacer todas las solicitudes a la vez en paralelo porque entonces la latencia no importa tanto. Entonces, lo que estás esperando principalmente no son las rondas de viaje en la red porque solo tienes una de esas. Si estás haciendo todo en paralelo, lo único en lo que te importa ahora es qué tan grande es el recurso. El problema con la renderización en el lado del cliente es que muy a menudo te encuentras en un escenario donde tienes al menos tres rondas de viaje en la red antes de renderizar algo. Esto se debe a que cuando haces la renderización en el lado del cliente, a menudo envías un HTML vacío al cliente en el vendedor inicial, que luego tiene algunos subrecursos, generalmente algún CSS y con la renderización en el lado del cliente, siempre algún JavaScript. Tienes que descargar ese JavaScript. Eso es una ronda de viaje en la red más. Luego tienes que ejecutar ese JavaScript y generalmente ese JavaScript ejecutado hace otra llamada a la API u otra llamada para obtener data del servidor. Eso es otra ronda de viaje en la red. Solo después de que se haya completado esa tercera ronda de viaje, puedes renderizar la página. Mientras que, si haces la renderización en el lado del servidor, puedes prescindir de muchos menos subrecursos, subpeticiones. La renderización en el lado del servidor te permite obtener los datos en la solicitud inicial para el HTML, lo que significa que no necesitas tener esta otra ronda de viaje en la red desde el cliente hacia una API, por ejemplo. Puedes hacer esa solicitud desde el servidor, lo cual es muy beneficioso porque los servidores suelen tener una latencia mucho mejor hacia otros servidores que los clientes tienen hacia los servidores. Debido a que los servidores están conectados a redes de alto performance, aparecen directamente en otros centros de datos de datos, tal vez tu database incluso se esté ejecutando en el mismo centro de datos que tu servidor lateral
8. Los Beneficios de SSR para el Rendimiento Web
Una vez que se haya descargado el HTML, es posible que solo necesites una única sub-solicitud, como la obtención de CSS, lo cual elimina una ronda completa de viaje en la red. Esto puede resultar en una mejora del 30% en los tiempos de renderización y es beneficioso para la batería del usuario en dispositivos móviles.
renderización desde, puedes tener una latencia mucho menor aquí. Esto significa que una vez que se haya descargado el
HTML, es posible que solo necesites una única sub-solicitud. Por ejemplo, algo como obtener el
CSS. Aquí has eliminado una ronda completa de viaje en la red. Si tienes una ronda de viaje en la red de 50 milisegundos, que es bastante rápido, eso significa que ahora has reducido tus tiempos de renderización en al menos 50 milisegundos. El proceso completo toma 150, lo has reducido en 50, eso es una mejora del 30%, eso es muy bueno. Y además, obviamente la renderización en el lado del cliente tiene la desventaja de utilizar muchos ciclos de CPU, porque mucho... en el dispositivo del cliente, especialmente en dispositivos móviles, que funcionan con batería, puede resultar en un consumo adicional de batería. No es algo que queramos. Si hacemos renderización en el lado del servidor, tienes que hacer menos trabajo en el cliente, es bueno para la batería del usuario, estarán mucho más contentos.
9. Optimizando Subsolicitudes para la Renderización
Puedes incrustar tu CSS en el HTML para evitar rondas adicionales en la red y mejorar el tiempo de renderización inicial. Al minimizar las subsolicitudes, puedes acelerar significativamente la renderización de la página.
Y puedes llevar esto aún más lejos. Esto es una um inmersión un poco más profunda en las subsolicitudes necesarias para la renderización. Este es un cronograma de red de la página de inicio de Fresh que te mostré antes. Y lo que puedes ver aquí es que la página de inicio de Fresh puede renderizar y mostrar contenido significativo al usuario después de que se haya completado la primera solicitud. No requiere subsolicitudes para poder mostrar contenido al usuario. Y podrías preguntar cómo funciona esto? ¿No siempre necesitas algo de CSS, por ejemplo? Bueno, puedes hacer cosas como incrustar tu CSS en el HTML para no requerir una ronda adicional en la red para tu renderización inicial. Esto puede ser muy beneficioso incluso en conexiones muy rápidas. Por ejemplo, en este caso, el HTML se ha descargado en 0.45 segundos, pero el siguiente, que en realidad resulta en la línea verde amarilla aquí en 0.52 segundos, es cuando la página se renderiza por primera vez, lo que resulta en una renderización en aproximadamente 55 milisegundos aquí, lo cual es muy rápido. Si hubiéramos tenido que esperar hasta que se completara una subsolicitud adicional en la red con otra ronda adicional en la red, la primera se completa a los 0.65 segundos. Así que habríamos tenido que ralentizar, la renderización de la página se habría ralentizado al menos en 10 a 15 milisegundos, lo que en este ejemplo aquí es una desaceleración del 30 por ciento. Muy significativo. Así que realmente quieres minimizar tus subsolicitudes si puedes, en todo caso intenta incrustar tu CSS en tu HTML para evitar una ronda adicional en la red
10. Renderizado del lado del cliente y JavaScript selectivo
A veces necesitamos renderizar del lado del cliente para funciones interactivas. Los marcos existentes como Next.js y Remix a menudo renderizan del lado del cliente la página completa, incluso para contenido estático que no ha cambiado desde la renderización del lado del servidor.
para descargar el
CSS. Esto puede ser muy beneficioso. Y finalmente, a veces necesitamos renderizar del lado del cliente para realizar ciertas acciones interactivas. Si necesitamos hacer renderizado del lado del cliente y necesitamos enviar algún
JavaScript al cliente para hacer esto, queremos asegurarnos de que este
JavaScript solo renderice del lado del cliente una parte de la página, solo la parte de la página que realmente requiere ser interactiva. Muchos de los marcos existentes como
Next.js y
Remix, lo que hacen es renderizar del lado del cliente no solo los componentes que son realmente interactivos, sino que renderizan del lado del cliente la página completa. Entonces lo que hacen es renderizar del lado del servidor la página por primera vez en el servidor, y luego empaquetan todo el código de renderizado completo que se requirió para renderizar del lado del servidor, lo envían todo al cliente y hacen todo ese renderizado del lado del servidor nuevamente en el cliente. Esto es muy doloroso porque gran parte del contenido que
11. Renderizado del lado del cliente y JavaScript selectivo
Para lograr un renderizado eficiente del lado del cliente, es importante enviar solo JavaScript al cliente para los componentes que son interactivos. Por ejemplo, en la página de inicio de Merge Store, solo se envía al cliente el JavaScript necesario para la funcionalidad del botón del carrito, en lugar de todo el renderizado de la página. Este enfoque minimiza el peso y el tiempo de carga de la aplicación.
que se renderizará en el cliente realmente no ha cambiado desde la renderización del lado del servidor. Como ejemplo, puedes pensar en un blog con un artículo escrito en Markdown. Para poder renderizarlo, necesitas analizar el Markdown y convertirlo a
HTML. Puedes hacer todo eso en el servidor, pero si también necesitas hacerlo en el cliente, necesitas enviar todo el analizador de Markdown, el propio Markdown y el convertidor de Markdown a
HTML. Necesitas enviar todo eso al cliente. Esto puede ser una carga significativa para tu aplicación, y puede ralentizar la carga sin ningún beneficio real, porque el Markdown no ha cambiado desde la renderización en el servidor, ¿verdad? No hay beneficio en hacerlo nuevamente en el cliente. Entonces, lo que quieres hacer es asegurarte de que tu renderizador del lado del cliente solo renderice los componentes que son realmente interactivos en el cliente. Quieres renderizar de manera selectiva. Gran parte de tu página es estática. No necesitas volver a renderizar este contenido estático en el cliente. Solo necesitas volver a renderizar las cosas que son realmente interactivas. Asegúrate de enviar solo el
JavaScript al cliente para los componentes que son realmente interactivos.
Te daré un ejemplo rápido de esto. Este es Merge Store. Conoces Merge Store. Puedes encontrarlo en merge.deno.com. Y esta es la página de inicio. La página de inicio tiene varios enlaces a diferentes productos disponibles en Merge Store. Y esos son simplemente etiquetas ATAGs regulares. No necesitan ningún JavaScript. Cuando haces clic en ellos, se navegará a una página diferente. Pero en realidad, hay un poco de JavaScript que se requiere en esta página, que es para activar este botón del carrito en la parte superior. Este botón del carrito, cuando haces clic en él, abre un diálogo desde el costado, que puedes usar para ver tu carrito de compras, eliminar elementos, presionar el botón de pago, cosas así. Esto requiere un poco de JavaScript para funcionar. En muchos frameworks tradicionales, eso significaría que ahora necesitamos enviar el renderizado de toda la página, incluidas las vistas previas de los productos, el encabezado, el pequeño icono en la parte superior izquierda, el pie de página, todo eso al cliente y volver a renderizarlo en el cliente. Pero lo que hacemos en su lugar es enviar solo JavaScript al cliente para las cosas que son realmente interactivas. Por lo tanto, solo enviamos el JavaScript al cliente que se requiere para renderizar ese pequeño botón y poder realizar las acciones correctas cuando haces clic en ese botón, el escuchador de eventos que se invoca cuando haces clic en ese botón. Puedo darte otros ejemplos de esta tienda. Esta es la página de vista previa del producto donde puedes ver información sobre un producto específico. Esto ofrece nuevamente una tarjeta que requiere algo de JavaScript, pero hay otras partes de esto
12. Arquitectura de Islas y Hidratación Selectiva
El visor de imágenes, el selector de tamaño y el botón de agregar al carrito en un sitio web instantáneo requieren JavaScript para funcionar. Este concepto se conoce como arquitectura de islas, donde solo se envía al cliente el JavaScript necesario para los componentes interactivos. La idea es renderizar las páginas en el servidor y hidratar selectivamente las partes con JavaScript del lado del cliente. El contenido estático permanece intacto. Para obtener más información, lee el artículo del blog 'Arquitectura de Islas' de Jason Miller, el creador de Preact.
también requiere
JavaScript. Por ejemplo, el visor de imágenes tiene un botón izquierdo y derecho que te permite ver diferentes imágenes del producto. Esto requiere un poco de
JavaScript para funcionar, y también tiene un selector de tamaño y un botón de agregar al carrito que también requieren un poco de
JavaScript. Todas estas cosas se envían al cliente individualmente y el
JavaScript se limita solo a los elementos que realmente necesitan ser interactivos. Podrías, por ejemplo, no hacer nada de esto y enviar el renderizador de toda la página al cliente. Pero nuevamente, esto es lento. Ahora necesitarías algo para poder renderizar la descripción del producto, que probablemente esté escrita en Markdown, en tu cliente y renderizar eso. No es algo que quieras hacer. Solo quieres enviar los componentes y el
JavaScript al cliente para los componentes que realmente son interactivos. Toda esta idea de enviar solo el
JavaScript que necesitas para hacer que algunos componentes sean interactivos se llama arquitectura de islas. La idea detrás de esto es que renderizas tus páginas en el servidor y luego hidratas partes específicas de ese Markdown con
JavaScript del lado del cliente. Y no tocas el contenido estático de la página. Por lo tanto, el contenido de la página que es completamente estático nunca es modificado por el
JavaScript del lado del cliente. Solo hidratas los componentes que realmente necesitan interactividad. Si quieres aprender más sobre la arquitectura de islas, después de esta charla puedes consultar el artículo del blog 'Arquitectura de Islas' de Jason Miller. Jason Miller es la persona que inventó originalmente Preact. Es un gran artículo de blog. Tiene algunos diagramas geniales. Realmente
13. Introducción al Fresh Web Framework
Fresh es un nuevo marco web construido para Dino que se enfoca en la velocidad y facilidad de uso. Renderiza páginas en el servidor, sin renderizado del lado del cliente ni JavaScript enviado por defecto. La interactividad del lado del cliente se logra enviando selectivamente componentes como islas. Fresh también proporciona la inclusión automática de CSS y utiliza Preact, una alternativa más rápida y personalizable a React. Ofrece características familiares como el enrutamiento del sistema de archivos y utiliza Deno, lo que lo hace familiar para los desarrolladores con experiencia en navegadores.
les insto a todos a leerlo. Entonces, esa fue la primera parte del título de la charla, Sitios web instantáneos, pero fue el título completo de la charla, Sitios web instantáneos con Fresh y Dino. Así que, vamos a hablar de Fresh. Fresh es un nuevo marco web que construimos para Dino, que se construye con la idea en mente de que todo debería ser realmente rápido y que deberías poder construir sitios web instantáneos con facilidad. Así que toma muchas de esas ideas que mencioné anteriormente en esta charla y las incorpora directamente en el marco, haciéndolas realmente fáciles de usar. Por ejemplo, Fresh renderiza todas tus páginas justo a tiempo en el servidor. No hay renderizado del lado del cliente por defecto, lo que también significa que no se envía
JavaScript al cliente por defecto. En su lugar, si quieres hacer alguna interactividad del lado del cliente, puedes tener ciertos componentes como islas, que se envían al cliente. Pero debes ser muy selectivo al respecto. No envías todo el renderizado de la página al cliente. Por ejemplo, solo envías componentes específicos al cliente para que se rendericen allí. Y Fresh también es muy... intentamos hacer que sea muy fácil hacer lo correcto. Por ejemplo, te dije que la inclusión de
CSS puede ser una gran mejora de rendimiento. Incluimos tu
CSS automáticamente si usas nuestro complemento de Tailwind, por ejemplo. Así que intentamos hacer que sea realmente fácil construir sitios web rápidos y hacer que sea realmente fácil mantenerse en el camino rápido. Entonces, ¿cómo se construyen realmente sitios con Fresh? Bueno, si has usado
NextJS o
Remix antes, te resultará muy familiar. Porque las páginas e islas, están escritas en JSX. Se parecerán mucho a los componentes
React que has construido para tus sitios de Next o
Remix. La diferencia es que en realidad no son renderizados por
React, son renderizados por Preact. Preact es un marco alternativo a
React. Es mucho más pequeño, mucho más rápido y mucho más personalizable que
React. Es una alternativa realmente genial, todos deberían echarle un vistazo, preactjs.org. Pero también hay otras formas en las que se siente muy familiar a
NextJS. Por ejemplo, el enrutamiento se realiza a través del enrutamiento del sistema de archivos. Esencialmente idéntico a
NextJS, que es muy... muchas personas están familiarizadas con él, y es una buena forma de hacer enrutamiento en la actualidad. Y Fresh utiliza
Deno, ¿verdad? Es un marco de
Deno, lo que significa que si has construido algo para el navegador en los últimos diez años, te resultará muy familiar. Si quieres hacer una solicitud HTTP, usa la API Fetch. Las solicitudes y respuestas son las mismas solicitudes y respuestas que tienes en los navegadores a través de la API Fetch o los service workers. Es
14. Características del Fresh Web Framework
Fresh hereda características geniales de Deno como la ausencia de un paso de compilación, tiempos de iteración rápidos y soporte de TypeScript de forma nativa. Facilita la conversión de componentes estáticos en islas interactivas y el manejo de la obtención de datos para el renderizado en el servidor. Para comenzar con Fresh, descarga la CLI de Deno, ejecuta el comando de inicio y visita la página de inicio de Fresh para obtener más información.
te resultará muy familiar. Tienes web crypto a tu disposición si necesitas hacer cosas como hash, encriptación o desencriptación. Y otras características realmente geniales de Fresh que hereda de
Deno son que no hay un paso de compilación, lo que significa que tienes tiempos de iteración realmente rápidos. No necesitas ninguna configuración. Todo funciona de forma nativa, sin necesidad de configuración. Y
TypeScript también funciona de forma nativa sin necesidad de configuración, al igual que en
Deno. Echemos un vistazo a un poco de código, solo para ilustrar mi punto aquí. Esta es una ruta básica muy simple, como la que encontrarías en la mayoría de los proyectos. Para crear una ruta, colocas un archivo TSX o JSX en la carpeta de rutas de tu proyecto. En este caso, tengo una ruta llamada routes/about.tsx, que debido al enrutamiento del sistema de archivos estará disponible en /about en mi servidor web. Este es solo un componente JSX regular. Devuelve un marcado
HTML, que se renderiza en el lado del servidor para cada solicitud. Y eso de cada solicitud es importante, porque si tienes rutas dinámicas que contienen parámetros, por ejemplo, esta ruta, greed/:name, quieres poder cambiar la salida de tu ruta según los parámetros de entrada. En este caso, quieres leer el usuario específico que solicitó esa ruta. Y creo que una de las características más geniales de Fresh es cómo maneja las islas interactivas y lo fácil que es tomar un componente estático y convertirlo en una isla interactiva. Entonces, para convertir un componente estático en una isla interactiva, lo único que necesitas hacer en Fresh es colocarlo en la carpeta de islas, hay una carpeta llamada islas, colocas un componente JSX allí, lo importas desde tu ruta, lo usas en tu ruta y Fresh se encargará del resto. Se asegurará de que se envíe al cliente y se hidrate allí. También se asegurará de que cualquier cosa que sea estática, por ejemplo, esta ruta tiene un título y un párrafo estáticos, no se envíen al cliente como
JavaScript. Solo se envían al cliente como marcado estático. Y la obtención de datos también es algo muy importante en la actualidad si estás haciendo renderizado en el servidor. Esto está inspirado en
Remix en gran medida. Si has usado
Remix antes, has usado los controladores de datos y las funciones de obtención allí, te resultará muy familiar. Tienes una forma de tener una función que se ejecuta para cada solicitud, en la que puedes obtener datos y luego pasar esos datos al componente de la página o al componente de la ruta, donde esos datos se renderizan en
HTML. Incluso puedes pasar estos datos como propiedad de una isla y se serializarán e hidratarán automáticamente en el cliente. Esto fue muy rápido. Lo siento, no tenemos mucho tiempo. Si quieres comenzar por ti mismo con Fresh, descarga la
CLI de
Deno. Puedes hacerlo desde deno.land. Luego, ejecuta este comando de inicio aquí,
deno run -A https://fresh.deno.dev, que también resulta ser la página de inicio de Fresh. Si quieres obtener más información sobre Fresh, puedes ir allí, especificar un directorio para generar un proyecto, ingresar a ese directorio y ejecutar
deno run start. Y luego podrás ver tu
15. Mejorando el rendimiento de la página con Deno Deploy
Para mejorar drásticamente el rendimiento de la página, reduzca el tiempo de ida y vuelta de la red acercando el servidor al usuario. Con Deno Deploy, puedes ejecutar tu código en 34 regiones diferentes en todo el mundo, logrando implementaciones en dos a cinco segundos. Deno Deploy está a menos de 100 milisegundos de la mayoría de los usuarios de Internet en el mundo desarrollado. Échale un vistazo en deno.com/deploy. Netlify Edge Functions funciona con Deno Deploy.
nuevo sitio web en localhost 8000. Eso es Fresh. Quiero señalar otra cosa realmente genial aquí, que es que hemos hablado mucho sobre el renderizado en el servidor y los tiempos de ida y vuelta de la red hoy. Y una forma de mejorar drásticamente el rendimiento de tu página es simplemente reducir el tiempo de ida y vuelta de la red, lo cual suena muy difícil. Y dije anteriormente que era casi imposible, pero en realidad hay una forma en la que puedes tener mucho efecto en... En realidad hay una forma en la que puedes afectar esto mucho, que es simplemente acercar tu servidor al usuario. Si tienes un servidor en US East 1, si un usuario está en Tokio, necesita hacer un viaje de ida y vuelta de la red desde Tokio hasta US East 1. Eso son como 500 milisegundos. Eso es muy lento. Así que quieres evitar esto. Quieres tener un segundo servidor en Tokio. O ¿qué pasa si no tienes solo un segundo servidor, sino que tienes 30 servidores en todo el mundo, muy cerca de todos tus usuarios? Esto es algo que puedes hacer con
Deno Deploy. Los Despliegues de
Deno son una oferta de alojamiento de
Deno. Puedes darnos tu código de
Deno, lo ejecutaremos en 34 regiones diferentes en todo el mundo. Tiene una integración integrada con GitHub donde puedes enviar algo a tu repositorio de GitHub y luego lo implementaremos instantáneamente en estas 34 regiones en dos a cinco segundos. Y estamos a menos de 100 milisegundos de prácticamente todos los usuarios de Internet en el mundo desarrollado. Puedes comprobar esto en deno.com/deploy. Y si quieres ver algunos productos del mundo real que se construyen con
Deno Deploy, Netlify
Edge Functions funciona con
Deno Deploy. Así que si alguna vez has usado Netlify
Edge Functions, ya has usado
Deno Deploy. Genial, eso es todo. Aquí tienes algunos recursos finales que quiero compartir contigo. Si quieres aprender más sobre FRESH, ve a fresh.deno.dev,
Deno, puedes ir a deno.land, puedes encontrar el manual de
Deno, instrucciones de instalación, referencias de API, guías, todo eso en esa página. Si tienes alguna pregunta sobre
Deno o FRESH, puedes hacerlas en discord, discord.gg/
deno. Y si quieres hablar conmigo personalmente, mi correo electrónico está en mi sitio web en lcast.dev o puedes tuitearme o enviarme un mensaje directo en Twitter a lcasdev en Twitter. Y finalmente, actualmente estamos contratando, así que si algo de esto te pareció interesante y estás interesado en trabajar con nosotros en
Deno o en FRESH o en
Deno Deploy, actualmente estamos contratando varias posiciones diferentes, incluyendo
design, ingeniería de infraestructura, operaciones e ingeniería de rendimiento. Así que si algo de eso te parece interesante, por favor aplica, puedes encontrar todas las ofertas de trabajo y todos los detalles en deno.com. Y si tienes alguna pregunta, no dudes en contactarme en Twitter. Esa es mi charla, gracias a todos por ver y nos vemos la próxima vez. ¡Adiós!
React Summit 2023
Comments