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

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.

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.

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.

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.

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.