Medir y Mejorar el Rendimiento del Frontend Utilizando la Automatización de Pruebas

Rate this content
Bookmark

Las pruebas de rendimiento automatizadas pueden ayudar a detectar los efectos perjudiciales de los cambios de código en el rendimiento de la aplicación. Aprenda a utilizar herramientas como Lighthouse y Web Core Vitals en su CI y establezca umbrales de rendimiento para mantener un rendimiento óptimo del frontend en esta sesión.

22 min
11 Dec, 2023

AI Generated Video Summary

La charla se centra en la importancia de las pruebas y la recopilación de información para la construcción de buenas aplicaciones. Destaca el uso de la automatización de pruebas para el monitoreo del rendimiento y el registro para la medición del rendimiento. La charla también discute el impacto del rendimiento en la participación del usuario y en las clasificaciones de los motores de búsqueda. Enfatiza el uso de los plugins de Cypress para monitorear las métricas de rendimiento y establecer umbrales para las pruebas. En general, la charla enfatiza el valor de las herramientas de automatización de pruebas al proporcionar información valiosa a un bajo costo.

1. Introducción a las Pruebas e Información

Short description:

Hola a todos en TestJS Summit esta vez. Estoy muy contento de estar aquí de nuevo. Hoy, vuelvo a casa con un descubrimiento interesante sobre el rendimiento. Me apasionan las pruebas y creo que la información es rey. Recopilar información es importante para construir buenas aplicaciones. Hazlo funcionar, hazlo bien, hazlo rápido: el orden de construir buenas aplicaciones.

Hola a todos en TestJS Summit esta vez. Estoy muy contento de estar aquí de nuevo porque la cumbre TestJS fue una de las primeras conferencias en las que tuve el honor de ser orador. Es como volver a casa hoy.

Hoy, en realidad, vuelvo aquí con un pequeño descubrimiento interesante que quiero mostrar cuando se trata de mi experiencia en testing. Si ya lo habías adivinado, es sobre performance. Bueno, antes de eso, rápido, mi nombre es Ramona. Trabajo como Developer Advocate en Offs Zero. Aparte de eso, soy Google Developer Expert en tecnología web y embajador de Cypress. Como habrás adivinado, creo que, sí, al menos me apasiona cuando se trata de testing. Sí, no debería ser una sorpresa que esté aquí para hablar de testing hoy.

Entonces, especialmente cuando se trata de testing, hay algunas cosas que son realmente importantes. Y sí, esta pequeña cosa, el contenido es rey, que espero tener suficiente para estos 20 minutos. Fue hecho por Steve Bommer, creo. Hace muchas citas que son memorables. Pero bueno, cambiemos un poco esta cita. Porque, si el contenido es rey, la información es rey, como el doble o incluso más. Y no es solo porque me gusta jugar videojuegos y este es el título de una misión de World of Warcraft. Pero yo, bueno, lo encuentro interesante. Al menos me gustan esas pequeñas misiones secundarias donde, por ejemplo en este caso, un vendedor goblin llamado Goodskitch quiere tener un poco de piel de Krukal a cambio de información. Entonces, no solo en videojuegos la información es realmente importante. Recopilar información, tener una buena idea de lo que sucede dentro de tu aplicación, es realmente importante. No solo en los juegos, sino también cuando se trata de testing.

Entonces, bueno, supongo que esto debería estar claro la mayor parte del tiempo. Pero, ¿por qué necesitamos tener información sobre nuestra aplicación? Porque queremos construir buenas aplicaciones, ¿verdad? Entonces, podrías haber tropezado con esta cita de Comeback, que dice, hazlo funcionar, hazlo bien, hazlo rápido, en ese orden particular. Entonces, solo para profundizar un poco, hacer que funcione es autoexplicativo. Intenta resolver un problema a mano, que podría construir una buena aplicación. Entonces, solo haz que funcione cuando se trata de tus requisitos. Si puedes hacer eso, haz la segunda cosa, hazlo mantenible, hazlo bien. Entonces, intenta tener en cuenta los requisitos no funcionales. Ten en cuenta el código limpio, por ejemplo, para hacerlo no solo funcionar, sino funcionar de la manera correcta y funcionar de la manera en que todavía quieres trabajar con tu aplicación, digamos, un año a partir de ahora.

2. Uso de la Automatización de Pruebas para el Monitoreo del Rendimiento

Short description:

