Ganando la Carrera de Rendimiento

Rate this content
Bookmark

Durante los últimos dos años, hemos mejorado drásticamente el rendimiento de los sitios web de Wix, superando a todos nuestros competidores en Core Web Vitals. Este proyecto fue un esfuerzo de toda la empresa para finalmente resolver la queja número uno de los usuarios en la empresa: el rendimiento del sitio en vivo.


En esta charla, haré una inmersión profunda en los cambios de diseño que se implementaron para lograr esta mejora significativa, y explicaré por qué y cómo esas soluciones podrían aplicarse en cualquier aplicación web para obtener resultados similares.

21 min
23 Oct, 2023

AI Generated Video Summary

La charla de hoy se centra en mejorar el rendimiento de los sitios web de Wix a través de un cambio de arquitectura que redujo el tamaño de JavaScript y mejoró las métricas de Core Web Vitals. La implementación de una característica con datos guardados requirió reescribir componentes y calcular datos de vista en un servidor frontend separado. Este enfoque condujo a una aplicación cliente más pequeña y rápida y permitió el almacenamiento en caché en la CDN. Las conclusiones clave incluyen la reducción de la descarga de JavaScript, el uso de componentes específicos de características y el almacenamiento en caché de las respuestas del servidor.

1. Mejorando el Rendimiento de los Sitios Web de Wix

Short description:

Hoy quiero contarles cómo mejoramos el rendimiento de millones de sitios web de Wix. Invertimos mucho en rendimiento e implementamos un gran proyecto que generó una mejora masiva. Core Web Vitals es una métrica que Google desarrolló para medir la experiencia del usuario en los sitios web, y podemos usarla para medir nuestras aplicaciones web. El proyecto que estoy a punto de presentar fue uno de los mayores influenciadores para esta mejora.

Hola a todos. Gracias por unirse. Mi nombre es Gil. Soy un ingeniero de software en Wix, y hoy quiero contarles cómo mejoramos el performance de millones de sitios web de Wix.

Para aquellos de ustedes que no lo saben, Wix es una plataforma para crear sitios web y aplicaciones web, y dado que los sitios web de Wix pueden ser muy complejos con muchas características y componentes diferentes, performance siempre ha sido uno de nuestros mayores desafíos. En los últimos años, invertimos mucho en performance. Implementamos muchas soluciones para optimizar sitios web, pero hoy quiero centrarme en un gran proyecto que generó una mejora masiva en performance.

Pueden ver el impacto de performance aquí. Este es un gráfico basado en métricas de Core Web Vitals. Estoy seguro de que muchos de ustedes ya saben lo que es, para aquellos de ustedes que no lo saben. Core Web Vitals es una métrica que Google desarrolló para medir la user experience de los sitios web en internet, y podemos usar Core Web Vitals para medir nuestras aplicaciones web, las aplicaciones que renderizan los sitios web de Wix. Pueden ver a Wix en el gráfico naranja, se compara con otras plataformas web o competidores, y pueden ver cuánto hemos mejorado, desde tener resultados muy bajos de Core Web Vitals hace solo unos años, hasta tener uno de los mejores resultados de Core Web Vitals, relativamente en un corto período de tiempo, y por supuesto esos resultados reflejan la user experience en nuestros sitios web. Entonces, aunque muchas cosas sucedieron durante este tiempo, el proyecto que estoy a punto de presentar a ustedes fue uno de los mayores influenciadores para esta mejora.

2. Mejorando el rendimiento de los sitios web de Wix (Parte 2)

Short description:

Hoy quiero hablar sobre el camino que recorrimos para mejorar el rendimiento de los sitios web de Wix. Implementamos un gran proyecto que requirió un cambio en la arquitectura de la aplicación. Al disminuir drásticamente la cantidad de JavaScript enviado a los sitios web de Wix, pudimos abordar los problemas de rendimiento. Explicaré por qué el tamaño de JavaScript es un problema y daré un ejemplo de cómo afectó nuestro código. Este es un problema común en muchas aplicaciones.

