Enfoque Integral de Rendimiento Web con Grafana y K6

Hola a todos. Mi nombre es Marie Cruz y soy una defensora del desarrollo aquí en Grafana Labs. Hoy me gustaría compartir con ustedes cómo pueden lograr un enfoque holístico del rendimiento web con herramientas como Grafana y K6. Pero primero, si desean una copia de estas diapositivas, siéntanse libres de escanear el código QR que se muestra aquí en mi pantalla.

Entonces, exploremos el problema en el que quiero enfocarme en mi charla de hoy. Las herramientas de pruebas de rendimiento son increíbles. Pero, ¿qué pasa con la experiencia de los usuarios reales? Por ejemplo, las pruebas de rendimiento que se crean con el módulo del navegador Grafana K6 utilizan datos de laboratorio recopilados de entornos, dispositivos y configuraciones de red predefinidos. Los datos de laboratorio te permiten reproducir los resultados de rendimiento de manera repetida, lo que resulta útil para detectar y solucionar problemas de rendimiento más temprano. Sin embargo, los datos de laboratorio no tienen en cuenta algo muy importante, que es la experiencia de usuario real. Los usuarios reales tienen diferentes comportamientos de usuario, que no se pueden simular de manera realista mediante scripts de prueba o casos de prueba. Por eso, es mejor complementar los datos de laboratorio con datos de campo para lograr un enfoque holístico de las pruebas de rendimiento web. Pero creo que primero es muy importante conocer la diferencia entre los datos de laboratorio y los datos de campo para entender por qué ambos son esenciales para las pruebas de rendimiento web.

Aquí hay una analogía de un automóvil que puede ayudarnos a ilustrar la diferencia. Imagina que estás testing la velocidad de un nuevo modelo de automóvil en un entorno controlado como una pista de carreras. Tienes un cronómetro y mides qué tan rápido acelera el automóvil, mides cómo frena y mides cómo puede tomar las curvas. Registras estas mediciones de manera consistente sin tráfico, condiciones de la carretera perfectas, y con un conductor muy hábil al volante.

Ahora imagina el rendimiento de un automóvil en carreteras como una calle concurrida de una ciudad o autopistas. Las condiciones de la carretera variarán, habrá tráfico inevitable y diferentes conductores pueden manejar el automóvil de manera diferente. Los datos de laboratorio para el rendimiento web son similares al rendimiento de nuestro automóvil en un entorno idealizado. Los datos de laboratorio se recopilan en un entorno controlado, a menudo con herramientas o scripts especializados que simulan las interacciones del usuario en un sitio web y son útiles para detectar problemas de rendimiento más temprano. Por otro lado, los datos de campo son similares al rendimiento de nuestro automóvil en condiciones reales de la carretera. Los datos de campo reflejan cómo los usuarios acceden a su sitio desde diferentes dispositivos y ubicaciones y bajo diferentes condiciones de red. Estos usuarios también pueden tener diferentes navegadores y velocidades de conexión, al igual que los conductores reales en las carreteras tendrán habilidades y comportamientos diferentes.

Ahora, cuando trabajas con herramientas que utilizan datos de laboratorio, es posible que notes que las métricas de rendimiento web pueden diferir de las generadas por herramientas que utilizan datos de campo. Como ejemplo, cuando ejecutas una prueba de rendimiento web en un entorno de laboratorio, normalmente solo incluyes la URL base de la aplicación web que estás testing. Sin embargo, en el mundo real, diferentes usuarios accederán a un sitio web utilizando diferentes parámetros de consulta o diferentes fragmentos de texto, lo que también puede afectar las métricas de rendimiento web. Cuando tus usuarios acceden a tu sitio web en la vida real, también habrá diferentes anuncios dirigidos según el historial de navegación de tus usuarios, lo que también puede afectar las métricas de rendimiento web. Entonces, ahora has comprendido la diferencia entre los datos de laboratorio y los datos de campo. ¿Cuándo debes usarlos cuando se trata del rendimiento web? Entonces, ambos tipos de datos son valiosos para diferentes propósitos. Los datos de laboratorio son excelentes cuando se utilizan durante las etapas de desarrollo temprano y pruebas. Debido al entorno controlado, los problemas de rendimiento se pueden detectar y solucionar más temprano. Entonces, como ejemplo, si deseas comprender tus métricas de rendimiento en una configuración específica como un dispositivo o un tamaño de pantalla particular, en ese caso, podrías configurarlo de manera controlada sin preocuparte por otros factores externos.

