El Rendimiento Web se Encuentra con las Ciencias Humanas

Wow, hola a todos. Es genial estar aquí en Ámsterdam. Como dijo Nathaniel, ese soy yo. Soy Matheus Albuquerque. Puedes encontrarme en todas partes como Vidacombinator. Trabajo en esta empresa llamada Medallia y también soy GDE en rendimiento web. Y me siento realmente genial de estar de vuelta en el React Summit. Estuve aquí hace unos años contando una pequeña historia sobre los internos de React. Y hoy quiero obtener su ayuda para contar una historia diferente sobre un poco de los internos de nuestras mentes.

Así que para decirles por qué quiero contar la historia para empezar, tengo un pequeño preámbulo aquí. Y me gustaría comenzar esto con esta reflexión. ¿Qué significa ser rápido para ti? O aún mejor, quiero que empieces a imaginar en tu cabeza. Si tuvieras que resumir la velocidad, la velocidad web en una métrica, ¿con cuál irías? Como mencioné, quiero su ayuda para contar esta historia. Así que este código QR va a estar en la pantalla durante los próximos segundos. Y realmente me encantaría si pudieras tomar fotos y comenzar a ingresar tu opinión.

Esto no va a ser codificación en vivo, sino un ejercicio de demostración en vivo en cierto sentido. Así que crucemos los dedos para que funcione. Además, es súper complicado hacer una pequeña conversación durante 30 segundos. Es mucho tiempo cuando estás en el escenario tratando de distraer a la gente. Creo que hemos terminado y podemos avanzar. Probablemente luchaste durante los últimos 30 minutos para resumir las cosas en una métrica, porque vivimos en esta realidad donde simplemente tenemos tanto. Tenemos docenas de métricas sintéticas. Tenemos docenas de métricas de monitoreo de usuarios reales. Tenemos docenas de métricas que tenemos que adaptar para casos de uso específicos y demás. Esto fue lo que dijiste. Hablamos sobre latencia, sobre TTI, que espera, capacidad de respuesta, sí, las respuestas siguen llegando. Y un denominador común que veo cada vez que hago esta pregunta en diferentes conferencias es que es súper difícil encontrar este único denominador común. Y eso es porque el cliché es cierto. Las métricas de velocidad no son un solo número. Pero aún más que eso, no son solo un solo número, sino que recientemente hemos estado encontrando formas de hackear algunas de estas o hackear la forma en que se calculan, como Core App Vitals y otros, porque queremos manipular estas métricas.

Queremos presumir que nuestros sistemas son cada vez más rápidos. Queremos obtener mejores clasificaciones en SEO y demás. Así que no solo no hay un número único, sino que a veces pueden ser hackeados. Así que mi motivación aquí es tratar de encontrar las cosas que no pueden ser tan fácilmente hackeadas, o lo que llamo métricas no hackeables. Y estos son principalmente los indicadores del comportamiento real del usuario. Así que el tiempo que pasan fuera del sitio, tus tasas de rebote, tus conversiones, los ingresos de tu negocio, y este tipo de cosas. Pero desafortunadamente, como muchos de ustedes saben, este es también el tipo de métricas que no quieres llevar a diapositivas y estados porque eso es principalmente datos corporativos privados . E incluso la falta de esto podría básicamente decirle a los competidores cómo está tu negocio y etcétera.

Así que en esta búsqueda, hay una muy buena publicación de Andy Davis que se llama Strengthening the Link Between Speed and Business Outcomes. Y hay una imagen que realmente me gusta. Que es, él dice, el contexto influye en la experiencia del visitante, lo que influye en el comportamiento del visitante, lo que influye en los resultados comerciales. Así que lo que quiero hacer contigo en los próximos 20 minutos es desglosar esto. En la primera mitad, quiero hablar sobre el sesgo humano y la frustración del usuario. Y después, quiero hablar sobre cómo podemos empezar a pensar en medir la frustración. Así que comenzando con el sesgo. Así que una definición de sesgo, y todos lo tenemos porque todos tenemos cerebros, es que un sesgo cognitivo es un error sistemático en el pensamiento que ocurre cuando las personas procesan e interpretan información en su entorno influyendo en sus decisiones y juicios.