Bien. Entonces, en primer lugar, mi nombre es Gil. Soy un ingeniero de software en Wix, y en Wix formo parte del equipo de visualización. En el equipo de visualización desarrollamos la aplicación que renderiza los sitios web de Wix. Así que cada vez que un usuario visita un sitio web de Wix, nuestra aplicación se ejecuta y renderiza el sitio web.

Así que en los últimos dos años estoy liderando el equipo de performance donde intentamos encontrar y también, por supuesto, resolver problemas de performance en los sitios web de Wix. Volviendo a este gráfico, hoy quiero hablar sobre el camino que recorrimos. Antes de sumergirme en el proyecto y las soluciones de cómo realmente mejoramos la performance de los sitios web de Wix, quiero comenzar explicando los problemas que nos hicieron tener resultados tan bajos y, por supuesto, la user experience, y luego también, por supuesto, explicar la solución que solucionó esos problemas.

Es importante para mí decirles que ninguno de esos problemas y soluciones de los que voy a hablar son específicos de Wix. Ninguno de ellos es realmente específico de Wix. Tal vez, al principio, comenzaré con un ejemplo de nuestra aplicación, pero muy rápido también hablaré de por qué creo que esos problemas y también esas soluciones se pueden encontrar e implementar en cualquier aplicación web. Hablaré más de esto más tarde. Entonces, como dije antes, hay muchas cosas que hicimos y también que cualquiera puede hacer para mejorar la performance de las aplicaciones web en general, pero hoy quiero centrarme en lo más importante e impactante que hicimos. Implementamos muchas, muchas, muchas soluciones diferentes, pero lo que voy a hablar es en realidad el proyecto más grande. Fue el proyecto más grande que implementamos. También, creo, el problema más difícil que resolvimos, porque no son algunas líneas de código que puedes agregar a tu aplicación. Al resolver este problema, en realidad requiere más de un cambio en la architecture de la aplicación. Tuvimos que reescribir muchas partes de nuestra aplicación para resolver este problema. No es algo que simplemente cambie unas pocas líneas de código y todo se resuelva. Requirió un gran cambio, y por lo general, la mayoría de las aplicaciones requieren un cambio mayor. Hoy, quiero contarles cómo disminuimos drásticamente la cantidad de JavaScript que enviamos a los sitios web de Wix. Esto es en lo que me voy a centrar hoy.

Para aquellos de ustedes que están menos familiarizados con este problema, pueden ver cuánto JavaScript está descargando y ejecutando una aplicación en el navegador yendo a la pestaña de red en las herramientas de desarrollo del navegador, y en la parte inferior, pueden ver que tienen el tamaño de transferencia del JavaScript. En la pestaña de JavaScript, pueden ver el tamaño de transferencia y el tamaño del recurso. Ambos son importantes, la diferencia entre ellos es la compresión del JavaScript, lo que se descarga está comprimido, y el navegador lo descomprime y lo ejecuta, por lo que generalmente el tamaño del recurso que el navegador está ejecutando es en la mayoría de los casos mayor que el tamaño de transferencia, alrededor de 3, 4, 5, realmente depende del código.

