¿Por qué es tan difícil construir un juego multijugador y qué podemos hacer para solucionarlo para todos?

Rate this content
Bookmark
Hacer juegos casuales se ha vuelto más fácil que nunca, pero configurar el modo multijugador todavía requiere que escribas código de red, manejes websockets, equilibres la carga de servidores, coloques servidores y demás.
Estoy construyendo Playroom para resolver esto, una sincronización de alto rendimiento que maneja la conexión en red y la gestión de las salas para que puedas concentrarte en construir tu juego.
18 min
28 Sep, 2023

Video Summary and Transcription

Asad Nehman analiza los desafíos de crear juegos multijugador y sugiere formas de simplificar el proceso. Destaca la necesidad de un backend, como un servidor Node.js con Socket.io, para manejar las conexiones de los jugadores. Se introducen las salas para conectar a los jugadores y sus amigos, permitiendo la comunicación dentro de cada sala. Opciones de alojamiento como AWS EC2, Vercel y Netlify pueden ayudar a escalar el juego a nivel global. El marco de Playroom elimina la necesidad de código de servidor, sistemas de lobby y gestión de perfiles de jugadores.

Available in English

1. Introducción a la Creación de Juegos Multijugador

Short description:

Asad Nehman habla sobre los desafíos de crear juegos multijugador y sugiere formas de simplificar el proceso. Destaca la necesidad de un backend, como un servidor Node.js con Socket.io, para manejar las conexiones de los jugadores. Se introducen las salas para conectar a los jugadores y sus amigos, permitiendo la comunicación dentro de cada sala. Los códigos de sala se utilizan como identificadores de canal únicos para la comunicación, incluyendo el estado y la posición del jugador. Se necesita una interfaz de lobby para compartir los códigos de sala, permitiendo que los jugadores se unan a la misma sala. Las opciones de personalización, como avatares y colores, ayudan a diferenciar entre los jugadores.

Hola a todos, soy Asad Nehman. Voy a hablar sobre por qué es tan difícil crear juegos multijugador y qué podemos hacer para facilitarlo. Un poco de lo que quiero decir. Soy un desarrollador. Hago cosas. Específicamente, me gusta crear herramientas para desarrolladores y lo he estado haciendo durante más de 10 años. También fundé una empresa de IDE en línea en el pasado. También me gusta jugar juegos multijugador con mis amigos. Así que naturalmente me gusta hacer juegos multijugador. Digamos que quiero hacer un juego multijugador. Comencemos con el juego multijugador más simple y veamos qué desafíos enfrentamos. Lo primero que probablemente quieras hacer es obtener un juego de un solo jugador base, que luego convertirás en un juego multijugador. Este juego base probablemente tendrá un bucle de juego con él, y las partes multijugador pueden ser agregar más jugadores y alguna lógica al respecto, algunas competiciones y cosas así. Y lo primero que probablemente harías para convertir esto en un juego multijugador es agregar un backend a él. Y en el contexto de los juegos web, esto suele ser un servidor Node.js con algún tipo de framework de web socket como Socket.io. Entonces, probablemente quieras manejar las conexiones de los jugadores y almacenar esos jugadores en una matriz global dentro de tu aplicación Node.js, y de esta manera todos los jugadores pueden conectarse entre sí utilizando este backend de web socket, y esto funciona. Pero pronto te das cuenta de que también necesitas tener algún concepto de Salas en tu juego, en tu servidor. Entonces, lo que harían las Salas es asignar algún código de sala a algunos jugadores y lo que esto te permite hacer es conectar a cada jugador y a sus amigos entre sí. Entonces, todos los jugadores en todos tus juegos no están en la misma sala. Están en sus propias salas y las salas pueden comenzar y terminar en sus propios tiempos dependiendo de cuándo comiencen sus juegos. Así que suena como que estos dos jugadores están en sus propias salas y estos dos jugadores están en sus propias salas y solo pueden comunicarse dentro de sus propias salas. No pueden comunicarse con los jugadores de otras salas. Bastante simple. Y sí. Pueden usar este código de sala como un identificador de canal único a través del cual pueden comunicarse entre sí. La comunicación puede ser el estado del jugador y la posición del jugador, puntuaciones, todas esas cosas. Ahora, necesitas... Una vez que introduces los códigos de sala, necesitas una forma de compartir estos códigos de sala con otros jugadores. Esto puede ser algún tipo de interfaz de lobby que necesitas crear. La interfaz de lobby puede ser que el anfitrión inicie el juego, comparta el código de sala, enlace de sala, código QR con otros jugadores, y ese código QR o enlace de sala tendrá el ID de la sala incrustado en él, y cuando el otro jugador abra esta URL, se conectará automáticamente a la misma sala, y de esta manera pueden comunicarse entre sí. También necesitas alguna forma, alguna interfaz de usuario para permitir a los jugadores elegir sus avatares, sus colores, sus nombres, para tener alguna personalización, y para que puedan diferenciarse

