¿Cuánta RAM está usando tu UseMemo? ¡Vamos a perfilarlo!

Rate this content
Bookmark
Slides

¡Memoriza todas las cosas!, es lo que la mayoría de las guías de React te dirán, explicando cómo su costo de memoria es insignificante en comparación con sus beneficios de rendimiento, pero ¿alguien realmente lo ha medido alguna vez? ¿Qué tal hacerlo en una aplicación React compleja con varios miles de componentes? Resulta que obtener esa respuesta no es simple en absoluto, y requiere adentrarse en el complejo mundo del perfilado de memoria de Chrome. Esta charla explorará los conceptos básicos del perfilado de heap, avanzando hacia herramientas y técnicas más avanzadas para analizar el uso de memoria en tu aplicación React, incluyendo cómo perfilarlo en tu pipeline de CI y responder a tus propias preguntas de optimización escribiendo analizadores de heap personalizados.

20 min
12 Dec, 2023

AI Generated Video Summary

El uso de memoria a menudo se pasa por alto en las aplicaciones web, pero el uso excesivo de memoria afecta el rendimiento y la experiencia del usuario. Es importante analizar el uso de memoria y optimizarlo, considerando conceptos como count versus size y shallow versus retain memory. El Chrome Memory Profiler y Memlab son herramientas útiles para analizar el uso de memoria. Al optimizar los componentes de React y usar herramientas como Memlab, el uso de memoria se puede reducir significativamente. Los hooks de React pueden ser costosos para proyectos a gran escala, y el análisis de memoria es una tarea desafiante.

1. Uso de memoria en aplicaciones web

Short description:

El uso de memoria a menudo se pasa por alto en las aplicaciones web. Optimizamos una aplicación React compleja, pero nuestro uso de memoria se volvió muy alto. Los navegadores limitan el uso de memoria, y el uso excesivo de memoria afecta el rendimiento y la experiencia del usuario.

El uso de memoria es una parte comúnmente pasada por alto en las aplicaciones web modernas, con frameworks como React intercambiándolo por performance y facilidad de desarrollo. La razón por la que hacemos esto es que normalmente las aplicaciones web son lo suficientemente simples. Y la memoria en los clientes es abundante. ¿Pero es esto siempre el caso? ¿Y qué hacemos cuando no lo es?

Hola, soy Giulio Zauza, soy ingeniero de software. Y quería traerte algunas lecciones que aprendí de la manera difícil mientras optimizaba una aplicación React compleja. De hecho, estoy trabajando en una aplicación web compleja llamada Flux. Es una herramienta CAD electrónica basada en navegador que permite un diseño rápido y colaborativo de circuitos eléctricos y PCB design. Bajo su capó, es una gran aplicación de tipo script que usa WebGL para renderizar documentos complejos, y está construida usando React, 3.js y Reactive Fiber.

Estamos trabajando duro en performance ya que queríamos que la aplicación fuera rápida y receptiva pero también escalable. Necesitamos poder soportar documentos gigantes con miles de componentes, cada uno hecho de docenas de formas complejas. Originalmente, pensamos que el tiempo congelado durante las interacciones y FPS eran las cosas a optimizar, pero pronto nos dimos cuenta de que eso era en realidad solo una parte del panorama. Al hacer ese tipo de optimization, a veces intercambias el uso de memoria por performance, lo cual es algo que en nuestro caso se volvió en nuestra contra. De hecho, construimos un sistema de renderizado usando mucha memorización siempre que fue posible, y usamos cachés para prevenir re-renderizados, y usamos muchas precomputaciones. Esto inicialmente comenzó a hacer que la performance fuera mejor, pero en cierto punto, en realidad empeoró las cosas. El uso de memoria era muy, muy alto al abrir proyectos más grandes y superaba fácilmente la marca del gigabyte. Hicimos esas optimizaciones porque seguimos lo que todavía se considera una mejor práctica para performance con React, que es usar la memorización tanto como sea posible. De hecho, incluso hay un artículo famoso que aboga por usar la memorización de React para cada valor de símbolo conocido. Lo que encontramos, sin embargo, es que usar esta estrategia puede volverse perjudicial ya que afectará su uso de memoria de formas incluso inesperadas.