Entonces, en primer lugar quiero hablar de por qué el tamaño de JavaScript es en realidad un problema, qué nos causó tener una cantidad tan grande de JavaScript que en realidad nos causó tener muchos problemas de performance, así que quiero tocar exactamente qué en nuestro código era en realidad el problema. Y voy a dar un ejemplo de una característica en un componente para demostrar este problema, pero luego por supuesto explicaré por qué este problema ocurrió en todo nuestro código. Y también por supuesto cómo es un problema muy común en muchas aplicaciones. Entonces, voy a comenzar con un ejemplo simple, es el ejemplo de una característica que tenemos en un componente de botón, y es la característica que permite a nuestros usuarios cuando agregan botones, como dije Wix es una plataforma para crear sitios web, o puedes agregar componentes y puedes agregar características a esos componentes, así que en este ejemplo es la característica de enlace del componente de botón, puedes definir a dónde quieres que vaya la página, qué página, o lo que quieras que suceda cuando el usuario haga clic en el botón, en realidad el usuario del sitio web. Entonces, como puedes ver en este panel, puedes elegir qué hacer cuando se hace clic en el botón, en caso de enlace, por supuesto, quieres enlazar a algún lugar, puedes enlazar a una página, puedes enlazar a una dirección web externa, puedes enlazar a un correo electrónico, un número de teléfono, abrir un lightbox, puedes hacer muchas cosas, en caso de un enlace de página, puedes elegir a qué página navegar y también cómo abrirla, tantas opciones, puedes elegir configurar este objeto de enlace.

3. Implementando la Característica con Datos Guardados

Short description:

Echemos un vistazo a cómo alguien implementaría esta característica. Guardamos los datos del panel en una base de datos y los pasamos a un componente de botón. El componente renderiza diferentes HTML dependiendo de si se añade un enlace o no. Esta diferenciación es importante para fines de SEO. Este es un simple componente de React que implementa la característica que acabamos de presentar.

Y pensemos en cómo alguien implementaría esta característica. Por supuesto, tendrías que guardar los data del panel, ¿verdad? Quiero decir, el desarrollador probablemente tomó todos los data del panel, los guardó en una database. Echemos un vistazo a los data guardados de nuevo.

Ejemplo simple de los data que se guardaron basándose en el panel. Así que tenemos los data del patrón. Por supuesto que tiene un ID y un tipo pero también dentro de la propiedad data puedes ver el objeto link. El objeto link incluye el tipo de enlace que el usuario eligió. En este caso era un enlace, un enlace de página. Significa que quieres navegar a una página diferente. Y también el ID de la página de este enlace, de la página que el usuario eligió. Así que por ejemplo, en este ejemplo, simplemente otra página en nuestra aplicación, en nuestro sitio web. Así que estos son los data guardados de este panel.

Y luego por supuesto, los data guardados necesitan ser pasados al componente de botón para crear el enlace en sí. Así que cuando el usuario haga clic, haremos la navegación. Así que de nuevo, quiero mostrarles cómo se vería un simple componente de React implementando esta lógica exacta. Así que un componente de React muy simple tomando las props. Por supuesto las props incluyen los data que acabamos de ver. Puedes ver el objeto link. Puedes ver la función calculate link en este código. Nos adentraremos en ella en un segundo. Pero puedes ver, devuelve un href, y luego tomamos el href y lo ponemos en la etiqueta anchor. Así que cada vez que el usuario haga clic en el botón, se realizará la navegación. Puedes ver que hay otro caso en caso de que el usuario no añada un enlace porque no tienes que añadir un enlace. No todos los botones tienen enlaces. Simplemente renderizamos un HTML diferente y usamos un botón, y tal vez en casos más complicados añadiremos una función onClick. Es muy importante diferenciar entre esas etiquetas. Para SEO es muy importante si tienes un href poner una etiqueta de anclaje, y si tienes un botón regular, no añadirlo. Es muy importante por razones de SEO. Este es un simple componente de React que implementa la característica que acabamos de presentar. Esta es solo una arquitectura general de nuestra solución desde el panel.

4. Analizando Problemas de Código y JavaScript No Utilizado

Short description:

Guardamos los datos en nuestros servidores y los enviamos al lado del cliente para crear el HTML para el sitio web. La función calculate link tiene muchas opciones del panel, lo que resulta en una gran cantidad de código no utilizado. Este es el primer problema: muchas opciones hacen que los componentes descarguen código no utilizado. El segundo problema es resolver el código que toma los datos guardados y crea el HTML.