2. Transmitiendo el Estado del Juego y Desplegando Servidores

Short description:

Una vez que tienes la transmisión y sincronización del estado del juego en su lugar, necesitas desplegar tu juego. Opciones de alojamiento como AWS EC2, Vercel y Netlify pueden ayudarte a escalar tu juego a nivel global. Sin embargo, surge un desafío cuando tus servidores están aislados y los jugadores conectados a diferentes servidores no pueden interactuar. Para resolver esto, necesitas conectar los servidores a una base de datos central como Redis y desplegarlos en todo el mundo para una baja latencia.

entre los jugadores. Sí, y una vez que tienes eso, creas tu juego. Tu juego es esencialmente, transmites el estado del juego a los jugadores, y los jugadores transmiten su propio estado a los demás jugadores, y tu trabajo como creador de juegos es combinar esos estados, actualizaciones, y consumirlos, guardarlos localmente. Por ejemplo, un jugador puede moverse y compartir la posición al servidor WebSocket, y los otros jugadores pueden leer esa posición y actualizar al jugador en su propia pantalla, y viceversa. Entonces, básicamente lo que estás haciendo es mantener estas variables globales propias, que deseas sincronizar entre todos los jugadores. Y la mayor parte del código de red involucrado sería asegurarse de que estos estados estén sincronizados. Una vez que tienes eso, tienes un juego simple. Ahora, no puedes simplemente compartir este juego sin desplegarlo en algún lugar. Para desplegarlo, necesitas algún lugar para alojar este juego. Esto puede ser una instancia de AWS EC2, lo cual recomendaría. Puedes usar algún servicio como Vercel, Netlify, y lo que pueden hacer es alojar tu juego, escalar tu juego a nivel global, tener múltiples instancias ejecutándose de tu juego basado en el tráfico que llega a tu juego y una vez que eso sucede, te das cuenta del problema principal aquí.

3. Conexión de Servidores y Uso de Soluciones Alternativas

Short description:

Tus servidores están aislados, pero puedes conectarlos a una base de datos central como Redis para sincronizar los estados de las salas y las listas de jugadores. Desplegar servidores y réplicas de bases de datos en todo el mundo garantiza una baja latencia para los jugadores. En lugar de gestionar clústeres y bases de datos, considera utilizar soluciones alternativas como Photon o netcode de Unity, o servicios de alojamiento de servidores de juegos como Hathora, Revit y Snapser. Firebase también se puede utilizar como backend para juegos simples y no arcade. Además, es necesario implementar conexiones punto a punto.

