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

This ad is not shown to multipass and full ticket holders
React Summit US
React Summit US 2025
November 18 - 21, 2025
New York, US & Online
The biggest React conference in the US
Learn More
In partnership with Focus Reactive
Upcoming event
React Summit US 2025
React Summit US 2025
November 18 - 21, 2025. New York, US & Online
Learn more
Bookmark
Rate this content

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.

This talk has been presented at TestJS Summit 2023, check out the latest edition of this JavaScript Conference.

FAQ

Ramona trabaja como Developer Advocate en Offs Zero, es Google Developer Expert en tecnología web y embajador de Cypress.

Ramona se centró en el tema de 'performance' dentro del contexto de pruebas de software, abordando cómo la información y la automatización son clave en este ámbito.

Las tres métricas principales son: la Pintura de Contenido Más Grande (LCP), el Primer Retraso de Entrada (FID), y el Cambio de Layout Acumulativo (CLS).

Ramona propone usar las pruebas de extremo a extremo para capturar métricas de rendimiento significativas y utilizar herramientas como Lighthouse y Cypress para evaluar y mejorar la performance de las aplicaciones.

Ramona menciona varias herramientas como phpStan, ESlearnStyle, y otras herramientas de análisis estático que pueden ayudar a mejorar la calidad del código y facilitar las pruebas.

La automatización es crucial para apoyar los tres aspectos esenciales de las aplicaciones: hacer que funcionen correctamente, mantenerlas bien y optimizar su rendimiento.

Integrar la automatización de pruebas permite no solo verificar la funcionalidad y la calidad del código, sino también monitorear y mejorar el rendimiento de la aplicación, haciendo más eficiente el proceso de desarrollo.

Ramona Schwering
Ramona Schwering
22 min
11 Dec, 2023

Comments

Sign in or register to post your comment.
Video Summary and Transcription
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

Una Guía del Comportamiento de Renderizado de React
React Advanced 2022React Advanced 2022
25 min
Una Guía del Comportamiento de Renderizado de React
Top Content
This transcription provides a brief guide to React rendering behavior. It explains the process of rendering, comparing new and old elements, and the importance of pure rendering without side effects. It also covers topics such as batching and double rendering, optimizing rendering and using context and Redux in React. Overall, it offers valuable insights for developers looking to understand and optimize React rendering.
Acelerando tu aplicación React con menos JavaScript
React Summit 2023React Summit 2023
32 min
Acelerando tu aplicación React con menos JavaScript
Top Content
Mishko, the creator of Angular and AngularJS, discusses the challenges of website performance and JavaScript hydration. He explains the differences between client-side and server-side rendering and introduces Quik as a solution for efficient component hydration. Mishko demonstrates examples of state management and intercommunication using Quik. He highlights the performance benefits of using Quik with React and emphasizes the importance of reducing JavaScript size for better performance. Finally, he mentions the use of QUIC in both MPA and SPA applications for improved startup performance.
Solicitudes de Red con Cypress
TestJS Summit 2021TestJS Summit 2021
33 min
Solicitudes de Red con Cypress
Top Content
Cecilia Martinez, a technical account manager at Cypress, discusses network requests in Cypress and demonstrates commands like cydot request and SCI.INTERCEPT. She also explains dynamic matching and aliasing, network stubbing, and the pros and cons of using real server responses versus stubbing. The talk covers logging request responses, testing front-end and backend API, handling list length and DOM traversal, lazy loading, and provides resources for beginners to learn Cypress.
Concurrencia en React, Explicada
React Summit 2023React Summit 2023
23 min
Concurrencia en React, Explicada
Top Content
React 18's concurrent rendering, specifically the useTransition hook, optimizes app performance by allowing non-urgent updates to be processed without freezing the UI. However, there are drawbacks such as longer processing time for non-urgent updates and increased CPU usage. The useTransition hook works similarly to throttling or bouncing, making it useful for addressing performance issues caused by multiple small components. Libraries like React Query may require the use of alternative APIs to handle urgent and non-urgent updates effectively.
How React Compiler Performs on Real Code
React Advanced 2024React Advanced 2024
31 min
How React Compiler Performs on Real Code
Top Content
I'm Nadia, a developer experienced in performance, re-renders, and React. The React team released the React compiler, which eliminates the need for memoization. The compiler optimizes code by automatically memoizing components, props, and hook dependencies. It shows promise in managing changing references and improving performance. Real app testing and synthetic examples have been used to evaluate its effectiveness. The impact on initial load performance is minimal, but further investigation is needed for interactions performance. The React query library simplifies data fetching and caching. The compiler has limitations and may not catch every re-render, especially with external libraries. Enabling the compiler can improve performance but manual memorization is still necessary for optimal results. There are risks of overreliance and messy code, but the compiler can be used file by file or folder by folder with thorough testing. Practice makes incredible cats. Thank you, Nadia!