Entonces, por ejemplo, herramientas como K6 se pueden utilizar para simular todas estas configuraciones diferentes para que puedas detectar problemas en tus entornos de preproducción. Ahora, por otro lado, los datos de campo proporcionan una imagen general de cómo funciona tu sitio web en el mundo real. Cuando tu sitio web está ahora público, necesitarás un monitoreo continuo para detectar problemas de rendimiento en tu entorno en vivo. Y aquí es donde soluciones como GrafanaFaro pueden ayudar.

Entonces, ¿qué es GrafanaFaro? GrafanaFaro es un SDK web que puedes configurar para recopilar automáticamente todos los registros relevantes, errores y otras métricas de rendimiento para tu aplicación. Puedes configurar GrafanaFaro configurando una instancia del agente Grafana y luego enviar los datos de telemetría recopilados a otros productos de Grafana OSS como Loki para registros y Tempo para trazas. Pero la forma más fácil de comenzar con GrafanaFaro es registrándote en una cuenta gratuita en GrafanaCloud, y luego puedes usar el plan gratuito para siempre.

Entonces, cuando te registras en GrafanaCloud, hay un producto llamado GrafanaCloud Front End Observability, que es el servicio alojado de Grafana que utiliza el SDK web de GrafanaFaro en el fondo. Contiene paneles predefinidos, lo que facilita comenzar con Faro.

Ahora, dado que solo tengo poco tiempo para esta charla, demostraré cómo puedes configurar GrafanaFaro utilizando el producto Front End Observability, que se incluye de forma gratuita como parte de tu plan gratuito de Grafana para siempre. Entonces, para demostrar cómo podemos configurar GrafanaFaro, instrumentaré una aplicación de ejemplo llamada QuickPizza. Está disponible públicamente en github.com diagonal grafana diagonal quickpizza. Y hay mucha información detallada sobre cómo configurar esto localmente.

Así que ahora pasemos a la demostración. QuickPizza es una aplicación muy sencilla que puedes usar para generar combinaciones de pizza nuevas y emocionantes. Se puede configurar fácilmente utilizando Docker, y hemos agregado un montón de instrucciones aquí que pueden guiarte según el tipo de pruebas o caso de uso que desees.

Ya tengo la aplicación en funcionamiento. Y como puedes ver, es una aplicación muy sencilla. Hay un botón de `Pizza, por favor`. Si haces clic en eso, generará una combinación de pizza aleatoria y emocionante. Al mismo tiempo, también hay una pestaña advanced donde puedes establecer las calorías máximas por porción, el número mínimo de ingredientes y el número máximo de ingredientes. Y también puedes excluir algunas herramientas diferentes.

Ahora imaginemos que uno de tus usuarios se ha vuelto loco y ha ingresado un número muy aleatorio como parte del campo de número mínimo de ingredientes. Ahora, cuando hagan clic en `Pizza, por favor`, aún podrán ver algunas recomendaciones de pizza, aunque claramente el valor que hemos agregado aquí no es correcto. Así que abramos la consola de herramientas para desarrolladores y veamos si se están imprimiendo errores. Así que abramos la consola y veamos qué está sucediendo.

Como puedes ver, se están imprimiendo una serie de errores de JavaScript, pero no se están gestionando correctamente en nuestra aplicación de frontend. Idealmente, quieres capturar estos errores. Y tal vez mostrar algún tipo de advertencia o mensaje de error para que tus usuarios sepan que han hecho algo incorrectamente. Entonces, si estamos usando Grafana Faro, ¿cómo podemos rastrear estos diferentes errores? Lo primero que voy a hacer es volver a la página de inicio. Cuando creas tu cuenta de Grafana Cloud, serás redirigido a esta página de inicio y deberías ver una pestaña de frontend aquí para el producto de observability del frontend. Ya he creado la aplicación QuickPizza aquí, pero simplemente puedes crear un nuevo proyecto haciendo clic en `crear nuevo`, proporcionando un nombre y un origen permitido. Esto es básicamente la URL que se permite enviar los datos del frontend al punto de conexión de Grafana Faro. En nuestro caso, esto será simplemente el puerto localhost. Una vez que hayas hecho eso, así que voy a presionar el botón de editar aquí, deberías ver una pestaña para la configuración del SDK web. La URL de Grafana Faro, esto es a lo que me refiero.

Entonces, desde la perspectiva de QuickPizza, todo lo que necesitas hacer es agregar esa URL y exportarla a una variable de entorno llamada QuickPizza.conf.faro.url y luego agregarla al archivo .env.

Así que lo hemos hecho muy simple para que puedas comenzar si usas la aplicación QuickPizza. Pero para tus propias aplicaciones, simplemente puedes agregar el siguiente fragmento de código antes de cualquier otro código JavaScript o TypeScript. Por ejemplo, esto podría estar en tu archivo de índice principal justo antes de la inicialización de tu aplicación. De hecho, ya lo he hecho y he exportado mi URL de QuickPizza faro.