Bueno, pero podrías preguntar, ¿por qué nos importa el uso de memoria? Especialmente ahora que los clientes tienen más RAM que nunca. Bueno, hay tres formas en las que el uso de memoria afecta negativamente a su aplicación. La primera es que los navegadores limitan mucho su uso de memoria. Chrome para escritorio, por ejemplo, tiene un límite de memoria duro alrededor de cuatro gigabytes por pestaña. En el momento en que superas ese límite, el navegador simplemente matará tu pestaña sin ninguna forma de recuperarte de ello. Y este límite se vuelve aún menor en dispositivos móviles como Safari, iOS, por ejemplo. La segunda razón es que cuanto más uso de memoria pesa en el recolector de basura. Incluso si estás tratando de optimizar solo por velocidad, probablemente verás muchas entradas en tus perfiles de tiempo relacionados con actividades de recolección de basura como mi GC mayor y menor. Eso está sucediendo cuando se realizan demasiadas asignaciones de memoria en un corto período de tiempo y el navegador se ve obligado a pausar tu aplicación para ocuparse de ellas. Y la tercera razón es que usar demasiada memoria empeora la user experience. Muchos usuarios están usando su dispositivo para varias cosas a la vez. Y esto significa que si tu aplicación web está reteniendo gigabytes enteros de memoria, harás que la user experience de todo lo demás que se ejecuta en su cliente sea significativamente peor.

2. Análisis del Uso de Memoria y Herramientas

Short description:

Es importante vigilar el consumo de memoria y optimizarlo. Nos centraremos en identificar el uso de memoria y hacer distinciones. El uso de memoria transitoria puede ser difícil de detectar y puede causar fallos en la aplicación. Los conceptos de conteo versus tamaño y memoria superficial versus retenida son importantes. Los diferentes tipos de asignación en JavaScript VM y el código JS también ocupan espacio. Vamos a explorar las herramientas disponibles para analizar el uso de memoria.

Y debido a esas razones, diría que probablemente, independientemente del tipo de aplicación que estés construyendo, siempre es una buena idea vigilar el consumo de memoria de tu aplicación y optimizarlo cuando sea necesario, especialmente ahora que Chrome está empezando a informar a los usuarios sobre el consumo de memoria de las pestañas individuales cuando pasas el cursor sobre el título de la pestaña. Imagina ejecutar una simple aplicación de lista de tareas y ver que ocupa medio gigabyte. Diría que esa no es una buena impresión.

Entonces, supongamos que te encuentras en una de esas situaciones y quieres mejorar las cosas para tu aplicación. ¿Cómo lo haces? Bueno, el enfoque que suelo seguir se basa en tres puntos. El primero es que necesitas identificar qué es lo que está ocupando tanta memoria en tu aplicación. Y luego, una vez que has encontrado lo que está ocupando demasiada RAM, puedes usar algunas estrategias para optimizarlo. Y por último, quieres intentar evitar que esas cosas vuelvan a suceder en el futuro. Y puedes usar pruebas de memoria automatizadas en tu pipeline de CI para esto. En esta masterclass, nos centraremos solo en el primer punto, ya que los otros dos puntos también son muy grandes y dependen de la implementación.

Cuando se trata de analizar el uso de memoria, creo que es útil introducir algunos términos y hacer algunas distinciones primero. La primera es sobre el uso de memoria transitoria versus estática. Llamamos uso de memoria estática al conjunto de asignaciones de memoria que permanecen algo estables durante la ejecución de la aplicación, y es la que esperarías encontrar al tomar una instantánea del heap cuando tu aplicación está en estado estable. El uso de memoria transitoria, en cambio, es cuando tu aplicación asigna mucha memoria de una vez y la libera poco después, creando un pico en el uso de memoria. Esto podría ser muy difícil de detectar solo con una instantánea del heap, y un pico muy grande podría hacer que tu aplicación se bloquee.

Otra distinción importante es conteo versus tamaño. Puedes tener unidades individuales de asignación que ocupan mucha memoria. Pero también puedes tener muchas asignaciones más pequeñas, que por sí solas son lo suficientemente pequeñas. Pero juntas llenan tu RAM. En el segundo caso, puede ser más difícil encontrarlas y optimizarlas. Luego tenemos dos términos que aparecen a menudo en los perfiles de memoria, que son memoria superficial y retenida. Como JavaScript se basa en el uso de estructuras de data anidadas y punteros, hay una distinción entre el tamaño de un objeto en sí versus el tamaño al que ese objeto apunta. Por ejemplo, podemos tener un array de 10 elementos, cada uno siendo una cadena diferente con un millón de caracteres cada uno. Debido a su tamaño, las cadenas ocuparán en total alrededor de 10 megabytes, mientras que el array solo ocupará unas pocas docenas de bytes. Dado que el array está conteniendo y reteniendo esas cadenas, diremos que el tamaño retenido de ese array sería de 10 megabytes de todos modos, ya que es la razón por la que la cadena se ha mantenido en memoria de todos modos.