Y hay algo llamado los índices de sesgo cognitivo, que no espero que puedas leer. Pero la cuestión es que, si hago zoom en cualquier parte de esta imagen, vas a ver que hay miles si no cientos de sesgos. Así que, por supuesto, no podemos cubrirlos todos. Así que aquí, quiero discutir cómo las cosas impactan en cómo vemos nuestros datos, cómo los usuarios buscan nuestras aplicaciones, y cómo nosotros como humanos percibimos el tiempo. Así que cómo vemos nuestros datos. Hay dos sesgos aquí de los que quería hablar. Es el sesgo de confirmación y el sesgo de resultado . Así que el sesgo de resultado básicamente ocurre cuando elegimos datos que confirman nuestros resultados pasados. Y hacemos esto muchas veces al analizar las mejoras de velocidad que entregamos. Y el sesgo de confirmación es básicamente elegimos datos que confirman nuestras creencias preexistentes.

Así que usamos una nueva herramienta porque creemos que esto va a hacer que nuestra búsqueda sea más rápida. Y queremos demostrar usando eso, que está haciendo nuestra búsqueda más rápida. Pero mi favorito que impacta cómo vemos nuestros datos es el sesgo de supervivencia. Y probablemente hayas visto esta imagen por ahí. Es una imagen súper popular. La gente tuitea mucho. Pero quería proponer una visión diferente del sesgo de supervivencia en la web. Y para eso, quiero traer este estudio de caso del equipo de YouTube llamado PageRate Matters.

Y básicamente proviene del equipo de YouTube allá por 2012 cuando implementaron un montón de optimizaciones de rendimiento en la página de YouTube a través de algo que llamaron Fedders. Y lo más extraño sucedió. Después de que terminaron con todas las mejoras y etcétera, se dieron cuenta de que las métricas de rendimiento empeoraron. No mejoraron, sino que empeoraron. Tras un examen más detallado, descubrieron que lo que estaba sucediendo es que había ciertas partes del mundo como partes remotas de Siberia, África Subsahariana, Sudeste Asiático, América Central y demás, que simplemente tardaban 20 minutos en cargar un video.

Así que nunca llegaban al punto de ver el video. Y después de que lanzaron el proyecto Fedders, las personas que vivían allí finalmente pudieron abrir videos. Y por eso obtuvieron peores métricas. Porque finalmente pudieron ver esa muestra de usuarios. Y la razón por la que creo que esto es importante es porque tenemos muchas cosas que usualmente filtran a las personas de nuestras aplicaciones. Tenemos, por ejemplo, las diferentes realidades de dispositivos y ancho de banda.

Y por dispositivos, me refiero a cómo los mercados penetraron en internet. Como en Nigeria, la penetración de internet ocurrió después de la era de las computadoras. Así que pasaron directamente a los smartphones de bajo costo. Así que es una realidad totalmente diferente a algunos otros países que solemos observar.

Además, vivimos en un mundo donde los dispositivos simplemente tardan mucho tiempo en incluso analizar o JavaScript. Este es un estudio realizado por Edios Mani en 2017, donde mostraba desde el extremo más alto hasta el más bajo la diferencia en segundos para analizar un megabyte de JavaScript.

También en ancho de banda, vamos a ver muchas partes del mundo donde la principal forma de acceder a internet es a través de 2G o 3G. E incluso cuando hablamos de la misma tecnología, como las conexiones LTE, esto puede significar muchas cosas diferentes en todo el mundo. Así que podríamos estar variando de 6 a 45 megabytes por segundo, dependiendo de dónde estés hablando de la misma tecnología. Y esto se refleja en todo el espectro, hasta las velocidades de descarga, por ejemplo. Así que la gente descargará tu sitio web a una velocidad muy, muy diferente.