El problema es que tus servidores están aislados. Supongamos que estoy conectado al servidor A aquí y uso algún código de sala para conectarme al servidor y comparto ese código de sala con mi otro amigo que está conectado al servidor B. Y ellos intentan usar el mismo código de sala pero no me ven. Eso se debe a que el servidor A y B no están interconectados entre sí. Por lo tanto, el estado que mantienen, bueno, los estados de las salas, la lista de salas que mantienen, no es la misma porque se ejecutan en un proceso completamente separado en todo el mundo. Y para resolver esto, lo que necesitas es básicamente conectarlos a una base de datos central, tal vez. Supongamos que los conectas a una base de datos. Redis es una buena opción para hacer esto. Entonces, Redis puede actuar como el backend del backend, que luego almacena todas las salas, los estados y las listas de jugadores y todo. Y todos estos servidores simplemente se sincronizan con esa base de datos central, Redis en este caso. Pero también necesitas desplegar este par de servidor y base de datos en todo el mundo porque tus usuarios pueden conectarse desde lejos y no deberían experimentar retraso en su juego. Entonces, lo que quieres es desplegar servidores cerca de ellos y también quieres desplegar la réplica de la base de datos cerca de ellos. Así que no ven retraso. Comienzas desarrollando un juego, pero ahora estás gestionando tu clúster y bases de datos. Eso no es lo que quieres hacer. Y cada desarrollador de juegos se enfrenta a una versión de esto al hacer juegos multijugador. Eso es mucho trabajo duplicado. No quieren gestionar todos estos servidores. Solo quieren hacer el juego. Afortunadamente, hay algunas alternativas mejores que simplemente escribir tu propio servidor. Por ejemplo, Unity tiene Photon o netcode para objetos de juego. Hay servicios como Hathora, Revit, Snapser que alojan un servidor de juegos para ti. Entonces, solo les das el código del servidor y ellos lo alojan por ti. También puedes usar Firebase como backend para juegos. Esto puede ser útil para juegos simples, juegos no arcade y juegos de fiesta. Estas opciones son geniales. Al menos son mejores que lo que hablamos antes. Pero aún así, tienes que escribir un montón de código no relacionado con el juego y código de servidor backend. También debemos hablar sobre otro código no relacionado con el juego que probablemente necesitarás hacer. Que es averiguar las conexiones punto a punto.

4. Simplificando la Configuración del Juego con Playroom

Short description:

La mensajería directa de jugador a jugador reduce la latencia en juegos de ritmo rápido. La predicción del lado del cliente garantiza un movimiento fluido del jugador durante las actualizaciones. Los estudios de juegos gastan tiempo y dinero excesivos en código no relacionado con el juego. El marco de Playroom elimina la necesidad de código de servidor, sistemas de lobby y gestión de perfiles de jugadores. Proporciona una variable global para sincronizar el estado de la sala entre todos los jugadores. Playroom simplifica la configuración del juego, incluyendo las conexiones del lobby y las invitaciones de los jugadores. La lógica del juego maneja automáticamente la entrada y salida de jugadores y las actualizaciones del estado del juego.