Y por último, pero no menos importante, haz que funcione, hazlo rápido, haz que el usuario no se sienta molesto al usar tu aplicación. Podemos usar la automatización para apoyarnos en estos tres puntos, incluso en el rendimiento. La automatización de pruebas se puede utilizar para monitorear el rendimiento y recopilar información. El registro es el arte de mantener un registro o una lista de eventos que ocurren en tu sistema informático, como problemas, errores o simplemente información en las operaciones actuales.

Y por último, pero no menos importante, haz que funcione, hazlo rápido, haz que el usuario no se sienta molesto al usar tu aplicación. Y sí, por supuesto, el primer punto, hacer que funcione es bastante fácil de lograr con testing. Entonces, si pruebas tu aplicación, sabes que está funcionando como se esperaba. El segundo punto, hacerlo bien, puede ser apoyado por tooling, por ejemplo, si tuviéramos buenas pruebas, facilitaría la escritura de un buen código. Y no quiero empezar con todos los linches, todas las herramientas de análisis estático que puedes ejecutar, como phpStan, ESlearnStyle y lo que sea. Pero, bueno, tenemos un buen soporte cuando se trata de primero, hacer que funcione, hacerlo bien. Pero ¿qué pasa con el tercer punto, hacerlo rápido y hacerlo funcionar y básicamente hacer que se sienta impecable? Bueno, hacer que tu aplicación funcione parece realmente desalentador, porque como dije, no tienes tanto soporte de herramientas todavía. Y bueno, incluso el punto, los pasos para acelerar tu código de aplicación es realmente difícil, porque podrías preguntar, como, ¿quién tiene tiempo para eso, quién tiene el poder para hacer eso? Y puede ser por presión de los clientes, pero especialmente el espacio mental dentro de ti mismo. ¿Y tenemos tiempo para mejorar el performance o mantenerlo? Porque incluso obtener toda la información que necesitas sobre tu aplicación para monitorear el performance, hacer todas esas medidas localmente lleva mucho tiempo. Y todo esto junto parece realmente desalentador. Entonces, ¿qué pasaría si te dijera un punto interesante de que no necesitamos sentirnos perdidos? No necesitamos sentirnos tan agotados o asustados. ¿Qué pasaría si te dijera que podemos usar la automation para apoyarnos en todos esos tres puntos? Incluso el performance. No solo trabajar, no solo hacerlo bien, hacerlo funcionar. ¿Qué pasaría si te dijera que puedes usar la automatización de pruebas para eso? No solo intentar aprender GitHub Actions para implementar algunas herramientas que nos ayuden a monitorear el performance, sino usar todo lo que ya tenemos. La automatización de pruebas que ya tenemos para nuestro proyecto. Bueno, lo sé, lo sé, es un poco como mal usar el testing, ¿verdad? Entonces, bueno, todavía es bueno porque puedes usar tus conocimientos que ya tienes para ello. No necesitas aprender nuevas herramientas. Puedes usar tu CI bien conocido y familiar. Por ejemplo, si no quieres usar GitHub Actions, que puede dártelo, o si una acción de GitHub estandarizada no es suficiente para satisfacer tus necesidades. Entonces, en mi mente creo que es interesante usar las pruebas de extremo a extremo para medir el performance porque la pila de aplicaciones AppStack está completamente ahí, y existente. Entonces podemos hacer más de ello, que solo cuando se trata de pruebas unitarias. Y estamos cerca del usuario que se molestaría por los problemas de performance, ¿verdad? Pero, si queremos pensar en usar la automatización de pruebas para monitorear el performance y recopilar, monitorear y recolectar información sobre nuestro performance, retrocedamos un paso y veamos cómo medimos o recopilamos información sobre nuestra automatización de pruebas para empezar. Bueno, como esta charla se llama Medición, comencemos con los valores predeterminados para arrojar algo de luz sobre ello.

Muchos piensan en la forma más interesante o más normal de ver la información de tus pipelines de automatización de pruebas. Por ejemplo, si quieres ver por qué algo falla, mirarás los registros. El registro es en realidad el arte de mantener un registro o una lista de eventos que ocurren en tu sistema informático, como problemas, errores o simplemente información en las operaciones actuales. Podría ser testing, por ejemplo, en este sentido. Registra todo lo que sucede dentro de tus pruebas.

3. Uso de Registro para Medición del Rendimiento

Short description:

El registro de CRI es una parte vital para permitirte medir cosas. Necesitamos ser capaces de notar los problemas que tenemos y hacerlo rápido. Hay formas de apoyarte para tener un registro lo más fácil y accesible posible. Veamos cómo podemos usar el registro para medir los valores de rendimiento. El rendimiento en la automatización web depende de factores como el tiempo de carga de la página, la capacidad de respuesta y la experiencia general del usuario. Para lograr un sitio web de alto rendimiento, podemos optimizar reduciendo los tamaños de archivo y minimizando las solicitudes al servidor.

Se ve así. El registro de CRI es visible dentro de tu CRI. Incluso si la presentación difiere a veces, se maneja de manera similar en muchos frameworks, no importa si es Cypress, no importa si es PlayWrite. Entonces, puedes echar un vistazo a los resultados de las pruebas y, por supuesto, a los errores, si los hay. Y algunos frameworks te dan un poco más de información al respecto. Por ejemplo, aquí el test runner de Cypress y PlayWrite tiene uno similar. Pero todos esos frameworks dejan claro lo que sucede dentro de tu prueba. Bueno, podrías preguntarte ahora, ¿por qué te digo esto ahora? ¿Por qué debería importarme porque es una característica estándar, ¿verdad? Tienes razón. Pero hay algo que necesitas tener en mente, porque el registro es una parte vital para permitirte medir cosas. Y si no puedes medir algo, no puedes mejorarlo, ¿verdad? Porque no tienes un mensajero para decirte que algo está mal. Entonces, sí, necesitamos recordar la parte de hacerlo. Esto es crucial. Necesitamos ser capaces de notar los problemas que tenemos. Así especialmente el punto de hacerlo rápido es importante en nuestro caso. Así que dependemos de métricas. Así que necesitamos dejar que las métricas muestren como una base de comparación. Y antes de que te preocupes ahora, no necesitas siempre manejar esas salidas de registro desalentadoras.

Hay un par de formas de apoyarte para tener este registro lo más fácil y accesible posible. Por ejemplo, si quieres usar un reportero personalizado para mostrarlo un poco mejor, que podría ser más impresionante, pero hay muchos más en los que podrías echar un vistazo. Bueno, hay un montón de plugins que extienden la salida de registro dentro de tu CI. Tal vez el plugin de Cypress, en mi caso, donde agregaré el nombre más tarde porque yo aparentemente lo he olvidado. Así que podrías pensar en imprimir la salida de la consola DevTool o solicitar para hacerlo aún más fácil. Bueno, hasta ahora todo bien. Estos son los valores predeterminados de registro. Así que veamos cómo podemos usarlos en detalle para mal utilizar la automation de pruebas para medir los valores de performance. Y antes de hacer eso, por supuesto, esta charla es sobre performance, pero supongo que deberíamos tener un entendimiento común de lo que es performance en este sentido.

Así que performance en la automation web, primero la velocidad y eficiencia con la que un sitio web o aplicación web funciona y entrega contenido al usuario. Y puede depender de varios factores como el tiempo de carga de la página, la capacidad de respuesta y la experiencia general del usuario. Básicamente todo lo que podría hacerte sentir desencadenado o digamos que molesto o algo que no se siente como una experiencia de usuario impecable que no puedes hacer tu trabajo en. Y nuestro sueño de un sitio web de alto rendimiento es que se vea rápidamente, permite a los usuarios acceder a la información sin demoras o interrupciones. Así que es simplemente impecable, ¿verdad? Para llegar a ese punto, podemos hacer algunas optimizaciones que podrían implicar optimizar reduciendo los tamaños de archivo, minimizando el número de solicitudes hechas al servidor.

4. Pruebas y Monitoreo de Rendimiento

Short description:

Todas esas pequeñas cosas que se acumulan bastante rápido. Y sí, si no prestamos atención a esto, tendremos tasas de rebote más altas, menor compromiso del usuario y un impacto negativo en las clasificaciones de los motores de búsqueda. Entonces, cuando se trata de pruebas de rendimiento, hay un par de formas en las que podrías usar esto. Es el lado del cliente de front-end aquí, porque tenemos automatización de pruebas de front-end aquí utilizando Javascript. El monitoreo del rendimiento en el front-end tiene mucho sentido. La herramienta más común que todos usan para rastrear el rendimiento del front-end es Lighthouse. Podrías usar la Auditoría de Cypress para tareas de Cypress, también hay una Alternativa de Playwright. Todo entre 0 y 49 es malo y probablemente influirá en tu clasificación. Por nuestra parte, el rendimiento, hay algunas métricas interesantes nombradas aquí como la primera pintura con contenido y la pintura con contenido más grande que son realmente interesantes para nosotros. Las tres métricas principales de los vitales web son primero, la pintura de contenido más grande, el primer retraso de entrada, y el cambio de diseño acumulativo. Y hay un Plugin de Cypress 2, que podrías usar para monitorear los vitales web a través de nuestra automatización de pruebas.