Y otra cosa que es súper importante, y que podría estar filtrando a las personas de tus aplicaciones, es la asequibilidad. Así que esta es una investigación en ITU Data Hub que básicamente muestra la asequibilidad de tener internet en casa versus el GNI per cápita o lo que cada persona gana a lo largo del año. Y habrá algunos países donde puede ser el 100% de lo que ganan en un año. Así que no es asequible en absoluto. Y si haces zoom y tomas dos muestras, como Portugal y Mozambique, dos países que incluso hablan el mismo idioma. Y en el primero cuesta el 1.26% de lo que ganan en un año tener internet en sus hogares. Y en el segundo, cuesta casi la mitad. Así que esto es súper diferente.

Y el segundo, cuesta casi la mitad. Así que esto es muy diferente. {{^}}Y por eso creo que es realmente importante tener iniciativas como esta de ThinkAdlike.

Ya no está en línea, pero solía llamarse What Does My Site Cost? Y básicamente comparaba las métricas de rendimiento de tu sitio web con el costo de internet en diferentes países. Otra cosa que también impacta es el contexto político. Y por contexto político, esto podría significar muchas cosas, pero una de ellas es el Gran Cortafuegos de China. Y el Gran Cortafuegos de China es un conjunto de diferentes medidas a nivel de red para controlar y cambiar la forma en que se accede a internet en China.

Y una de las cosas que emplean es la inspección profunda de paquetes, que básicamente analiza de manera no pública la forma en que tus botellas, por ejemplo, podrían cargarse. Botellas de CSS, botellas de JS, imágenes, y demás. Y también hay un montón de investigaciones interesantes que muestran cómo muchas páginas, muchas páginas populares, como grandes sitios web, solo un porcentaje de esto se entrega en China. Por último, pero no menos importante, otra cosa que también podría estar filtrando a las personas de nuestros sitios web es la accesibilidad.

eso incluye entradas retrasadas o la pérdida de enfoque porque se está cargando más JavaScript y está causando cambios de diseño y demás. Además, muchas de las otras malas prácticas de rendimiento que tenemos que impactan el rendimiento regular impactarán la accesibilidad, como tener tamaños de DOM grandes con mucho anidamiento y miles y miles de nodos, o incluso reflows, que también son otra mala práctica que a veces causamos mucho. Esto también impacta mucho a los lectores de pantalla. Además, la falta de métricas específicas sobre accesibilidad, por lo que es aún más difícil medir.

Para concluir sobre accesibilidad, me encanta esta cita de Marco Reze. Solía trabajar durante muchos años en accesibilidad y rendimiento e intersectando eso en Firefox. Y él dijo, reducir el número de milisegundos que tarda un lector de pantalla en comenzar a hablar después de presionar una tecla de aproximadamente 100 a 140 a 100 aquí, o de 120 a 100 allá. No importa mucho en una máquina rápida. Pero en una máquina lenta, eso es de aproximadamente 250 a 250, o de 250 a 200 o 190. Así que esto es, nuevamente, parte de nuestros usuarios que podríamos estar filtrando debido al rendimiento.

Considerando todo, vivimos en un mundo donde incluso la paciencia es algo local. Así que hay una investigación muy interesante que compara los umbrales de frustración en diferentes países. Y vas a ver que... Ya veo a algunas personas riendo. Vas a ver que países que hablan el mismo idioma e incluso están uno al lado del otro, como Estados Unidos y Canadá, tendrán umbrales de frustración muy, muy diferentes.

Así que, sí. La segunda cosa es cómo los usuarios juzgan nuestras aplicaciones. Para esto, tenemos la regla del pico-final y el efecto de posición serial. La regla del pico-final básicamente dice que las personas juzgarán una experiencia en gran medida basándose en cómo se sintieron en su pico y su final. Y el efecto de posición serial nos dice que las personas recordarán los primeros y últimos elementos de una serie como los mejores y los del medio como los peores. Y cómo esto se cruza con la web, básicamente la tasa de retención de tu sitio web podría estar influenciada por el mejor y peor rendimiento en las primeras y últimas páginas. Y tu tasa de conversión, por ejemplo, podría depender del mejor y peor rendimiento en las páginas antes de la conversión, o en este caso, el pico.