Las conexiones punto a punto. Por lo tanto, los mensajes no se envían a un servidor, en su lugar se envían directamente al otro jugador, lo que reduce la latencia para ti. Esto es absolutamente necesario para juegos de ritmo rápido. Probablemente también quieras agregar soporte para Gamepad para que los jugadores puedan jugar localmente, en pantalla dividida o en la televisión. También querrás hacer algún tipo de predicción del lado del cliente para los movimientos de los jugadores. Porque mientras se envía esta actualización, por ejemplo, para una posición a ese jugador, ese jugador no debería quedarse atascado en el espacio. Debería ver alguna forma de predicción sucediendo. Entonces, el jugador se mueve suavemente al siguiente paso. Entonces, hablamos con algunos estudios de juegos sobre su opinión sobre lo que proporciona la infraestructura actual y cómo se sienten al respecto. Y vimos un patrón común de que están gastando mucho tiempo y dinero en hacer estos juegos multijugador. Y sí, no debería ser así. Debería ser así. Entonces, repensemos cómo sería si no tuvieras que lidiar con ningún código no relacionado con el juego en tus juegos. Eso significaría simplemente no escribir ningún código de servidor en absoluto. Y sí, tampoco quieres escribir tu propio sistema de lobby y interfaces de usuario y gestionar perfiles de jugadores y todas esas cosas. ¿Qué tal si solo llamas a una función y te da la lista de jugadores en esta sala actual y simplemente comienza un juego con esa lista de jugadores? Y no tienes que preocuparte por todas las conexiones del lobby, los códigos QR, el estado de la sala, qué estado de la sala quieres sincronizar. Es solo una variable global a la que puedes establecer y obtener y se sincronizará automáticamente entre todos los jugadores en esta sala, por lo que no tienes que preocuparte por cómo obtener este estado del dispositivo A al dispositivo B. Por ejemplo, establezco el estado PUNTUACIÓN3 en el dispositivo A en el jugador A, y luego puedo intentar obtener la puntuación en otro dispositivo y obtener el estado actualizado aquí. Esa es la premisa detrás del marco llamado Playroom en el que estoy trabajando. Sí, veamos cómo funciona. Entonces, primero que nada, para usar Playroom lo que quieres hacer es instalar playroom-get y después de hacer eso llamas a esta función init() que llamamos insertCoin. Esto le dice a Playroom que comience, esto le dice a Playroom que inicie el sistema de lobby para que muestre la interfaz de lobby y desde allí maneja automáticamente toda la creación, unión, perfiles de jugadores y que los jugadores elijan sus propios colores y avatares y todas esas cosas. ¿Cómo? Veamos. Entonces, cuando llamas a insertCoin, el jugador ve esta interfaz de pantalla completa que llamamos la interfaz de lobby y los jugadores pueden, como dije, elegir sus avatares y colores y todo y también pueden invitar a otros jugadores para que puedan compartir el enlace a tu juego con esa URL única o simplemente el otro jugador puede escanear este código QR para unirse a la misma sala. Y el siguiente paso que quieres hacer es escribir una lógica de juego para que los jugadores se unan al juego y abandonen el juego. Entonces, por ejemplo, cuando un jugador se une al juego probablemente quieras agregar algún sprite para ellos en la escena y cuando se van quieres eliminar ese sprite de la escena. Y eso es unirse y abandonar el juego. La otra cosa que quieres manejar es el estado del juego en sí. Entonces, digamos que quieres tomar alguna entrada, hacer algún cálculo y actualizar la posición del jugador y una vez que hagas eso, los otros jugadores verán automáticamente esa nueva posición y actualizarán la posición del jugador.

5. Playroom Backend y Ciclo de Vida de Roles

Short description:

Puedes configurar y obtener fácilmente posiciones, entrada de jugadores, salud, puntuación, ganador y clasificaciones utilizando las funciones de Playroom sin escribir ningún código de servidor. Playroom se basa en Cloud Play y DurableObjects para su backend, proporcionando almacenamiento de baja latencia en todo el mundo. El ciclo de vida de un rol implica crear una nueva sala para el primer jugador, conectar a otros jugadores a través de una URL única y gestionar el estado del juego. Playroom mantiene dos tipos de conexiones: un socket TCP confiable a través de los servidores de Playroom y una conexión UDP o WebRTC no confiable entre los jugadores. Este último es adecuado para estados como las posiciones de los jugadores.

En tu pantalla. Y esto sucede automáticamente. Solo tienes que configurar y obtener posiciones de las funciones de Playroom y esto es válido para las posiciones de los jugadores, la entrada, la salud, la puntuación, quién es el ganador, las clasificaciones y todas esas cosas. Y nuevamente, nunca escribiste ningún código de servidor para esto, solo instalas esto con npm e inicias en Playroom y luego estás configurando y obteniendo el estado. Eso es todo. Entonces, ¿cómo funciona esto detrás de escena? Supongo que el mayor secreto aquí es Cloud Play y DurableObjects. Cloud Play tiene nodos adicionales en todo el mundo y probablemente también tenga nodos adicionales dentro de tu ISP. Por lo general, estos están a unos 50 ms de distancia en términos de latencia. Y la otra cosa es DurableObjects, que es como un sistema de almacenamiento que Cloud Play proporciona y que te permite tener un almacenamiento consistente y de baja latencia en cualquier parte del mundo. Sí, eso es como el backend de Playroom.

Y repasemos el ciclo de vida de un rol. Cuando el primer jugador inicia un juego y el juego llama a insertCoin, lo que hace Playroom es mostrar la interfaz de CRM para el lobby y el perfil y todo. Y detrás de escena, Playroom crea una nueva sala para ellos y se conectan a esta sala. Y cuando comparten esta URL única con otros jugadores, ellos también se unen a la misma sala. Y luego, cuando el anfitrión hace clic en iniciar, simplemente se guarda la sala. Y Playroom gestiona el estado.