Lo último que creo que es importante introducir son los diferentes tipos de asignación dentro de la Máquina Visual de JavaScript. Chrome, por ejemplo, hace la distinción entre objetos, arrays, cadenas, arrays tipados, y también es importante notar cómo incluso tu código JS ocupa espacio en memoria. Y al navegar por los resultados de una instantánea de memoria, puedes aprender algunas cosas muy interesantes, como el hecho de que la función JS por sí sola puede ocupar espacio como si fueran objetos, ya que necesitan llevar un registro de sus cierres. Por lo tanto, es mejor evitar crear funciones en bucles por esta razón.

Bien, ahora que hemos establecido algunos términos, veamos las herramientas que están disponibles para analizar el uso de memoria.

3. Análisis del Uso de Memoria y Herramientas

Short description:

El Analizador de Memoria de Chrome ofrece dos opciones de análisis útiles: instantánea del heap y muestreo de asignaciones. Las instantáneas del heap proporcionan un desglose de los tipos de objetos y la retención de memoria. El muestreo de asignaciones ayuda a identificar los picos de uso de memoria. Al analizar la instantánea, descubrimos un objeto de mapa grande que causaba un alto uso de memoria. Resultó ser una variable global utilizada para las suscripciones a eventos. Eliminar el hook useState y reemplazar el mapa por un set redujo el uso de memoria hasta en un 50%. Sin embargo, la mayoría de la huella de memoria está dominada por objetos más pequeños, que son difíciles de optimizar individualmente. El analizador de memoria de Chrome no agrupa los objetos por tipo, pero exportar la instantánea del heap a un archivo JSON permite un análisis estadístico utilizando herramientas como Memlab.

El punto de partida es, por supuesto, el Analizador de Memoria de Chrome, que tiene tres opciones de análisis disponibles. Es posible que descubras que la instantánea del heap y el muestreo de asignaciones son las opciones más útiles. Pero para dos propósitos diferentes. La instantánea del heap toma una imagen completa del uso actual de la memoria en un punto dado en el tiempo, proporcionándote un desglose de los tipos de objetos en memoria y por qué se están reteniendo. Usando una instantánea del heap, puedes observar diferentes tipos de objetos, su uso de memoria superficial, y su uso de memoria retenida como dijimos antes.

Con cualquier instantánea, sin embargo, te falta información sobre lo que está cambiando con el tiempo y no puedes observar los picos transitorios de uso de memoria. Si estás interesado en los picos de uso de memoria, puedes utilizar el método de muestreo de asignaciones. Puedes iniciarlo y detenerlo más tarde y después de ejecutarlo durante algún tiempo, te proporciona un gráfico, describiendo cuánto se asignó durante el tiempo y por qué funciones. Esta es una herramienta realmente poderosa para depurar picos de uso de memoria, pero es menos adecuada para analizar la huella de memoria total de tu aplicación en un estado estable. Y solo usando estas dos herramientas, puedes hacer optimizaciones de uso de memoria realmente poderosas.

Por ejemplo, puedo mostrarte cómo las usamos para optimizar la actualización y el trabajo. Después de tomar una instantánea de memoria de la aplicación Flux en un estado estable, podemos hacer clic en las columnas de tamaño superficial y retenido para ordenar los tipos de asignación por uso de memoria y con suerte encontrar los mayores infractores y eliminarlos. Podemos verificar ambos, tanto retenido como superficial, para que podamos encontrar tanto asignaciones individuales grandes como ubicaciones más pequeñas que están reteniendo una gran cantidad de memoria. Y mientras mirábamos esa lista, había algo que destacaba de inmediato.