Guardamos los data en nuestros servidores, y luego cuando el usuario va al sitio web enviamos al lado del cliente, y por supuesto acabamos de ver el JavaScript del componente React que se envían al lado del cliente para crear el HTML que luego, por supuesto, mostramos el sitio web con.

Entonces, es una característica muy simple, pero hablemos un poco sobre algunos problemas que vemos con este código. El problema más grande está realmente en la función calculate link. Ahora vamos a profundizar en esta función, la función calculate link.

Así es como se ve la función calculate link. Obtiene algunos parámetros, pero luego puedes ver todos esos casos que, recuerda, vimos desde el panel. Firmamos el panel, esos casos, y ahora podemos ver todos esos casos en nuestro código. Entonces, si es un enlace de página, necesito calcular el enlace a la página. Podría ser un enlace externo. Probablemente también lo tenga en los data. Podría ser cualquier otro caso. Si quiero abrir un popup, probablemente necesitaré más información aquí. Entonces puedes ver que esta función tiene muchas, muchas opciones del panel. Entonces, repasemos los problemas que vemos aquí.

Probablemente puedes empezar a imaginar los problemas que tenemos aquí. Damos a nuestros usuarios muchas opciones para configurar los componentes, ¿verdad? Por supuesto, los componentes pueden hacer muchas cosas, especialmente los botones y especialmente las opciones de enlace. Entonces les damos muchas opciones y luego escribimos código para implementar esas opciones. Pero dado que el usuario solo puede elegir una opción, escribimos mucho código que en realidad no se utiliza en muchos casos, porque dado que el usuario solo puede usar una opción, la mayoría de los otros casos no se utilizan, por lo que este es mucho código JavaScript no utilizado que descargamos al cliente. Y por supuesto también, lo vimos también dentro de la función calculate link, pero también podemos verlo en el componente de botón. Porque también este código puede, solo hay un componente que, solo un HTML que podemos enviar. Entonces, pero también necesitamos implementar en el componente de botón, dos opciones en este caso, y probablemente más opciones, por lo que más código no utilizado. Entonces este es el primer problema. Muchas opciones hacen que los componentes descarguen mucho código no utilizado. Pero en realidad hay otro problema. Y en realidad es más difícil de ver en este ejemplo porque es un ejemplo muy pequeño. Puedes verlo aquí. Resolviendo el código que tomó los data guardados y en realidad creó el HTML. Y miremos el código, lo siento. Estoy hablando de este código. El código que realmente obtiene los data de nuestra estructura, de nuestros data guardados, y crea HTML.

5. Calculando HTML desde Datos Guardados

Short description:

En nuestro caso, la función calculate link se utiliza para mapear el ID a la URL de la página. Guardar los datos tal cual crearía desafíos para entender el tipo de navegación elegido por el usuario. Para evitar el envío de JavaScript innecesario, necesitamos una solución al problema de calcular HTML a partir de datos guardados. Este problema no es específico de nuestro caso, sino que es común en muchas aplicaciones. Para abordarlo, reescribimos los componentes en pequeños componentes específicos de la característica y calculamos los datos de la vista en un servidor frontend separado. Esto elimina la necesidad de descargar código no utilizado y mejora el rendimiento.

En nuestro caso, es básicamente esta función calculate link. Ahora en nuestro caso, ejemplo simple, es solo una línea de código. Pero en casos más complejos, es en realidad más código que realmente tenemos que ejecutar. Tenemos que ejecutar este código. Así que incluso lleva más tiempo.