Todas esas pequeñas cosas que se acumulan bastante rápido. Y sí, si no prestamos atención a esto, tendremos tasas de rebote más altas, menor compromiso del usuario y un impacto negativo en las clasificaciones de los motores de búsqueda. Entonces, cuando se trata de performance testing, que básicamente es el tipo de testing realizado para evaluar la velocidad, la capacidad de respuesta, estabilidad y scalability de una aplicación o sitio web, hay un par de formas en las que podrías usar esto. Entonces, cuando pienso en cosas como las pruebas de carga, donde tienes las cargas de usuarios normalmente esperadas para determinar su tiempo de respuesta, pero también las pruebas de estrés testing, pruebas de pico, cuando se trata de picos de carga sobre cómo manejarlo en tu aplicación, incluso pruebas de estrés, para intentar empujar tu sitio web más allá de su capacidad normal, hay dos aspectos de performance testing que podrías utilizar para obtener una imagen más grande de el comportamiento de tu aplicación. Podría ser un consejo de fondo, por supuesto, por lo que las herramientas más tradicionales, no cubro esas, a toda costa, pero quiero centrarme en otra cosa, es el lado del cliente de front-end aquí, porque tenemos automation de pruebas de front-end aquí utilizando Javascript, pero no solo eso, muchas personas no recuerdan que la mayor parte del tiempo de carga de una página web se gasta en el front-end, como dice Marie, espero que hayas echado un vistazo a su charla, porque es increíble, pero el monitoreo del performance en el front-end tiene mucho sentido, si la mayoría de las personas lo notarán en el front-end, y si piensas en, okay, ¿cómo puedo monitorear las auditorías de front-end, las métricas de front-end, supongo que compartimos un pensamiento similar, y básicamente el primer paso que damos cuando se trata de esos temas, bueno, es evaluar Lighthouse, por lo que Lighthouse es básicamente la herramienta más común que todos usan para rastrear el performance de front-end, y muchas personas lo usan porque es bastante fácil porque puedes acceder a él a través de Chrome DevTools.

Y supongo que cuando se trata de depurar localmente, muchos de ustedes chicos tal vez ya lo han probado, pero ¿sabías que podrías automatizar esto? Podrías usar una Acción de GitHub que supongo que incluso está predefinida, pero podrías usar tu prueba de extremo a extremo para seguir la pista de esas también. Hay un plugin que se llama Cypress Audit que proporciona auditorías de Lighthouse pero también auditorías de Pally, pero no quiero centrarme en accessibility ahora mismo porque supongo que es suficiente para el espacio aquí. Así que Lighthouse es. Así que podrías usar la Auditoría de Cypress para tareas de Cypress, también hay una Alternativa de Playwright, y allí echas un vistazo a los típicos umbrales de Lighthouse. Las categorías que usamos para Lighthouse y proporcionan la puntuación entre 0 y 100 en el ámbito del performance, que es importante para nosotros. Accessibility, best practices, SEO y PWA. Y cuando se trata de lo que es bueno y lo que no, podríamos centrarnos en la auditoría de performance aquí y vemos que todo entre 0 y 49 es malo y probablemente influirá en tu clasificación. Luego todo entre 50 y 89 es algo con algunas posibilidades de mejora y todo por encima de 19 es genial y puedes ver eso aquí mismo ahora. Y por nuestra parte, el performance, hay algunas métricas interesantes nombradas aquí como la primera pintura con contenido y la pintura con contenido más grande que son realmente interesantes para nosotros. Vamos a echar un vistazo más de cerca porque estos son los que queremos echar un vistazo más de cerca y queremos actuar sobre esos. Bueno, esos dos términos fueron tomados de los vitales web de Google que son un conjunto de métricas específicas que miden la user experience de un sitio web. Se centran en tres aspectos críticos del rendimiento web como la carga, como qué tan rápido es algo, la interactividad, qué tan rápido la aplicación reacciona a nuestra entrada y la estabilidad visual. Así que tal vez ya te ha pasado tener una página móvil. Estás desplazándote por ella, quieres hacer clic en algo, pero salta. Sí, esto es algo a lo que debemos prestar atención. Y sí, como dije, esas métricas son de Google y tienen implicaciones en el sitio web. Así que las tres métricas de los core web vitals son primero, la pintura de contenido más grande, que mide qué tan rápido se ve el contenido principal de una página web. Debería ocurrir dentro de un segundo 2.5 o cuando la página comienza a cargar por primera vez. El segundo es el primer retraso de entrada. Mide el tiempo que tarda una página web en volverse interactiva. Debería ser menos de cien milisegundos. Por último, pero no menos importante, el cambio de diseño acumulativo, que mide la estabilidad visual de una página web rastreando cambios inesperados de diseño de elementos. Y debería tener una puntuación de menos de 0.1. Y hay muchas más métricas, por supuesto, pero cubriremos las principales, los core web vitals aquí. Y hay un Plugin de Cypress 2, que podrías usar para monitorear los core web vitals a través de nuestra automation de pruebas.