Tenemos muchos objetos de mapa, alrededor de 10,000, la mayoría de ellos bastante pequeños, pero aparte del primero, que estaba ocupando alrededor de 84 megabytes de RAM. Y eso inmediatamente pareció una gran alerta roja ya que no sabía que teníamos un mapa tan grande para algo en la aplicación. Y en la parte inferior de la interfaz de usuario del perfilador, podemos ver por qué y quién estaba reteniendo ese gran objeto de mapa, que resultó ser una variable global que estábamos utilizando para suscribirnos a eventos. De hecho, cada vez que en nuestra aplicación ocurre una suscripción, estamos utilizando un hook useState para generar y almacenar un UID de cadena, que luego se utilizaba para eliminar la suscripción en CleanApp. Resultó ser extremadamente ineficiente para el consumo de memoria, ya que necesitaba instanciar el hook useState, almacenar la cadena, y también mantener el cierre alrededor de esa función lambda. Y al eliminar esa llamada al hook useState y reemplazar el mapa que mantenía las cadenas solo por una estructura de conjunto data, pudimos reducir la huella de memoria de las suscripciones, lo que ahorró incluso un 50% de RAM en algunos casos. Y este es un ejemplo de una estructura de datos data obviamente ineficiente en memoria, que fue fácil de encontrar y optimizar.

Desafortunadamente, sin embargo, eso no siempre es el caso. De hecho, fue una de las pocas cosas fáciles que pudimos optimizar en nuestra aplicación. Si miras este perfil, puedes ver cómo la mayoría restante de la huella de memoria está dominada por objetos. Y desafortunadamente, ya no tenemos un solo objeto para optimizar, sino más bien dos millones de instancias de objetos más pequeños que se mantienen en memoria. El analizador de memoria de Chrome no facilita la comprensión ya que no agrupa los objetos por tipo. Y no hay forma de que puedas desplazarte manualmente por todos ellos y averiguar qué está pasando. Afortunadamente, sin embargo, el analizador de memoria de Chrome puede exportar tu instantánea del heap a un archivo JSON. Así que hay esperanza para nosotros para realizar algún análisis estadístico sobre ellos. Sin tener que escribir mucho código, un importador y un analizador nosotros mismos, hay una herramienta fantástica para analizar esos archivos llamada Memlab.

4. Análisis del Uso de Memoria con Memlab

Short description:

Memlab es un paquete completo para el análisis de memoria. Puede detectar fugas de memoria, ejecutarse en tuberías de CI y analizar instantáneas del heap. Al agrupar objetos por tipo y propiedades, podemos entender el uso de la memoria. Los hooks de React, como useState y useMemo, utilizan una estructura de datos llamada nodo de fibra. Simplifique y optimice los hooks para reducir el uso de la memoria. Otro analizador de Memlab ayuda a identificar los componentos de React más pesados en términos de uso de memoria.

Y Memlab es mantenido por Meta Open Source, y es un paquete completo para el análisis de memoria. Por ejemplo, se puede utilizar para detectar automáticamente fugas de memoria en tu aplicación, o incluso puede ejecutarse en tuberías de CI para verificar periódicamente tu uso de memoria, lo cual es realmente genial.

Otra característica interesante de Memlab es que puedes usarlo como un marco para realizar análisis en instantáneas del heap. De hecho, puedes escribir tu propio plugin de análisis usando JavaScript. He desarrollado algunos que me ayudaron a entender mejor la huella de memoria de mi aplicación. Y compartiré el código de esos para que otras personas también puedan usarlos.

Y el primer analizador que hice fue para responder a la pregunta, ¿qué tipos de objetos están ocupando más espacio de los dos millones que encontramos en una instantánea? Y para responder a esta pregunta, escribí este plugin de analizador que carga la instantánea del heap, agrupa los objetos por tipo, por el nombre de las propiedades que tienen dentro, y acumula su tamaño juntos, ordenándolos por mayor tamaño primero. De esta manera espero darle sentido a los cientos de megabytes que están siendo ocupados por objetos más pequeños.

Ejecuté el análisis en una instantánea de mi aplicación y los resultados que obtuve fueron realmente interesantes. El tipo de objetos que ocupaba el mayor tamaño en la aplicación tenía esta forma, con nombres de propiedades, base queue, base state, memorize state, next state, next end queue. No era un objeto que formaba parte de mi aplicación, pero me preguntaba de dónde venía. Y en realidad venía de los canales del marco de React. Y así es como funcionan internamente los hooks de React. De hecho, cada componente de React que se renderiza mantiene su información de estado en una estructura de datos llamada nodo de fibra. Cada objeto de nodo de fibra contiene una propiedad de estado memorizado, que es un puntero a una lista enlazada que contiene toda la información sobre tus hooks. Cada vez que realizas una llamada de hook en tu componente de React, se asigna un nuevo objeto de ese tipo y se añade a la propiedad next en esa lista enlazada. El valor de ese hook se almacena entonces en la propiedad de estado memorizado del nodo de la lista enlazada. Esta estructura de datos es utilizada por React cuando necesita renderizar ese componente, ya que puede recorrer la lista enlazada con cada llamada de hook, como useState, useMemo, useCallback, y obtener el valor que necesita devolver. Y por eso el orden de las llamadas de hook importa.