En este ejemplo, simplemente toma el objeto de la página y mapea el ID para obtener la URL de la página. Entonces probablemente estás pensando, ¿por qué necesito calcular estos data en lugar de guardarlos? Supongo que una solución aún más simple sería simplemente guardar los data como quieres verlos en lugar de calcular todas estas transformaciones en el lado del cliente. Entonces digamos que puedo guardar los data con el age ref en lugar de guardar lo que el usuario eligió aquí. Pero entonces si lo hago, si guardo el age ref, por ejemplo, esta URL que tengo aquí, realmente moveré el problema al lado del editor donde configuro el botón, porque entonces necesito tratar de averiguar qué sucede, ¿cómo transformo una URL a este panel? Básicamente va a ser muy difícil entender qué tipo de navegación eligió el usuario basándose en esta URL. Así que no quiero guardarlo para calcularlo cuando el usuario crea este panel, pero entonces si quiero calcularlo en el lado del cliente, necesito enviar todo este JavaScript.

Entonces, ¿qué hacemos? Antes de saltar a la solución, quiero hablar un poco sobre si es un problema específico de la semana. Y no lo creo. Creo que este problema de guardar data y luego enviarlo al lado del cliente y calcular el HTML a partir de los data guardados también es muy pesado en muchas aplicaciones. Normalmente no pensamos realmente cuando guardamos data, cómo vamos a presentarlo. Por ejemplo, como página de producto, no pensamos realmente, vale, cómo voy a mostrar esto página de producto. Normalmente pienso en lo que tiene este producto, pero cómo lo muestro, en muchos casos es completamente diferente, entonces necesito descargar JavaScript y descargar los data, tratando de calcular cómo quiero crear HTML. Además, tener muchas opciones para los componentes tampoco es un problema específico de Wix. Desarrollamos muchos, digo desarrolladores frontend, en React generalmente, creamos componentes complejos con muchas opciones que requieren mucho JavaScript, y a veces, solo usamos algunos de ellos en nuestro código. Entonces, de nuevo, mucho JavaScript que en realidad no se utiliza. Así que creo que cualquier aplicación web puede tener este problema, y estoy seguro de que muchas aplicaciones con problemas de performance tienen este problema.

Entonces, hablemos de la solución. Entonces, ¿cómo resolvemos no descargar mucho código no utilizado? En realidad reescribimos nuestros componentes en pequeños componentes específicos de la característica. Entonces, en lugar de tener este gran componente de botón que también podría tener un botón de enlace pero también botón regular en diferentes casos, botones de dirección web y muchos botones diferentes, ya sabes, simplemente tratando de implementar lo que el usuario quería, en realidad cortamos esos componentes en pequeños componentes específicos de la característica. Entonces, en lugar de tener este gran componente de botón, lo reescribimos en pequeños componentes específicos de la característica. Este es el primer paso, pero puedes ver que el href ya pasó de las props aquí, entonces ¿cómo calculamos el href? En realidad pasó, el href ahora se pasa desde el servidor. Entonces el segundo paso de la solución es calcular los data de la vista, que en nuestro caso es el href, lo calculamos en un servidor, pero no en el mismo servidor de donde provienen los data guardados. En realidad creamos un servidor frontend, que es algo entre el servidor backend y nuestra aplicación cliente. Así que toda esta función se ha movido completamente al backend, a nuestro servidor frontend, porque no tiene nada que ver con el navegador. Todos los data que utiliza esta función básicamente toman data guardados y calculan la vista data. Entonces, y por supuesto en este caso tenemos la URL basada en XML y por supuesto podemos enviarla a este servidor frontend.

6. Mejorando el Rendimiento a través de la Lógica del Servidor

Short description:

El cambio de arquitectura implicó mover los datos guardados y la función calculate delete al lado del servidor, lo que resultó en una mejora del rendimiento. Al calcular los datos de la vista en el servidor frontend y enviar solo los datos necesarios, la aplicación cliente se volvió más pequeña y rápida. Este cambio también permitió el almacenamiento en caché en la CDN, mejorando aún más el rendimiento. Este enfoque se puede aplicar a muchas aplicaciones comprendiendo los datos enviados al lado del cliente y moviendo el código apropiado al lado del servidor. Las conclusiones clave son reducir la descarga de JavaScript, usar componentes específicos de la característica y almacenar en caché las respuestas del servidor.