Por último, pero no menos importante, cómo percibimos el tiempo. Así que un poco de levantar la mano. ¿También sientes que el tiempo se acelera cada año? Parece que la Navidad y las vacaciones se acercan cada vez más rápido. Yo también. Y no estamos solos. Y en realidad hay una razón para eso. Y está realmente conectado con nuestro cerebro perdiendo su capacidad año tras año para procesar información a la velocidad que le llega. Así que simplemente está siendo bombardeado más y más. Así que la percepción del tiempo es súper complicada. Es tan complicada que es la razón por la cual tenemos espejos en los ascensores. Los ascensores no siempre tuvieron espejos. Pusieron espejos en los ascensores para que la gente no se quejara en los tiempos industriales de que los ascensores eran lentos y la gente dejó de quejarse.

Mi caso favorito sobre esto es en realidad los aeropuertos. Así que hubo este caso en los aeropuertos de Houston hace más de una década, donde básicamente la gente se quejaba de que tomaba mucho tiempo recoger las maletas de las cintas de equipaje y optimizaron más y más hasta que llegó a un punto en que la gente esperaba ocho minutos y seguían quejándose. Y luego la administración del aeropuerto se dio cuenta de que la gente caminaba desde las puertas hasta la cinta en un minuto y esperaba siete minutos. Así que la solución fue alejar las cintas para que la gente tuviera que caminar durante seis a siete minutos. ¿Y adivina qué? Las quejas bajaron a casi cero. Así que la percepción del tiempo es tan complicada y es lo mismo en las computadoras. Desde el 68 hemos estado tratando de encontrar esos números mágicos para optimizar cómo percibimos el tiempo. Y en el 68 teníamos estos números mágicos. Y luego en el 93 Jacob Nielsen encontró otro conjunto que iba de 0.1 segundo, 1 segundo y 10 segundos. Después de 10, simplemente perdimos el tren de atención. Luego, años después en Chrome, obtuvimos lo que se llama el modelo real donde teníamos incluso diferentes umbrales para la frustración.

Y por cierto, vas a tener estas diapositivas, así que tendrás la oportunidad de. Pero la cosa es que este tipo de cosas que provienen de la investigación centrada en UX impactan eso. Por ejemplo, ¿quién aquí ha usado la API de prueba larga en Performance Observer? ¿Quién aquí ha perfilado una aplicación y vio un montón de puntos rojos y etcétera? Sí, más manos. Así que esos puntos rojos señalan pruebas que toman más de 50 milisegundos. Sus 50 no es un número mágico aquí. Proviene de la investigación alrededor del modelo real. Así que este tipo de investigación realmente impacta la forma en que las APIs que usamos funcionan. Y es lo mismo para React. Estamos en una conferencia de React. Revisa la fuente del programador y verás diferentes umbrales también. Que van desde 250 milisegundos hasta 10 segundos y básicamente definen cómo React va a programar diferentes tareas. Incluso para React concurrente, donde tenemos este número mágico de cinco milisegundos para volver al hilo principal, es lo mismo. En este caso, es porque es lo que cabe en un solo cuadro incluso en dispositivos de 120 FPS. Así que se trata de encontrar el punto óptimo para la percepción del tiempo y nosotros los humanos. Porque al final del día, queremos evitar la frustración.

