A menudo asumimos que todos tienen una buena conexión a Internet y hardware con altas especificaciones. Si bien esto puede ser cierto en algunas regiones, no es el caso en todo el mundo. Quiero llamar la atención sobre África, donde muchos países luchan con conexiones 3G deficientes que son costosas, dependiendo de la cantidad de datos consumidos. Esto se debe a la infraestructura limitada del continente, lo que lleva a depender de las conexiones móviles.
Dadas estas circunstancias, el uso eficiente de datos con un buen rendimiento web se vuelve una prioridad. Por lo tanto, nuestra sesión se centrará en los desafíos que enfrentan los usuarios y desarrolladores africanos, y cómo la descarga de grandes cantidades de JavaScript está exacerbando el consumo de datos y los problemas de rendimiento. Exploraremos cómo los marcos existentes intentaron resolver el problema y cómo Qwik, con su enfoque innovador de resumibilidad, presenta una solución transformadora a estos desafíos. A diferencia de las aplicaciones de página única tradicionales, la resumibilidad de Qwik reduce drásticamente la carga inicial de JavaScript, lo que permite que las aplicaciones se vuelvan interactivas más rápidamente, incluso en conexiones lentas.
This talk has been presented at JSNation 2024, check out the latest edition of this JavaScript Conference.
La charla de hoy discutió el rendimiento web y la penetración de Internet en África, destacando los desafíos de los planes de datos limitados y los dispositivos menos potentes. Se enfatizó la importancia de considerar la accesibilidad a Internet al desarrollar sitios web, ya que los sitios web de carga lenta pueden resultar en críticas negativas y clientes perdidos. Se exploró el concepto de resumibilidad, que entrega solo el JavaScript necesario para mejorar el rendimiento, junto con la implementación del marco QUIC para lograr esto. También se discutió el marco QUIC en términos de ejecución perezosa y su capacidad para mejorar el rendimiento del sitio web y el consumo de recursos.
1. Web Performance and Internet Penetration in Africa
Short description:
Hoy hablaremos sobre el rendimiento web y el caso africano. La penetración de Internet en África es baja, especialmente en las regiones centrales y orientales. La mayoría de los africanos dependen de dispositivos móviles para acceder a Internet y tienen que pagar por cada megabyte consumido. Consideremos el precio de 15 gigabytes al mes, que se puede consumir fácilmente en unos pocos días. El tráfico web en África se comparte principalmente a través de dispositivos móviles.
Mi nombre es Eyo Belwen, soy el CTO de la Academia en Servio. Y hoy hablaremos sobre tecnología inclusiva. Antes de comenzar nuestra charla, será genial tener algo de contexto en África y cómo es la penetración de Internet allí. Comenzaremos con un gráfico aquí que muestra la penetración de Internet por región. Podemos ver en el medio el promedio mundial. El promedio mundial está entre el 60% y el 70%. Y podemos ver que Sudáfrica y el norte de África lo están haciendo bien. Cuando hablamos del norte de África, generalmente nos referimos a Marruecos, Argelia, Túnez. En el sur de África, se refiere a Sudáfrica. Pero podemos ver en el medio, África y el este, no lo están haciendo tan bien. Entonces, podemos ver que no hay penetración de Internet allí. Bien. Y no solo eso, podemos ver aquí con este gráfico que el tráfico web allí se comparte, podemos ver en este gráfico, el tráfico web compartido por tipo de dispositivo en África. Entonces, aquí lo que podemos ver es que la mayoría de los africanos allí dependen de dispositivos móviles. El 75% utiliza dispositivos móviles para acceder a Internet. Entonces, ¿por qué estoy hablando de esto? Lo que podemos ver aquí es que no hay fibra óptica, por ejemplo. Entonces, todos usarán su teléfono móvil para acceder a Internet. Y el problema aquí es que él debe pagar por cada megabyte que consuma. No es como usar ADCEL y tener internet limitado con ADCEL o fibra óptica. Solo son dispositivos móviles por los que debes pagar por cada megabyte que consumas. Bien. Y podemos ver aquí, por ejemplo, el precio de 15 gigabytes por mes. Entonces, imaginemos que todos usarán solo 15 gigabytes al mes. Y cuando hablamos de 15 gigabytes, creo que, por ejemplo, una hora de video de YouTube, tomará entre 500 megabytes y 1 gigabyte. Bien. Entonces, imagina si alguien está usando 15 gigabytes, no le durará mucho. Lo consumirá tal vez en tres o
2. Internet Accessibility Challenges in Africa
Short description:
En muchos países africanos, el precio de 15 gigabytes de internet al mes es equivalente o incluso mayor que el salario mínimo. Esto dificulta que las personas puedan pagar el acceso a Internet. Mientras que en Europa y Estados Unidos, el acceso ilimitado a Internet es común, en otras partes del mundo, las personas tienen que pagar por cada megabyte de datos. Por lo tanto, al desarrollar sitios web, debemos tener en cuenta las limitaciones que enfrentan los usuarios en estas regiones, como planes de datos limitados y dispositivos menos potentes.
cinco días. Y podemos ver aquí con este gráfico también el salario mínimo. Por ejemplo, podemos tomar Burkina Faso. El precio de 15 gigabytes al mes es casi el precio del salario mínimo allí. Entonces, debería pagar todo su salario para consumir solo 15 gigabytes al mes. Puedes ver conmigo, por ejemplo, Cabo Verde. El salario mínimo es tres veces el precio de 15 gigabytes de internet. Togo, es lo mismo. Y podemos ir más lejos. Por ejemplo, si vemos países como Zimbabwe o Malawi, podemos ver que el precio, por ejemplo, en Guinea Ecuatorial, el precio de 15 gigabytes de internet al mes es tres veces el salario mínimo. Entonces, para pagar 15 gigabytes al mes, debería pagar tres meses de salario. Eso no es bueno. Entonces, ¿por qué estoy hablando de esto? Estoy hablando de esto porque en el performance web, a veces en Europa o en Estados Unidos, no nos importa el internet que usamos porque es ilimitado. Vale. Entonces, no nos importa cuando estamos haciendo nuestros sitios web sobre el JavaScript que debemos entregar al lado del cliente sobre la optimización porque no necesitamos eso. Tenemos 5G o tenemos fibra óptica. Entonces, no necesitamos hacer eso. Pero en otras partes del mundo, hay personas que se preocupan por cada megabyte de internet porque están pagando su dinero por eso. Y cuando decimos pagar su dinero, no es una cosa pequeña, sino que es su salario. Entonces, por ejemplo, aquí, alguien en Zimbabwe no va a consumir 15 gigabytes al mes. Solo consumirán tal vez 500 megabytes o nada. Entonces, la forma en que estoy hablando de esto es que cuando intentamos trabajar en nuestros sitios web, debemos pensar en otras personas, no solo en Europa o Estados Unidos, sino que hay otras partes en el mundo de las que debemos preocuparnos cuando trabajamos en nuestros sitios web. Aquí, por ejemplo, podemos ver estadísticas sobre los teléfonos utilizados en África. Entonces, puedes ver que Apple, por ejemplo, no se usa mucho allí. Entonces, por ejemplo, en Zimbabwe, Nigeria, no es ni siquiera el 5% o el 3%. Vale. Y los teléfonos más utilizados son los teléfonos asequibles como Tecno, E-Tel, Xiaomi, Huawei y Samsung asequibles. Esa es la mayoría que la gente usa allí. Entonces, por qué digo eso es porque cuando usas un iPhone o un Samsung Ultra o algo así, no te importan los recursos porque estos teléfonos tienen una buena configuración de hardware. Vale. Entonces, cuando usas Google Chrome, usas algunas aplicaciones. No te importa el
3. Consideraciones para el rendimiento web
Short description:
Cuando se utilizan teléfonos inteligentes asequibles con recursos limitados, es importante evitar tener varias pestañas abiertas, especialmente con sitios web que entregan mucho JavaScript. Las limitaciones de las conexiones a Internet y del hardware en África y otras partes del mundo deben tenerse en cuenta al desarrollar sitios web. La experiencia del usuario es crucial y los sitios web de carga lenta pueden generar críticas negativas y pérdida de clientes. La invención de aplicaciones de una sola página, como las construidas con PHP y jQuery, ha simplificado el desarrollo web.
rendimiento del teléfono porque tienes un buen hardware. Vale. Pero cuando estás usando teléfonos inteligentes asequibles, no debes tener varias pestañas de Google Chrome abiertas porque consumirás todos los recursos que tienes y eso no será bueno. Vale. Y si tienes en cada pestaña, por ejemplo, sitios web que entregan mucho JavaScript eso consumirá más CPU, más RAM, eso no es bueno. Vale. Entonces, hay dos cosas. La primera cosa son las conexiones a Internet que no son buenas en África y el hardware. No es tan bueno. Entonces, debemos preocuparnos por estas dos cosas cuando estamos trabajando en nuestros sitios web. Y no solo eso, no solo África. También podemos pensar en el rendimiento web en nuestro contexto en Europa o en Estados Unidos. Si estás, por ejemplo, quieres ir a un restaurante, pides una simple pizza, pero el camarero te dice que debes esperar 45 minutos y que debes pagar $100. Esa no es una buena experiencia del usuario. Vale. Entonces, escribiremos malas críticas. Le dirás a tus amigos que nunca vengan a este restaurante y buscarás otro restaurante que te entregue la misma pizza en tal vez 15 o 10 minutos. Y pagando menos dinero. Eso es lo que importa. Y es lo mismo en nuestros sitios web. Si estás usando un sitio web de comercio electrónico que tarda mucho tiempo en cargar la página que quieres usar, pasarás a otro, buscarás otro. Tal vez olvidarás la página que estás usando. Y eso no es una buena experiencia. Vale. Entonces, cómo estamos aquí ahora. Lo que estoy tratando de hablar son las cosas técnicas. Después de usar PHP, usar jQuery, llegamos a una buena invención. Fue la aplicación de una sola página. Vale. Entonces, lo que debemos entender es cómo funciona la aplicación de una sola página.
4. Optimización de la entrega de JavaScript
Short description:
Para mejorar la experiencia del usuario, los desarrolladores web suelen utilizar la hidratación para entregar una versión no interactiva de la página primero, seguida de la ejecución de JavaScript para hacerla interactiva. Sin embargo, con las aplicaciones de una sola página, todo el JavaScript se entrega de antemano, incluso si el usuario no lo necesita todo. Esto puede llevar a descargas innecesarias y consumo de recursos. Para mitigar esto, los desarrolladores deben tratar de minimizar la cantidad de JavaScript entregado al lado del cliente.
Es muy fácil. En la primera vez entregamos en nuestra página un HTML que no contiene nada. Vale. Y esperamos a que nuestro JavaScript llegue. Ejecutamos el JavaScript, renderizamos la página y ahora nuestra página está aquí y es interactiva. Vale. Eso es bueno. Pero hay un problema. El cliente o el usuario debe esperar todo este tiempo para que se entregue su página. Vale. Pero lo que intentamos hacer es mejorar esta experiencia de usuario con la hidratación. Entonces, lo que hacemos es entregar un HTML grande que contiene toda la página, pero esta página no es interactiva. Aparece más rápido, pero no es interactiva. Y debemos esperar a este JavaScript. Debemos ejecutar este JavaScript y debemos hacer la reconciliación, la hidratación, para que nuestra página sea interactiva. El problema aquí es ¿qué? Con las aplicaciones de una sola página, estamos entregando todo el JavaScript que nuestro sitio web necesita para funcionar. Vale. Y si estás, por ejemplo, en Zimbabwe, le entregarás al chico mucho JavaScript que no necesitará, tal vez 13, tal vez 14 megabytes de JavaScript que no necesitará. Y eso no es bueno para él porque pagará por estos megabytes. Vale. Entonces, ¿qué debemos hacer? No es como, por ejemplo, la hidratación. La hidratación es buena, pero solo está engañando al usuario. Y al final, obtendrá todo el JavaScript. Descargará y ejecutará todo el JavaScript. Y estoy hablando de la descarga del JavaScript. No es bueno para su internet porque consumirá muchos megabytes. Y también la ejecución. Cuando ejecutes todo el JavaScript del sitio web, consumirá más recursos de su hardware. Y eso no es bueno para él. Entonces, lo que debemos intentar es entregar menos JavaScript al lado del cliente para no descargar mucho JavaScript y también para ejecutarlo.
5. Resumabilidad para mejorar el rendimiento
Short description:
Para mejorar el rendimiento del sitio web, es importante minimizar la cantidad de JavaScript entregado y ejecutado. La resumabilidad ofrece una solución al entregar solo el JavaScript necesario cuando se necesita, lo que resulta en páginas más rápidas y más interactivas.
la menor cantidad de JavaScript para no afectar los recursos de nuestro usuario. Vale. Y por eso estamos, vamos a hablar de aquí, vamos a hablar de, y eso es, podemos explicar eso con esta correlación, por ejemplo, porque en nuestros sitios web en estos días, necesitamos más interactividad. Tenemos muchos botones. Tenemos muchos gráficos. Entonces, cuando necesitamos más interactividad en nuestros sitios web, debemos entregar más JavaScript. Y cuando entregamos más JavaScript, descargamos más JavaScript. Ejecutamos más JavaScript. Entonces, tendremos menos rendimiento en nuestros sitios web. Vale. Entonces, la charla de hoy trata sobre la resumabilidad. Cómo podemos mejorar este proceso. Podemos mejorar este proceso al no entregar nada al lado del cliente. Aquí, podemos ver, por ejemplo, con la resumabilidad, entregamos el mismo HTML. La página está aquí e instantáneamente la página es interactiva sin entregar todo el JavaScript y ejecutarlo y hacer el proceso de reconciliación. Entonces, la pregunta aquí es cómo lo estamos haciendo. Es muy simple. En el primer HTML que entregamos, entregamos una pequeña cantidad, un kilobyte de JavaScript que se llama un escucha global, que escucha todas las interacciones del cliente y busca el JavaScript necesario. Por ejemplo, si el cliente hace clic en un botón, buscará el JavaScript necesario para este botón y lo ejecutará. No ejecutará algo que no necesitamos. De eso estoy tratando de hablar. Y no descargamos algo. Por ejemplo, si estamos en una página de inicio, no necesitamos la página de acerca de o la página de comercio electrónico. No nos importa eso. Entonces, ¿por qué descargaríamos y ejecutaríamos estas páginas? Vale, eso es
6. Implementando Resumabilidad con el Marco de QUIC
Short description:
Para mejorar el rendimiento del sitio web, es importante minimizar la cantidad de JavaScript entregado y ejecutado. La resumabilidad ofrece una solución al entregar solo el JavaScript necesario cuando se necesita. Google utiliza métricas como grandes elementos de contenido, retraso de la primera interacción y cambio acumulativo de diseño para medir la experiencia del usuario y clasificar los sitios web. Una demostración utilizando el marco de QUIC mostrará cómo funciona la resumabilidad.
¿Qué tal la resumabilidad? Se trata de entregar menos JavaScript, ejecutar menos JavaScript. Y con esta elección, al usar este paradigma, nuestras páginas aparecerán más rápido y las haremos interactivas más rápido. Y la correlación aquí será que tendremos más JavaScript, tendremos más interacción. Si queremos, si tenemos más interactividad, necesitaremos más JavaScript, pero escalaremos porque no afectaremos nuestro rendimiento ya que no descargaremos todo este JavaScript y no ejecutaremos todo este JavaScript. Si estás utilizando un framework SPA, tendrás 500 componentes. En la primera vez, descargarás los 500 componentes. Bien, pero al usar la resumabilidad, solo descargarás lo que necesitas en tu página y solo ejecutarás lo que el usuario necesita en la página. Bien, y no solo eso, no solo se trata de la experiencia del usuario o de África, también está Google que utiliza muchas métricas para medir tu sitio web. Por ejemplo, tenemos la primera que son grandes elementos de contenido. Mide los componentes más grandes en tu página. Toma cuánto tiempo se muestra en la página. También tenemos el retraso de la primera interacción que medirá el tiempo entre un botón, por ejemplo, se muestra en nuestra página y cuando es interactivo. Si tenemos un botón en nuestra página, pero debemos esperar más de 300 milisegundos para que sea interactivo, eso no es una buena experiencia del usuario. Y también tenemos el cambio acumulativo de diseño. Y es una métrica utilizada por Google para evaluar los elementos que se mueven en tu página. Por ejemplo, si tienes una página, pero después de dos segundos de mostrar la página, toda la página se mueve hacia abajo, eso no es una buena experiencia del usuario porque harás clic en algo que no necesitarás. Y estas métricas afectan la clasificación de tus sitios web en Google. Bien, lo que haremos ahora es ir con una demostración simple para mostrar cómo funciona la resumabilidad. Pero cuando hablamos de resumabilidad, hablamos de QUIC. Entonces este es un nuevo framework creado por el creador de Angular, Evrimishku, y se trata de la resumabilidad. Se trata de entregar menos JavaScript y ejecutar menos JavaScript en nuestro lado del cliente. Bien, comenzaremos con algo simple. Crearemos un nuevo componente y veremos conmigo cómo funciona eso. Entonces, index JSX, aquí crearé un componente simple. Por defecto. Hola, JS Nation. Y aquí, iré a mi JS Nation. Tengo mis componentes funcionando bien. Eso es bueno. Entonces, aquí, lo que haré es, como puedes ver, es JSX. Cuando usas QUIC,
7. Usando el Marco de QUIC para Interacciones de Botones
Short description:
QUIC es un nuevo marco que utiliza JSX y es similar a React. Permite a los desarrolladores crear fácilmente botones y ejecutar código JavaScript cuando se hace clic en los botones. Cuando se utiliza un marco SPA, se entrega y ejecuta mucho JavaScript detrás de los botones.
estamos usando QUIC. Es como cuando estás usando React. Es lo mismo. Si conoces React, conoces QUIC. Es un nuevo framework, pero utiliza JSX para que sea fácil para todos los desarrolladores acceder a él. Bien, aquí crearé un botón simple. Lo llamaré console JS Nation, y haré un simple evento de clic. Bien, y este evento de clic debería hacer un simple console log JS Nation console. Bien, guardaré esto. Crearé un segundo botón, console JS Nation, buscaré Amsterdam, y aquí, escribiré Amsterdam console. Eso está bien. Bien, he creado dos botones. Si estoy utilizando un framework SPA aquí, entregaremos este JavaScript. Lo que debes imaginar aquí es que detrás de este botón, hay mucho JavaScript que ejecutamos. Y si estás utilizando un framework SPA, entregaremos
8. Marco de QUIC y Ejecución de JavaScript
Short description:
Al usar QUIC, solo tienes el JavaScript que necesitas para tu página en la carga inicial. Un intermediario de servicios web descarga y almacena el JavaScript necesario en tu caché. El JavaScript se ejecuta y se renderiza en el DOM cuando interactúas con los botones.
en este JavaScript cuando accedemos a esta página. Bien, aquí tengo los dos botones, y aquí hice clic en JS para ver el JavaScript que tenía en la carga inicial. Podemos ver que en la carga inicial no tengo nada. Aquí, hice el menos VIT, porque no usamos VIT en producción. No necesitaremos el VIT en producción, así que hice menos VIT. Y aquí, podemos ver que no tenemos nada, no tenemos JavaScript. Entonces, cuando haga clic en este botón, obtendré el JavaScript necesario para él. Bien, JS Nation console. Y cuando haga clic en el segundo botón, obtendré el JavaScript necesario para él. Bien, si estás utilizando, por ejemplo, un framework SPA, obtendrás estos dos JavaScript aquí, porque los necesitas, porque los estás mostrando al cliente. Así que necesitarás este JavaScript. Pero al usar QUIC, no necesitarás hacer eso. Solo tendrás lo que deseas en la carga inicial. Entonces, aquí, por ejemplo, no estás consumiendo, no estás ejecutando todo el JavaScript que necesitas. Y la primera pregunta que puede venir a la mente es, ¿queremos esperar, y cada vez que haga clic en un botón, enviaré una solicitud al servidor para decirle, dame este JavaScript? No, porque al usar QUIC, estás utilizando un intermediario de servicios web que está haciendo una cosa simple. Está descargando el JavaScript que necesitas para tu página que estás mostrando aquí, y almacenándolos, este JavaScript, en tu caché. Bien, se llamará y se ejecutará. Entonces no ejecutarás nada en la carga inicial. No tienes el JavaScript necesario para estas dos páginas. Solo tienes lo que necesitas para tu página. E incluso este JavaScript que necesitas para tu página de inicio, no se ejecutará. Se ejecutará y se renderizará en el DOM cuando interactúes con estos botones.
9. Marco de QUIC y Ejecución Lazy
Short description:
Crearé un contador simple que se incrementa cuando se hace clic en un botón. Dependiendo del valor del contador, se mostrará JavaScript. La ejecución lazy es posible usando un signo de dólar. Solo se obtiene y adjunta al DOM el JavaScript necesario. QUIC proporciona carga y ejecución lazy incorporada, mejorando el rendimiento del sitio web y el consumo de recursos.
De acuerdo, y podemos profundizar más en eso. Aquí, por ejemplo, crearé un contador simple. Crearé un contador simple, usaré una señal. Y aquí, haré un botón que incremente esto. Entonces, un clic. Eso está bien. Y aquí, mostraré este JavaScript, solo si este contador es mayor que un valor, es mayor que uno, dos, cuatro. De acuerdo, si es solo uno, dos, tres, no funcionará. Aquí, puedo mostrar mi contador, el valor del contador. Y cuando haga clic en este contador, obtendré el JavaScript necesario. Pero obtendré este JavaScript que no necesito ahora. Y no tengo el contador porque el contador es solo uno, dos, tres. Pero obtuve algo de JavaScript que no necesito por ahora. Aquí, también puedo hacer una ejecución lazy del code. Es muy simple. Aquí crearé una función simple. Y la llamaré así. Usando un signo de dólar, puedo ejecutar lazy mi code. Aquí, por ejemplo, cuando haga clic y vea el botón, no obtendré el JavaScript para este botón. Solo obtendré un hash o un enlace al JavaScript que necesito. Y solo cuando necesite este JavaScript, ahora lo necesito porque el contador es mayor que uno, dos, tres, cuatro. Haré clic, obtendré este JavaScript Amsterdam Council y lo adjuntaré al DOM. Entonces, con QUIC, podemos hacer, es una carga lazy incorporada y una ejecución lazy incorporada. Y así es como podemos mejorar nuestro performance o el performance de nuestros sitios web, consumir menos internet y consumir menos recursos de nuestros dispositivos. Y gracias.
This transcription provides a brief guide to React rendering behavior. It explains the process of rendering, comparing new and old elements, and the importance of pure rendering without side effects. It also covers topics such as batching and double rendering, optimizing rendering and using context and Redux in React. Overall, it offers valuable insights for developers looking to understand and optimize React rendering.
Remix is a web framework built on React Router that focuses on web fundamentals, accessibility, performance, and flexibility. It delivers real HTML and SEO benefits, and allows for automatic updating of meta tags and styles. It provides features like login functionality, session management, and error handling. Remix is a server-rendered framework that can enhance sites with JavaScript but doesn't require it for basic functionality. It aims to create quality HTML-driven documents and is flexible for use with different web technologies and stacks.
Mishko, the creator of Angular and AngularJS, discusses the challenges of website performance and JavaScript hydration. He explains the differences between client-side and server-side rendering and introduces Quik as a solution for efficient component hydration. Mishko demonstrates examples of state management and intercommunication using Quik. He highlights the performance benefits of using Quik with React and emphasizes the importance of reducing JavaScript size for better performance. Finally, he mentions the use of QUIC in both MPA and SPA applications for improved startup performance.
The Talk discusses the shift to full-stack frameworks and the challenges of full-stack documentation. It highlights the power of interactive tutorials and the importance of user testing in software development. The Talk also introduces learn.svelte.dev, a platform for learning full-stack tools, and discusses the roadmap for SvelteKit and its documentation.
React 18's concurrent rendering, specifically the useTransition hook, optimizes app performance by allowing non-urgent updates to be processed without freezing the UI. However, there are drawbacks such as longer processing time for non-urgent updates and increased CPU usage. The useTransition hook works similarly to throttling or bouncing, making it useful for addressing performance issues caused by multiple small components. Libraries like React Query may require the use of alternative APIs to handle urgent and non-urgent updates effectively.
Suspense is a mechanism for orchestrating asynchronous state changes in JavaScript frameworks. It ensures async consistency in UIs and helps avoid trust erosion and inconsistencies. Suspense boundaries are used to hoist data fetching and create consistency zones based on the user interface. They can handle loading states of multiple resources and control state loading in applications. Suspense can be used for transitions, providing a smoother user experience and allowing prioritization of important content.
Los primeros intentos de Ivan en la depuración de rendimiento fueron caóticos. Vería una interacción lenta, intentaría una optimización aleatoria, vería que no ayudaba, y seguiría intentando otras optimizaciones hasta que encontraba la correcta (o se rendía). En aquel entonces, Ivan no sabía cómo usar bien las herramientas de rendimiento. Haría una grabación en Chrome DevTools o React Profiler, la examinaría, intentaría hacer clic en cosas aleatorias, y luego la cerraría frustrado unos minutos después. Ahora, Ivan sabe exactamente dónde y qué buscar. Y en esta masterclass, Ivan te enseñará eso también. Así es como va a funcionar. Tomaremos una aplicación lenta → la depuraremos (usando herramientas como Chrome DevTools, React Profiler, y why-did-you-render) → identificaremos el cuello de botella → y luego repetiremos, varias veces más. No hablaremos de las soluciones (en el 90% de los casos, es simplemente el viejo y regular useMemo() o memo()). Pero hablaremos de todo lo que viene antes - y aprenderemos a analizar cualquier problema de rendimiento de React, paso a paso. (Nota: Esta masterclass es más adecuada para ingenieros que ya están familiarizados con cómo funcionan useMemo() y memo() - pero quieren mejorar en el uso de las herramientas de rendimiento alrededor de React. Además, estaremos cubriendo el rendimiento de la interacción, no la velocidad de carga, por lo que no escucharás una palabra sobre Lighthouse 🤐)
Construir aplicaciones web instantáneas a gran escala ha sido elusivo. Los sitios del mundo real necesitan seguimiento, análisis y interfaces y interacciones de usuario complejas. Siempre comenzamos con las mejores intenciones pero terminamos con un sitio menos que ideal. QwikCity es un nuevo meta-framework que te permite construir aplicaciones a gran escala con un rendimiento de inicio constante. Veremos cómo construir una aplicación QwikCity y qué la hace única. El masterclass te mostrará cómo configurar un proyecto QwikCity. Cómo funciona el enrutamiento con el diseño. La aplicación de demostración obtendrá datos y los presentará al usuario en un formulario editable. Y finalmente, cómo se puede utilizar la autenticación. Todas las partes básicas para cualquier aplicación a gran escala. En el camino, también veremos qué hace que Qwik sea único y cómo la capacidad de reanudación permite un rendimiento de inicio constante sin importar la complejidad de la aplicación.
La web moderna sería diferente sin aplicaciones ricas del lado del cliente respaldadas por potentes frameworks: React, Angular, Vue, Lit y muchos otros. Estos frameworks se basan en JavaScript del lado del cliente, que es su núcleo. Sin embargo, existen otros enfoques para el renderizado. Uno de ellos (bastante antiguo, por cierto) es el renderizado del lado del servidor completamente sin JavaScript. Descubramos si esta es una buena idea y cómo Remix puede ayudarnos con ello? Prerrequisitos- Buen entendimiento de JavaScript o TypeScript- Sería útil tener experiencia con React, Redux, Node.js y escribir aplicaciones FrontEnd y BackEnd- Preinstalar Node.js, npm- Preferimos usar VSCode, pero también se pueden utilizar IDE en la nube como codesandbox (otros IDE también están bien)
- Introducción- Prerrequisitos para la masterclass- Estrategias de obtención: fundamentos- Estrategias de obtención – práctica: API de obtención, caché (estática VS dinámica), revalidar, suspense (obtención de datos en paralelo)- Prueba tu construcción y sírvela en Vercel- Futuro: Componentes de servidor VS Componentes de cliente- Huevo de pascua de la masterclass (no relacionado con el tema, destacando la accesibilidad)- Conclusión
Los primeros intentos de Ivan en la depuración de rendimiento fueron caóticos. Veía una interacción lenta, probaba una optimización aleatoria, veía que no ayudaba, y seguía probando otras optimizaciones hasta que encontraba la correcta (o se rendía). En aquel entonces, Ivan no sabía cómo usar bien las herramientas de rendimiento. Hacía una grabación en Chrome DevTools o React Profiler, la examinaba, intentaba hacer clic en cosas al azar, y luego la cerraba frustrado unos minutos después. Ahora, Ivan sabe exactamente dónde y qué buscar. Y en esta masterclass, Ivan te enseñará eso también. Así es como va a funcionar. Tomaremos una aplicación lenta → la depuraremos (usando herramientas como Chrome DevTools, React Profiler, y why-did-you-render) → identificaremos el cuello de botella → y luego repetiremos, varias veces más. No hablaremos de las soluciones (en el 90% de los casos, es simplemente el viejo y regular useMemo() o memo()). Pero hablaremos de todo lo que viene antes - y aprenderemos cómo analizar cualquier problema de rendimiento de React, paso a paso. (Nota: Esta masterclass es más adecuada para ingenieros que ya están familiarizados con cómo funcionan useMemo() y memo() - pero quieren mejorar en el uso de las herramientas de rendimiento alrededor de React. Además, cubriremos el rendimiento de interacción, no la velocidad de carga, por lo que no escucharás una palabra sobre Lighthouse 🤐)
Next.js es un marco convincente que facilita muchas tareas al proporcionar muchas soluciones listas para usar. Pero tan pronto como nuestra aplicación necesita escalar, es esencial mantener un alto rendimiento sin comprometer el mantenimiento y los costos del servidor. En este masterclass, veremos cómo analizar el rendimiento de Next.js, el uso de recursos, cómo escalarlo y cómo tomar las decisiones correctas al escribir la arquitectura de la aplicación.
Comments