Y eso no es todo lo que hace Playroom. Playroom también proporciona una conexión secundaria para ti. Entonces, Playroom mantiene dos tipos de conexiones para ti. Uno es el socket TCP del que hablamos, que es confiable y pasa por los servidores de Playroom. Y tienen una latencia de 80 a 150 ms. El otro tipo de conexión es la conexión UDP o WebRTC que Playroom mantiene entre los jugadores. Entonces, en estas conexiones no se involucra ningún servidor de Playroom. Y estas utilizan WebRTC y son inherentemente no confiables. Eso significa que tu estado puede que no siempre llegue al otro extremo. Pero para algunos tipos de estados, esto está bien. Por ejemplo, para las posiciones de los jugadores, esto está bien porque probablemente estarás enviando la posición del jugador nuevamente en unos pocos milisegundos. Entonces, si te pierdes uno, no importa. Simplemente...

6. Sending Player Positions and Playroom Benefits

Short description:

Playroom te permite elegir el tipo de estado que enviar a través de diferentes conexiones, como websockets o WebRTC. Los comentarios de los desarrolladores de juegos que han utilizado Playroom han sido positivos. Su enfoque se centra en proporcionar un SDK sencillo que permite a los desarrolladores de juegos centrarse únicamente en el código relacionado con el juego. Para obtener más información sobre Playroom, visita Playroom.com o sigue al orador en Twitter.

Si intentas enviar las posiciones de los jugadores utilizando websockets, lo que sucederá es que habrá un efecto de enlace de números allí arriba. Donde recibirán un montón de posiciones y los jugadores se quedarán atascados y avanzarán rápidamente. Y eso no es lo que quieres. Pero Playroom te permite decidir qué tipo de estado quieres enviar a través de qué tipo de conexión. Y para cada estado establecido, puedes decidir si quieres enviarlo a través de websockets o WebRTC. De lo contrario, Playroom decidirá por sí mismo en función de la calidad de la conexión y todas esas cosas. Compartimos Playroom con un grupo de desarrolladores de juegos y los comentarios iniciales han sido excelentes. Supongo que el enfoque de Playroom es hacer el SDK de múltiples capas más simple posible y el enfoque es que los desarrolladores de juegos no escriban ningún código que no esté relacionado con el juego. Y sí, los comentarios han sido buenos. Eso es todo de mi parte. Muchas gracias. Puedes obtener más información sobre Playroom y unirte a Playroom.com. También puedes seguirme en Twitter o escanear este código QR para seguirme en Twitter. Muchas gracias.

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
Top Content
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
Top Content
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.
JS GameDev Summit 2022JS GameDev Summit 2022
33 min
Building Fun Experiments with WebXR & Babylon.js
Top Content
During this session, we’ll see a couple of demos of what you can do using WebXR, with Babylon.js. From VR audio experiments, to casual gaming in VR on an arcade machine up to more serious usage to create new ways of collaboration using either AR or VR, you should have a pretty good understanding of what you can do today.
Check the article as well to see the full content including code samples: article. 

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
116 min
Make a Game With PlayCanvas in 2 Hours
Featured WorkshopFree
In this workshop, we’ll build a game using the PlayCanvas WebGL engine from start to finish. From development to publishing, we’ll cover the most crucial features such as scripting, UI creation and much more.
Table of the content:- Introduction- Intro to PlayCanvas- What we will be building- Adding a character model and animation- Making the character move with scripts- 'Fake' running- Adding obstacles- Detecting collisions- Adding a score counter- Game over and restarting- Wrap up!- Questions
Workshop levelFamiliarity with game engines and game development aspects is recommended, but not required.
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
Top Content
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
JS GameDev Summit 2022JS GameDev Summit 2022
121 min
PlayCanvas End-to-End : the quick version
Top Content
WorkshopFree
In this workshop, we’ll build a complete game using the PlayCanvas engine while learning the best practices for project management. From development to publishing, we’ll cover the most crucial features such as asset management, scripting, audio, debugging, and much more.
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 🤐)