Workshops on related topic

Masterclass de Depuración de Rendimiento de React
React Summit 2023React Summit 2023
170 min
Masterclass de Depuración de Rendimiento de React
Top Content
Featured Workshop
Ivan Akulov
Ivan Akulov
Los primeros intentos de Ivan en la depuración de rendimiento fueron caóticos. Vería una interacción lenta, intentaría una optimización aleatoria, vería que no ayudaba, y seguiría intentando otras optimizaciones hasta que encontraba la correcta (o se rendía).
En aquel entonces, Ivan no sabía cómo usar bien las herramientas de rendimiento. Haría una grabación en Chrome DevTools o React Profiler, la examinaría, intentaría hacer clic en cosas aleatorias, y luego la cerraría frustrado unos minutos después. Ahora, Ivan sabe exactamente dónde y qué buscar. Y en esta masterclass, Ivan te enseñará eso también.
Así es como va a funcionar. Tomaremos una aplicación lenta → la depuraremos (usando herramientas como Chrome DevTools, React Profiler, y why-did-you-render) → identificaremos el cuello de botella → y luego repetiremos, varias veces más. No hablaremos de las soluciones (en el 90% de los casos, es simplemente el viejo y regular useMemo() o memo()). Pero hablaremos de todo lo que viene antes - y aprenderemos a analizar cualquier problema de rendimiento de React, paso a paso.
(Nota: Esta masterclass es más adecuada para ingenieros que ya están familiarizados con cómo funcionan useMemo() y memo() - pero quieren mejorar en el uso de las herramientas de rendimiento alrededor de React. Además, estaremos cubriendo el rendimiento de la interacción, no la velocidad de carga, por lo que no escucharás una palabra sobre Lighthouse 🤐)
Diseñando Pruebas Efectivas con la Biblioteca de Pruebas de React
React Summit 2023React Summit 2023
151 min
Diseñando Pruebas Efectivas con la Biblioteca de Pruebas de React
Top Content
Featured Workshop
Josh Justice
Josh Justice
La Biblioteca de Pruebas de React es un gran marco para las pruebas de componentes de React porque responde muchas preguntas por ti, por lo que no necesitas preocuparte por esas preguntas. Pero eso no significa que las pruebas sean fáciles. Todavía hay muchas preguntas que tienes que resolver por ti mismo: ¿Cuántas pruebas de componentes debes escribir vs pruebas de extremo a extremo o pruebas de unidad de nivel inferior? ¿Cómo puedes probar una cierta línea de código que es difícil de probar? ¿Y qué se supone que debes hacer con esa persistente advertencia de act()?
En esta masterclass de tres horas, presentaremos la Biblioteca de Pruebas de React junto con un modelo mental de cómo pensar en el diseño de tus pruebas de componentes. Este modelo mental te ayudará a ver cómo probar cada bit de lógica, si debes o no simular dependencias, y ayudará a mejorar el diseño de tus componentes. Te irás con las herramientas, técnicas y principios que necesitas para implementar pruebas de componentes de bajo costo y alto valor.
Tabla de contenidos- Los diferentes tipos de pruebas de aplicaciones de React, y dónde encajan las pruebas de componentes- Un modelo mental para pensar en las entradas y salidas de los componentes que pruebas- Opciones para seleccionar elementos DOM para verificar e interactuar con ellos- El valor de los mocks y por qué no deben evitarse- Los desafíos con la asincronía en las pruebas de RTL y cómo manejarlos
Requisitos previos- Familiaridad con la construcción de aplicaciones con React- Experiencia básica escribiendo pruebas automatizadas con Jest u otro marco de pruebas unitarias- No necesitas ninguna experiencia con la Biblioteca de Pruebas de React- Configuración de la máquina: Node LTS, Yarn
Detox 101: Cómo escribir pruebas de extremo a extremo estables para su aplicación React Native
React Summit 2022React Summit 2022
117 min
Detox 101: Cómo escribir pruebas de extremo a extremo estables para su aplicación React Native
Top Content
Workshop
Yevheniia Hlovatska
Yevheniia Hlovatska
A diferencia de las pruebas unitarias, las pruebas de extremo a extremo buscan interactuar con su aplicación tal como lo haría un usuario real. Y como todos sabemos, puede ser bastante desafiante. Especialmente cuando hablamos de aplicaciones móviles.
Las pruebas dependen de muchas condiciones y se consideran lentas e inestables. Por otro lado, las pruebas de extremo a extremo pueden dar la mayor confianza de que su aplicación está funcionando. Y si se hace correctamente, puede convertirse en una herramienta increíble para aumentar la velocidad del desarrollador.
Detox es un marco de pruebas de extremo a extremo en caja gris para aplicaciones móviles. Desarrollado por Wix para resolver el problema de la lentitud e inestabilidad y utilizado por React Native en sí como su herramienta de pruebas E2E.
Únete a mí en esta masterclass para aprender cómo hacer que tus pruebas de extremo a extremo móviles con Detox sean excelentes.
Prerrequisitos- iOS/Android: MacOS Catalina o más reciente- Solo Android: Linux- Instalar antes de la masterclass
Next.js 13: Estrategias de Obtención de Datos
React Day Berlin 2022React Day Berlin 2022
53 min
Next.js 13: Estrategias de Obtención de Datos
Top Content
Workshop
Alice De Mauro
Alice De Mauro
- Introducción- Prerrequisitos para la masterclass- Estrategias de obtención: fundamentos- Estrategias de obtención – práctica: API de obtención, caché (estática VS dinámica), revalidar, suspense (obtención de datos en paralelo)- Prueba tu construcción y sírvela en Vercel- Futuro: Componentes de servidor VS Componentes de cliente- Huevo de pascua de la masterclass (no relacionado con el tema, destacando la accesibilidad)- Conclusión
Masterclass de Pruebas de API con Postman
TestJS Summit 2023TestJS Summit 2023
48 min
Masterclass de Pruebas de API con Postman
Top Content
WorkshopFree
Pooja Mistry
Pooja Mistry
En el panorama siempre en evolución del desarrollo de software, garantizar la fiabilidad y funcionalidad de las API se ha vuelto primordial. "Pruebas de API con Postman" es una masterclass completa diseñada para equipar a los participantes con los conocimientos y habilidades necesarios para sobresalir en las pruebas de API utilizando Postman, una herramienta poderosa ampliamente adoptada por profesionales en el campo. Esta masterclass profundiza en los fundamentos de las pruebas de API, avanza a técnicas de prueba avanzadas y explora la automatización, las pruebas de rendimiento y el soporte multiprotocolo, proporcionando a los asistentes una comprensión holística de las pruebas de API con Postman.
Únete a nosotros para esta masterclass para desbloquear todo el potencial de Postman para las pruebas de API, agilizar tus procesos de prueba y mejorar la calidad y fiabilidad de tu software. Ya seas un principiante o un probador experimentado, esta masterclass te equipará con las habilidades necesarias para sobresalir en las pruebas de API con Postman.
Monitoreo 101 para Desarrolladores de React
React Summit US 2023React Summit US 2023
107 min
Monitoreo 101 para Desarrolladores de React
Top Content
WorkshopFree
Lazar Nikolov
Sarah Guthals
2 authors
Si encontrar errores en tu proyecto frontend es como buscar una aguja en un pajar de código, entonces el monitoreo de errores de Sentry puede ser tu detector de metales. Aprende los conceptos básicos del monitoreo de errores con Sentry. Ya sea que estés ejecutando un proyecto de React, Angular, Vue, o simplemente JavaScript “vainilla”, mira cómo Sentry puede ayudarte a encontrar el quién, qué, cuándo y dónde detrás de los errores en tu proyecto frontend.
Nivel de la masterclass: Intermedio