Al leer estos resultados del análisis del heap, obtuvimos una visión interesante. Los useMemos y los hooks son costosos, pero no por la razón que podrías pensar. No es realmente el contenido del valor memorizado en sí el que está ocupando mucho espacio, sino más bien todas las estructuras de soporte que son necesarias para que el hook funcione. Así que a partir de esto, obtuvimos una estrategia. Simplificar, fusionar, eliminar todos los hooks que tenemos en el camino crítico, y reducirlos tanto como sea posible. La gran pregunta, sin embargo, era cuáles componentes de React son los más pesados, y necesitamos optimizar primero para obtener el mayor beneficio de memoria. Para responder a esta pregunta, escribimos otro analizador de Memlab, que hizo las siguientes cosas. Primero, encuentra todas las estructuras de datos Fibernode en la instantánea de memoria. Para cada Fibernode, determina a qué componente de React pertenece mirando la propiedad de tipo. Luego calcula estadísticas sobre ese Fibernode, como qué hooks estaba utilizando y cuánta memoria estaba ocupando y luego acumula todas las estadísticas calculadas, agrupándolas por Tipo de Componente de React. Y al hacer esto, finalmente pudimos entender cuáles componentes de React eran los más pesados en términos de uso de memoria.

5. Optimización de Componentes React y Análisis de Memoria

Short description:

Optimizamos los componentes React más pesados y redujimos el uso de memoria en un 50%. Usa nuestro código para resolver problemas de memoria. Memlab ayudó a responder preguntas sobre las asignaciones de memoria de las cadenas. La transición a UIDs numéricos solo ahorraría un par de megabytes. El análisis de memoria es difícil y las optimizaciones pueden salir mal. El perfilador de Chrome es útil, pero herramientas como Memlab proporcionan un análisis más profundo. Los hooks de React son costosos para proyectos a gran escala. Se agradeció a los asistentes por su participación.

Lo utilizamos para decidir qué optimizar primero. Y después de optimizar incluso solo el primero de la lista, los componentes de React más pesados que teníamos, pudimos reducir en un 50% el uso de memoria en nuestra aplicación. Y ahora también puedes intentar hacer lo mismo con tu código si tienes problemas de memoria con el código que vamos a publicar.

Luego usamos Memlab para responder a otras preguntas que teníamos sobre nuestro uso de memoria. Una, por ejemplo, era sobre las asignaciones de memoria de las cadenas. De todas las cadenas que teníamos, ¿cuántas de ellas eran UIDs? ¿Deberíamos pasar de UIDs de cadena a UIDs numéricos? Bueno, el analizador de Memlab que hicimos nos permitió obtener una respuesta a esa pregunta. Y en realidad descubrimos que podríamos haber ahorrado solo un par de megabytes, por lo que no valía la pena por ahora.

Entonces, para resumir lo que aprendimos al analizar el uso de memoria. Lo primero es que el análisis de memoria es difícil y a veces la optimización que crees que mejorará las cosas puede salir mal. Por lo tanto, realizar análisis de este tipo ayuda mucho. Lo segundo es que el perfilador de Chrome es genial y es muy útil, pero a veces tienes que analizar las cosas más a fondo utilizando herramientas como Memlab que incluso es personalizable y puedes usarlo para responder tus propias preguntas. Y lo último es que los hooks de React no son baratos especialmente cuando tienes miles de instancias de los mismos componentes de React. Así que si estás construyendo algo grande con React, tenlo en cuenta. Y gracias por asistir a esta masterclass. Espero que esto te ayude a descubrir por qué tu aplicación está consumiendo tanta RAM. Y feliz perfilado.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