Y porque la frustración puede coincidir con muchas cosas como el estrés. Por ejemplo, descubrieron que básicamente en conexiones lentas, los participantes de una investigación tuvieron que concentrarse un 50% más usando sitios web a través de una conexión más lenta. La frustración también puede llevar a la ansiedad cuando descubren que usando esos retrasos... Estaban falsamente retrasados. Pero usar esas páginas web lentas provocó un aumento del 38% en la frecuencia cardíaca, lo cual era comparable a ver una película de terror solo. Y la frustración también puede llevar a la ira cuando descubren que al menos una vez en sus vidas, el 40% de los británicos se había vuelto físicamente violento hacia sus computadoras. O cuando lo mismo, no sobre los británicos, sino sobre dispositivos y volverse violentos, cuando tuvieron esta investigación sobre páginas lentas y móviles y el 4% de las personas incluso arrojaron sus teléfonos porque estaban frustrados con sitios web lentos. Así que es obvio que la frustración es algo malo y queremos evitarlo. Pero si queremos evitarlo, necesitamos poder medirlo. Y podemos medirlo preguntando a los usuarios, por supuesto. Y Wikipedia, incluso nosotros, hicieron una investigación muy interesante sobre preguntar a los usuarios y sobre cómo se sentían usando Wikipedia y etcétera. Pero en general, es difícil diseñar como una encuesta o un pop-over cualquier cosa de una manera que las personas elijan responder lo que estás haciendo, lo que estás preguntando. Así que terminas requiriendo algún compromiso activo de los usuarios. Además, eres propenso a lo que se llama sesgo de selección y efectos de observación, que son estos dos. Así que el sesgo de selección básicamente ocurre cuando no logras una adecuada aleatorización en el muestreo.

Y cómo los efectos externos es mi favorito, donde básicamente las personas reaccionan de manera diferente a la misma cosa, solo porque saben que están siendo observadas. Hablando de observar, otra cosa que podemos hacer es lo que se llama computación afectiva. Hasta hace poco, no tenía idea de que había incluso un área específica de la informática llamada computación afectiva. Que básicamente se trata de entender las computadoras y las emociones y todo eso. Pero sí, y se trata de cosas como adjuntar medidas de frecuencia cardíaca o análisis de ancho de banda y todo eso. E incluso hay bibliotecas en GitHub para rastrear los ojos de tus usuarios mientras navegan por tu página.

Pero seamos honestos. No vamos a hacer esto de manera regular. Así que otra cosa que podemos hacer es lo que se llama análisis de comportamiento. Y hay muchas soluciones llamadas DxA por ahí para esto, y probablemente hayas visto algunas de ellas. Así que no necesariamente tienes que implementar desde cero todo lo que voy a decir aquí. Pero una de las cosas son los clics de rabia. Así que los clics de rabia básicamente ocurren cuando los usuarios tocan rápidamente o cuando algo no está funcionando. Sí, es mejor mostrarlo de este lado. Así que siempre hemos estado en este lugar. A veces es porque el hilo principal está bloqueado o a veces es solo porque la solicitud de red está en curso y no hay retroalimentación visual. Así que podemos rastrear los clics de rabia.

También podemos rastrear otra cosa llamada desplazamiento aleatorio, que básicamente se define por un desplazamiento rápido a menudo a través de grandes fragmentos de tu página. Y eso indica que el usuario está buscando lo que sea el siguiente paso. Y esta es también la razón por la que tratamos de optimizar tanto lo que se llama contenido por encima del pliegue, ya sea a través de SSR o algo así. De todos modos, hay mucha investigación interesante que muestra cómo el desplazamiento y la atención están conectados y cómo puedes pensar en optimizarlo. Última cosa, cursor basura. Así que nuevamente, hay mucha investigación web que dice cuánto puedes leer de tus usuarios sobre sus emociones solo verificando cómo mueven sus ratones. Y el cursor basura se define básicamente por cubrir una gran distancia recorrida en un corto período de tiempo sin una clara intencionalidad. Y básicamente indica que el usuario está impaciente, que tiene algunas dudas o alguna dificultad o incluso ansiedad. Y las posibles razones podrían ser, en primer lugar, sí, el rendimiento.

Básicamente, si hacen esto, cuando están esperando que un video se almacene en búfer o cuando están esperando que la siguiente ruta de tu SPH se cargue o algo así, pero también puede indicar una alta carga cognitiva, por ejemplo, cuando están involucrados en una actividad de escritura o redacción de contenido o llenando un formulario para papeleo. Todo depende del contexto de tu aplicación.