Entonces, echemos un vistazo a la architecture. Si antes, antes de la solución, los datos guardados se enviaban al cliente junto con el JavaScript, ahora tenemos algo en medio que llamamos servidores frontend, básicamente es solo un servidor Node.js que está como en medio del servidor backend y una aplicación cliente. Y la mayoría del JavaScript ahora se pasa al servidor frontend. No tienes que descargarlo, simplemente se guarda allí. Y calculamos todos los datos de la vista dentro de este servidor, y luego enviamos solo los datos de la vista. Y cuando decimos datos de la vista, ahora mapearlo a HTML, calcular el HTML a partir de los datos de la vista es muy fácil. Necesitas muy poco JavaScript también para descargar y también para ejecutar. La aplicación cliente se vuelve mucho, mucho más pequeña, pero también, por supuesto, más rápida. Y también puedes ahora, si calculas los datos de la vista en el servidor frontend, puedes añadir caché en CDN, y entonces también no ejecutas este código JavaScript en muchos de los casos. Todo es desde la caché de CDN. Lo ejecutas una vez, lo calculas una vez, pero luego lo guardas en la CDN. Así que la próxima vez es aún más rápido. Así que ahora obtener estos datos es ahora rápido. Parece un cambio pequeño, pero en realidad fue un gran cambio tomar los datos guardados, tomar la función calculate delete, moverla al lado del servidor que crea solo los datos de la vista. Y puedes ver que solo los datos de la vista se mueven a los pequeños componentes de react que escribimos que solo crean el HTML. Un pequeño ejemplo de una característica en un componente, pero en realidad tenemos muchos componentes y muchas características. Y tuvimos este problema en casi todos los componentes y todas las características. Así que tuvimos que hacer una gran refactorización para implementar la solución en toda nuestra aplicación. Eso es lo que nos hizo tener esta mejora masiva. Lo hicimos en todas nuestras aplicaciones, en todas nuestras características, rediseñamos completamente nuestra aplicación, y movimos mucho código al servidor, lo almacenamos en caché, y ahora una aplicación cliente es muy, muy pequeña, solo recibe los datos de la vista, los transforma a HTML. Y eso es todo en el lado del cliente. ¿Puedes hacerlo en cualquier aplicación? Por supuesto, creo que tiene sentido hacerlo. Creo que tiene sentido hacerlo en muchas aplicaciones. Solo necesitas entender cuáles son tus datos que estás enviando al lado del cliente. Y luego necesitas entender qué código puedes mover realmente al lado del servidor para calcular los datos guardados en datos de la vista. Luego envías, luego tus componentes solo recibirán datos de la vista, que son muy similares a los HTML, por lo que no necesitarás ningún cálculo para mapear estos datos a HTML.

Para resumir, esto es, como dije al principio, hicimos muchas cosas para mejorar el rendimiento, y por supuesto no fue lo único, pero creo que este proyecto fue la principal razón por la que mejoramos tanto en los últimos años. Gradualmente movimos más y más componentes y características a esta architecture, y con eso mejoramos los revivals de código, y por supuesto en la user experience. Así que las conclusiones de hoy son que creo que la mejor manera de mejorar el tiempo de carga es disminuir la cantidad de descarga de JavaScript al lado del cliente. Puedes hacerlo moviendo la lógica del lado del cliente al lado del servidor, como hemos hablado. Puedes escribir componentes específicos de la característica, por lo que solo estás descargando los componentes que realmente necesitas, y no grandes componentes con muchas opciones, y por supuesto almacenando en caché las respuestas del servidor, ahora eso incluye los datos de Vue y la CDN, en realidad creará tu aplicación de una manera que es muy, muy rápida. Muchas gracias. Si tienes alguna pregunta, por supuesto, estoy aquí y puedes preguntarme.

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.