React Advanced Conference 2022React Advanced Conference 2022
25 min
A Guide to React Rendering Behavior
React is a library for "rendering" UI from components, but many users find themselves confused about how React rendering actually works. What do terms like "rendering", "reconciliation", "Fibers", and "committing" actually mean? When do renders happen? How does Context affect rendering, and how do libraries like Redux cause updates? In this talk, we'll clear up the confusion and provide a solid foundation for understanding when, why, and how React renders. We'll look at: - What "rendering" actually is - How React queues renders and the standard rendering behavior - How keys and component types are used in rendering - Techniques for optimizing render performance - How context usage affects rendering behavior| - How external libraries tie into React rendering
React Summit 2023React Summit 2023
32 min
Speeding Up Your React App With Less JavaScript
Too much JavaScript is getting you down? New frameworks promising no JavaScript look interesting, but you have an existing React application to maintain. What if Qwik React is your answer for faster applications startup and better user experience? Qwik React allows you to easily turn your React application into a collection of islands, which can be SSRed and delayed hydrated, and in some instances, hydration skipped altogether. And all of this in an incremental way without a rewrite.
React Summit 2023React Summit 2023
23 min
React Concurrency, Explained
React 18! Concurrent features! You might’ve already tried the new APIs like useTransition, or you might’ve just heard of them. But do you know how React 18 achieves the performance wins it brings with itself? In this talk, let’s peek under the hood of React 18’s performance features: - How React 18 lowers the time your page stays frozen (aka TBT) - What exactly happens in the main thread when you run useTransition() - What’s the catch with the improvements (there’s no free cake!), and why Vue.js and Preact straight refused to ship anything similar
JSNation 2022JSNation 2022
21 min
The Future of Performance Tooling
Our understanding of performance & user-experience has heavily evolved over the years. Web Developer Tooling needs to similarly evolve to make sure it is user-centric, actionable and contextual where modern experiences are concerned. In this talk, Addy will walk you through Chrome and others have been thinking about this problem and what updates they've been making to performance tools to lower the friction for building great experiences on the web.
JSNation 2023JSNation 2023
26 min
When Optimizations Backfire
Ever loaded a font from the Google Fonts CDN? Or added the loading=lazy attribute onto an image? These optimizations are recommended all over the web – but, sometimes, they make your app not faster but slower.
In this talk, Ivan will show when some common performance optimizations backfire – and what we need to do to avoid that.

Workshops on related topic

React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Featured WorkshopFree
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
JSNation 2023JSNation 2023
170 min
Building WebApps That Light Up the Internet with QwikCity
Featured WorkshopFree
Building instant-on web applications at scale have been elusive. Real-world sites need tracking, analytics, and complex user interfaces and interactions. We always start with the best intentions but end up with a less-than-ideal site.
QwikCity is a new meta-framework that allows you to build large-scale applications with constant startup-up performance. We will look at how to build a QwikCity application and what makes it unique. The workshop will show you how to set up a QwikCitp project. How routing works with layout. The demo application will fetch data and present it to the user in an editable form. And finally, how one can use authentication. All of the basic parts for any large-scale applications.
Along the way, we will also look at what makes Qwik unique, and how resumability enables constant startup performance no matter the application complexity.
React Day Berlin 2022React Day Berlin 2022
53 min
Next.js 13: Data Fetching Strategies
WorkshopFree
- Introduction- Prerequisites for the workshop- Fetching strategies: fundamentals- Fetching strategies – hands-on: fetch API, cache (static VS dynamic), revalidate, suspense (parallel data fetching)- Test your build and serve it on Vercel- Future: Server components VS Client components- Workshop easter egg (unrelated to the topic, calling out accessibility)- Wrapping up
React Advanced Conference 2023React Advanced Conference 2023
148 min
React Performance Debugging
Workshop
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
Vue.js London 2023Vue.js London 2023
49 min
Maximize App Performance by Optimizing Web Fonts
WorkshopFree
You've just landed on a web page and you try to click a certain element, but just before you do, an ad loads on top of it and you end up clicking that thing instead.
That…that’s a layout shift. Everyone, developers and users alike, know that layout shifts are bad. And the later they happen, the more disruptive they are to users. In this workshop we're going to look into how web fonts cause layout shifts and explore a few strategies of loading web fonts without causing big layout shifts.
Table of Contents:What’s CLS and how it’s calculated?How fonts can cause CLS?Font loading strategies for minimizing CLSRecap and conclusion
React Summit 2022React Summit 2022
50 min
High-performance Next.js
Workshop
Next.js is a compelling framework that makes many tasks effortless by providing many out-of-the-box solutions. But as soon as our app needs to scale, it is essential to maintain high performance without compromising maintenance and server costs. In this workshop, we will see how to analyze Next.js performances, resources usage, how to scale it, and how to make the right decisions while writing the application architecture.