5. Uso de Plugins de Cypress para el Monitoreo de Rendimiento

Short description:

Utilice los plugins de Cypress para monitorear las métricas de rendimiento y establecer umbrales para sus pruebas. Herramientas como Lighthouse y los escritores web de Cypress pueden ayudarlo a monitorear el rendimiento del sitio web y detectar fallas. Trate su trabajo de pruebas de extremo a extremo como un detective que verifica las métricas todas las noches. Recuerde medir el rendimiento, enfocarse en el front-end y utilizar la automatización de pruebas para capturar métricas de rendimiento. Las herramientas de automatización de pruebas pueden ser más que simples herramientas de prueba. Proporcionan información valiosa a un bajo costo.

Así que use este código QR para encontrarlo. Y permítanme mostrarlo un poco. Así que podrías instalarlo a través de npm o yarn, o tu gestor de paquetes favorito. Y luego puedes importar los comandos para que Cypress los conozca. De nuevo, el flujo de trabajo de instalación típico de Cypress cuando se trata de plugins. Como lo vemos aquí. Después, básicamente podrías empezar a usarlo dentro de tus pruebas. Así que lo importaré en el commands.js. Y luego usaré una prueba en blanco existente para incluir el comando de los escritores de cypress. Y usar algunos escritores web de configuración, que es la URL que quiero echar un vistazo. Y aparte de eso, es solo que, quiero usar los umbrales normales. Y como lo ves aquí, algo falla porque se ha cruzado un umbral. Así que el umbral que vimos en la diapositiva anterior. Y sí, la prueba falla si no necesitamos esos. Y bien, si ves un ejemplo con algunas métricas en él, incluso podrías usar otros umbrales si quieres. Por ejemplo, añadí el primer contenido para la página, que es el primer elemento mostrado, cuánto tiempo tarda en cargar. Bueno, el tiempo hasta el primer byte, el tiempo entre la solicitud de un recurso. Y cuando el primer byte de una respuesta comienza a llegar, que son métricas útiles también. Y si echas un vistazo a cómo está bloqueado, puedes verlo aquí en el test runner, verás, sí, el fallo visible dentro del log. Este es el log. Y por supuesto, el resultado está ahí también. Y puedes estar seguro de que tu prueba fallará si no coincide con los umbrales. Okay. Entonces, estas herramientas como Lighthouse y los escritores web de Cypress te ayudarán a monitorear el rendimiento de tu sitio web y harán que tu prueba falle, lo cual es realmente genial. Así que, podrías pensar en un pipeline en tu trabajo de pruebas de extremo a extremo como un pequeño detective, que va allí todas las noches y echa un vistazo a las métricas de tu aplicación. Y falla visible en las métricas de rendimiento no están alcanzando los umbrales. Puedes ver eso a través del login. Y sí, tienes tu propio Sherlock Cypress o Sherlock Playwright si quieres. Así que, te proporciona mucha información con no tanto costo. Genial, ¿verdad? Así que, si quieres recordar cuatro cosas de mi charla, que son realmente importantes cuando se trata de monitorear y mejorar el rendimiento del front-end utilizando la automatización de pruebas es siempre medir el rendimiento para mejorarlo porque de lo contrario no tienes posibilidad de mejorarlo. Los problemas de rendimiento a menudo se notan en el front-end, así que enfócate aquí primero para medir. Puedes usar tu normal automatización de pruebas de extremo a extremo para capturar la mayoría de las métricas de rendimiento y los agujeros de luz y especialmente los vitrales de cobalto pueden ser usados fácilmente como desordenadores de cypress. Así que, dije que puedes usar herramientas de automatización de pruebas para más que solo pruebas. Espero que puedan sentirse como un asistente para ti, así que siéntete libre de usarlos y espero que te estén ayudando mucho. Así que, ¿qué más decir entonces? Gracias por tu tiempo y por escucharme. Si tienes preguntas, puedes encontrarme como leichterkeek en las plataformas normales o en LinkedIn o simplemente dispara una pregunta y aparte de eso, gracias por escuchar y adiós.

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.
TestJS Summit 2021TestJS Summit 2021
33 min
Network Requests with Cypress
Whether you're testing your UI or API, Cypress gives you all the tools needed to work with and manage network requests. This intermediate-level task demonstrates how to use the cy.request and cy.intercept commands to execute, spy on, and stub network requests while testing your application in the browser. Learn how the commands work as well as use cases for each, including best practices for testing and mocking your network requests.
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
TestJS Summit 2021TestJS Summit 2021
38 min
Testing Pyramid Makes Little Sense, What We Can Use Instead
Featured Video
The testing pyramid - the canonical shape of tests that defined what types of tests we need to write to make sure the app works - is ... obsolete. In this presentation, Roman Sandler and Gleb Bahmutov argue what the testing shape works better for today's web applications.
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.

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 🤐)
React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Featured Workshop
React Testing Library is a great framework for React component tests because there are a lot of questions it answers for you, so you don’t need to worry about those questions. But that doesn’t mean testing is easy. There are still a lot of questions you have to figure out for yourself: How many component tests should you write vs end-to-end tests or lower-level unit tests? How can you test a certain line of code that is tricky to test? And what in the world are you supposed to do about that persistent act() warning?
In this three-hour workshop we’ll introduce React Testing Library along with a mental model for how to think about designing your component tests. This mental model will help you see how to test each bit of logic, whether or not to mock dependencies, and will help improve the design of your components. You’ll walk away with the tools, techniques, and principles you need to implement low-cost, high-value component tests.
Table of contents- The different kinds of React application tests, and where component tests fit in- A mental model for thinking about the inputs and outputs of the components you test- Options for selecting DOM elements to verify and interact with them- The value of mocks and why they shouldn’t be avoided- The challenges with asynchrony in RTL tests and how to handle them
Prerequisites- Familiarity with building applications with React- Basic experience writing automated tests with Jest or another unit testing framework- You do not need any experience with React Testing Library- Machine setup: Node LTS, Yarn
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.
TestJS Summit 2022TestJS Summit 2022
146 min
How to Start With Cypress
Featured WorkshopFree
The web has evolved. Finally, testing has also. Cypress is a modern testing tool that answers the testing needs of modern web applications. It has been gaining a lot of traction in the last couple of years, gaining worldwide popularity. If you have been waiting to learn Cypress, wait no more! Filip Hric will guide you through the first steps on how to start using Cypress and set up a project on your own. The good news is, learning Cypress is incredibly easy. You'll write your first test in no time, and then you'll discover how to write a full end-to-end test for a modern web application. You'll learn the core concepts like retry-ability. Discover how to work and interact with your application and learn how to combine API and UI tests. Throughout this whole workshop, we will write code and do practical exercises. You will leave with a hands-on experience that you can translate to your own project.
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 Summit 2022React Summit 2022
117 min
Detox 101: How to write stable end-to-end tests for your React Native application
WorkshopFree
Compared to unit testing, end-to-end testing aims to interact with your application just like a real user. And as we all know it can be pretty challenging. Especially when we talk about Mobile applications.
Tests rely on many conditions and are considered to be slow and flaky. On the other hand - end-to-end tests can give the greatest confidence that your app is working. And if done right - can become an amazing tool for boosting developer velocity.
Detox is a gray-box end-to-end testing framework for mobile apps. Developed by Wix to solve the problem of slowness and flakiness and used by React Native itself as its E2E testing tool.
Join me on this workshop to learn how to make your mobile end-to-end tests with Detox rock.
Prerequisites- iOS/Android: MacOS Catalina or newer- Android only: Linux- Install before the workshop