Unas últimas cosas. Es muy importante que seamos capaces de establecer correlaciones. Y eso incluye, por ejemplo, todos los core web vitals que estamos midiendo. Así que es bueno que obtengamos buenos puntajes de Lighthouse, por ejemplo, buen REM para core web vitals, pero es aún mejor si puedes correlacionarlo.

Por ejemplo, hay investigaciones que correlacionan un buen LCP con la tasa de retención o buenos cambios de diseño acumulativos con las tasas de recarga o buenos IMPs, la nueva métrica, con las tasas de clics de rabia. Así que establecer correlaciones es importante. Encuentra métricas que representen cosas que impactan en la UX. Como para algunas aplicaciones, el tiempo hasta que los desplazamientos comienzan a funcionar o la aplicación comienza a responder a los clics podría ser la clave. O para otras aplicaciones, podría ser el tiempo hasta que los videos y animaciones más significativos se ejecuten.

O incluso si el cumplimiento es algo tan importante en GDPR y etcétera, tu métrica clave podría ser el tiempo hasta que aparezca tu banner de cookies. Por eso me encanta este ejemplo de Vercel donde mencionaron que para V0 y chatbots en general, la métrica clave que descubrieron fue el tiempo hasta el enfoque de entrada porque es una aplicación de chat. Y están optimizando en este caso con pre-renderizado parcial.

Y por último, pero no menos importante, establecer conexión con los resultados empresariales. Por eso me encantan sitios web como este. Se llama Web Performance Optimization Stats, y está lleno de casos que datan de décadas sobre cómo esas métricas técnicas realmente impactaron a los usuarios y las métricas empresariales. Y web.dev también está lleno de casos como, hey, optimizamos esto y reducimos las tasas de rebote o optimizamos aquello y aumentamos las ventas totales. Esto es lo que importa.

Wow. Sé que esto fue mucho. Espero haber logrado de alguna manera mostrar cómo el rendimiento web puede conectarse con la economía, la psicología, la neurociencia, los análisis empresariales y todo eso. Antes de comenzar la sesión de preguntas y respuestas, vamos a tener tiempo para algunas preguntas. El cliché es cierto. No puedes arreglar lo que no puedes medir. Y es obvio para mucha gente, pero siempre hemos estado en este lugar donde vemos una nueva tecnología en una conferencia como esta, vamos al trabajo y decimos, necesitamos empezar a usar esto lo antes posible. Así que midamos antes. Y eso es parte de construir la imagen completa.

Por eso es importante que siempre intentes correlacionar los análisis empresariales con esas métricas contextuales, con los resultados empresariales para finalmente contar la historia completa de tu aplicación.

La tercera cosa que escuché en una charla de Tim Cadillac, y no podría estar más de acuerdo, es cosas como Core App Vitals, son un mejor punto de partida que una línea de meta. Porque si intentamos hacer de ellos nuestro objetivo final, tendemos a empezar a manipularlos y todo este tipo de cosas, y eso no es ideal.

La cuarta cosa es que es bueno cuando nuestras aplicaciones y nosotros como desarrolladores incorporamos en nuestras aplicaciones, reconociendo que no cumplimos con las expectativas de los usuarios. Cosas como lo que Windows dice, hey, está tardando más, pero vamos a llegar allí, etcétera. Hay una investigación interesante sobre cómo las computadoras y aplicaciones que se disculpan pueden aliviar la percepción de un mal rendimiento. Así que también piénsalo. Y último punto, probablemente haya un caso empresarial como trato de mostrar a lo largo de mi charla para hacer tu aplicación más rápida. Pero como vimos, especialmente en el sesgo de supervivencia, muchas veces el rendimiento es más que solo negocios como siempre.