Ahora estoy de vuelta en el proyecto QuickPizza como parte de mi producto de observabilidad del frontend. Y aquí hay varias pestañas diferentes, como la descripción general, los diferentes errores, el seguimiento general y las diferentes sesiones que he realizado. Así que volvamos a la pestaña de descripción general. Desde una perspectiva de rendimiento web, Grafana Faro utiliza las métricas vitales de la web para que puedas comprender lo que realmente está sucediendo en la experiencia real de tus usuarios. Por lo tanto, las métricas como el primer contenido visible, el contenido visible grande, el cambio de diseño acumulativo y las demás métricas vitales de la web se rastrean aquí en tiempo real. Por lo tanto, puedes analizar en detalle las diferentes métricas vitales de la web a lo largo del tiempo a medida que rastreas tu aplicación. Si vas a la pestaña de errores, puedes ver aquí los principales errores que están experimentando tus usuarios. Por ejemplo, el final inesperado de la entrada JSON. Este fue el mensaje de error que se mostraba en mi consola cuando intentaba proporcionar un número arbitrario como parte del número mínimo de ingredientes. Pero aparte de eso, puedes ver qué navegador o qué versión se encontró el error. Por lo tanto, puedes tener una vista mucho más investigativa de las diferentes áreas que ven tus usuarios si están utilizando diferentes combinaciones de navegadores.

Ahora, dado que tenemos ese error ocurriendo en producción, necesitamos poder reproducir este error de manera consistente en nuestro entorno de preproducción para que también podamos verificar que cualquier corrección de errores que nuestro equipo implemente funcione y evite que el problema vuelva a aparecer. También puede haber otros errores ocurriendo de los que no estás al tanto porque las pruebas de control o las pruebas de laboratorio que has creado como parte de tu estrategia de testing no pudieron capturar esto. Estos diferentes errores también pueden ralentizar el rendimiento de tu aplicación si no se les presta atención a lo largo del tiempo.

Ahora, complementar los datos de laboratorio con observaciones de datos de campo permite este enfoque continuo de testing de rendimiento. Puedes incorporar los comentarios que obtienes al realizar pruebas de campo y mejorar aún más tus pruebas de laboratorio. Una herramienta que puede ayudarte a complementar tus datos de campo es K6. Grafana K6 es una poderosa herramienta amigable para desarrolladores diseñada y desarrollada con un enfoque en las pruebas de carga, pero cuenta con capacidades más allá de ese caso de uso. K6 comenzó como una herramienta de pruebas de carga, pero ahora también puede admitir pruebas de navegadores, inyección de fallos e incluso más.

Puedes pensar en K6 como tu amigo de testing de confiabilidad que puede ayudarte a detectar estos diferentes problemas antes de que lleguen a producción. Ahora, una característica de K6 que puede ayudar con el rendimiento web es el módulo de Navegador, que tomó inspiration de Playwright. El módulo de Navegador, que comenzó como una extensión y ahora es un módulo experimental en K6, agrega automatización de navegadores y pruebas web de extremo a extremo a K6, al tiempo que admite las características principales de K6. Agrega APIs a nivel de navegador para interactuar con los navegadores y recopilar métricas de rendimiento web como parte de tus pruebas. Usando K6 Navegador, puedes simular las acciones del navegador para el escenario de errores de JavaScript y confirmar que la corrección que tu equipo va a implementar abordará el problema, lo que podría ser la introducción de un mensaje de error muy simple que se mostrará a tus usuarios cada vez que ingresen un valor no válido en alguno de los campos.

Ahora, vamos a hacer una rápida demostración nuevamente. Bien, lo primero que he hecho es crear un archivo vacío llamado browser.js y luego vamos a importar el módulo del navegador. Para hacer eso, agreguemos rápidamente la declaración de importación para usar el módulo del navegador. Luego voy a crear mi función predeterminada. Las funciones predeterminadas en K6 son básicamente el código que tu usuario virtual ejecutará dependiendo de cuántos usuarios virtuales tengas. En este caso, no configuré ningún usuario virtual porque solo quiero verlo desde una perspectiva de usuario único. Así que simplemente creemos la función predeterminada tal como está.

Entonces, exportemos la función predeterminada. Una vez que hayas creado la función predeterminada, necesitamos abrir una nueva página y aquí es donde la inspiration de Playwright realmente entra en juego porque notarás que los diferentes métodos que voy a usar son bastante similares a los que proporciona Playwright, aunque no son exactamente iguales. Así que creemos una nueva página ahora. Browser.newpage y una vez que haya abierto una nueva página, simplemente visitemos la aplicación. Eso será en localhost puerto 3333. Y dado que el método goto es una operación asíncrona, necesito usar la palabra clave await. Así que debemos convertir esto en una función asíncrona. Y permíteme agregar rápidamente también el page.close porque este es un paso obligatorio. Entonces, si estás abriendo una nueva página, también necesitas cerrarla. Así que este es un primer paso muy simple para nuestras pruebas de navegador.

Ahora, si estás usando K6 Browser, necesitas agregar algo de código adicional y asegurarte de que estás ejecutando esto usando un navegador basado en Chromium. Así que voy a agregar eso rápidamente. Bien, una vez que se haya agregado, podemos volver a nuestra terminal y te mostraré cómo puedes ejecutar fácilmente esta prueba. Entonces, si vuelvo a mi terminal aquí, necesitamos establecer la variable de entorno K6 Browser headless en false para que podamos ver las acciones que suceden. Y luego, todo lo que necesitas hacer, y esto es después de haber instalado K6, si estás en una Mac, puedes instalar fácilmente K6 usando homebrew. Solo necesitas usar el comando K6 run y luego pasar el nombre del archivo y luego ejecutarlo rápidamente y es un poco rápido, pero viste la aplicación. Pero ahora agregaré los pasos que vamos a hacer para simular el escenario que causó el error de JavaScript. Así que volvamos a la aplicación de Quick Pizza, abramos las herramientas de desarrollo, vayamos a elementos aquí y veamos qué selector hay aquí. Y luego vamos a usar el page.locator para interactuar con ese selector en particular. Pasamos el selector para la pestaña advanced y luego usamos el método check. Esto marcará la casilla de verificación para navegar a la vista advanced. Ahora solo voy a agregar los otros pasos relevantes para completar el recorrido del usuario. Y también voy a agregar la verificación para asegurarnos de que se muestre un mensaje de error.

Ten en cuenta que esto no se mostrará realmente en la aplicación, pero puedes ver cómo se ve. Así que si la aplicación de Quick Pizza de repente tiene la notificación de mensaje de error, al menos mi prueba de navegador podrá cubrir eso.

Ok, he agregado un montón de código aquí, pero básicamente esto solo va a simular el escenario donde escribo un valor inválido y luego hago clic en el botón de pizza por favor y luego también verificará si el mensaje de error está realmente visible en la página. Así que ahora intentemos ejecutar esa prueba nuevamente. Puedes ver que la aplicación va lenta porque está tratando de encontrar que el mensaje de error esté allí, lo cual en este momento no está. Pero entiendes la idea de utilizar las observaciones de tus pruebas de campo y luego utilizar eso como retroalimentación para tus pruebas de navegador. Una cosa a tener en cuenta aquí es que el módulo del navegador de Grafana K6 también mide las métricas vitales de la web. Así que aquí puedes ver las diferentes métricas que se informaron y esta es una buena oportunidad para comparar las métricas que obtienes de tus pruebas de laboratorio y luego comparar eso con lo que realmente está sucediendo desde la perspectiva de tus usuarios. Pero no te obsesiones con que las métricas vitales de la web que obtienes de tus pruebas de laboratorio no coincidan con las métricas vitales de la web que obtienes de tus pruebas de campo porque, como mencioné antes, hay muchos otros factores externos en juego. Pero lo que puedes hacer es mantener una tendencia de estas diferentes métricas a lo largo del tiempo y ver si las métricas que obtienes de tus pruebas de laboratorio y campo están mejorando con el tiempo. Ahora, cuando se trata de crear una estrategia de rendimiento web, debes poder incluir tanto los datos de laboratorio como los datos de campo. Los datos de laboratorio y campo se complementan entre sí en lugar de trabajar en su contra. Así que si quieres saber más sobre cómo puedes medir el rendimiento web de tu aplicación utilizando tanto los datos de laboratorio como los datos de campo, echa un vistazo al módulo del navegador Grafana K6, así como a la documentación de Grafana Faro. Espero que esta charla haya sido realmente útil. Las herramientas que he demostrado aquí son solo ejemplos de herramientas que puedes incorporar como parte de tu estrategia de pruebas dependiendo del contexto en el que te encuentres. También puedes probar otras herramientas, pero asegúrate de que cuando se trata de tener este rendimiento web holístico, no debes ignorar los datos de laboratorio o de campo, sino asegurarte de que estos trabajen juntos en lugar de hacerlo por separado. Muchas gracias por escuchar y espero que esta charla haya sido útil. ¡Adiós!