en el sesgo de supervivencia, muchas veces el rendimiento es más que solo negocios como siempre. Por eso me encanta esta parte en MDN, cuando dicen que en cierto sentido el rendimiento web puede considerarse un subconjunto de la accesibilidad web. Y última captura de pantalla, la conclusión del post que mostré hace 20 minutos atrás, el estudio de caso de YouTube de 2012, decía, muchos de nosotros tenemos la suerte de vivir en regiones de alta banda ancha, pero todavía hay grandes porciones del mundo que no. Y esto fue en 2012, pero sigue siendo cierto. Así que gracias a todos por tenerme aquí. Pueden encontrar las diapositivas y muchas cosas en este código QR. Todas mis otras charlas sobre los internos de herramientas están allí. Y encuéntrame en el Q&A o en la conferencia. Fue un placer. Muchas gracias. Gran charla, Mateus. Además, mi parte favorita fue el hecho de que Alemania tiene la menor paciencia de todos los lugares. Por favor, ponte tu sombrero de fiesta. Es el décimo aniversario de Git Nation. Y luego podemos pasar a las preguntas. No dije eso. Fue tu conclusión sobre Alemania. Bueno, había estadísticas. De acuerdo. Hablemos de esto porque me encanta el hecho de que no solo hablaste de las métricas, sino que hablaste de la humanidad detrás de dichas métricas. Así que esta primera pregunta viene de Nico JS, que es sobre estas son medidas asombrosas. ¿Hay alguna biblioteca para ayudar a automatizar la medición de estas en lugar de tener que construir como medir estas métricas por sí mismo? ¿Hay alguna buena biblioteca para eso? Sí, así que pasé realmente, realmente rápido por esa diapositiva. Pero en realidad, todas esas, esto se llama principalmente DXA o análisis de experiencia digital. Así que hay un montón de empresas que mi empresa también hace eso. Pero hay un montón de empresas por ahí. Vas a ver como full story y demás que ofrecerán no solo esos clics de rabia, sino que mencionarán que te ayudarán a detectar esos clics. Te ayudarán a detectar todas las cosas de mouse y desplazamiento de las que hablo. Te ayudarán a detectar indicadores de frustración que no están necesariamente conectados al rendimiento como algo llamado clics hacia atrás. Eso es cuando navegas varias veces a la página anterior. Así que las bibliotecas DXA en general tienden a ayudar.

Y a veces esto es digno de saber, porque a veces no todas las empresas aprobarán presupuestos para contratar a terceros para medir este tipo de cosas. Así que a veces puedes encontrar un subconjunto de ellos que deseas y construirlos en un par de cientos de líneas de JavaScript y simplemente enviarte algún servicio RUM. Eso es bueno. Eso es bueno.

Y el último, cuando pensamos en obtener estadísticas, obtener información, no sé si esto está específicamente dirigido sobre el rage, el rage clicking, o la paciencia, pero a veces esto puede estar sesgado en la información. E incluso cuando pensamos en estos, como aceleraciones, seguimiento del mouse, puede haber sesgo porque ciertas cosas suceden en una página. ¿Cómo puedes identificar el sesgo que podría estar causando algo y algo siendo como ruido frente a ser una señal? Sí. Así que este es súper específico. Tal vez el autor de la pregunta estaba hablando de nuestros sesgos como desarrolladores también. Posible sesgo que influye. Oh sí, sí. Así que creo que, en primer lugar, si estás hablando del sesgo de los desarrolladores, entonces solo una cosa autoconsciente y decir, está bien, ¿podría estar mi data desordenada por la forma en que la estoy analizando? Y por eso es importante que sepamos todas las palabras clave. Cuando se trata de nuestros usuarios, es, sí, siempre es complicado y es un gran, depende. Como una de las cosas que te mostré, podría ser sobre el rendimiento, pero también podría ser sobre tus páginas, simplemente confusas. Hay una alta carga cognitiva. Así que para este, me quedaré con un gran, depende y sí, intenta ver dónde tiene sentido, analiza con el tiempo e intenta limpiar. Bueno, depende. Y puedes encontrar la respuesta completa a esa pregunta reuniéndote con Mateus en las salas de oradores.

Sé que tienes tus auriculares puestos, pero amigos, ¿podemos darle a Mateus un gran aplauso? Muchas gracias. Gracias, hombre.