Blog

Tu usuario no vive en el servidor: Midiendo la experiencia real

Actualizado: 30 de noviembre de 2025 • Federico Miranda

En el artículo anterior hablé sobre el rol del Product Engineer y la importancia de entender el impacto de nuestro trabajo, incluso más allá del momento del release. Hoy voy a profundizar en el concepto de medición.

Por lo general, cuando hablamos de rendimiento, lo primero que se nos viene a la cabeza son los datos de rendimiento del backend. Pensamos en el uso de la CPU, la memoria, el tiempo de respuesta, las tasas de error y la latencia. Pero ¿qué pasa cuando todo eso está bien y los usuarios siguen sintiendo que la aplicación es lenta?

El problema es que el frontend no es tan fácil de medir, ya que estamos lejos de poder controlarlo al 100%. Nuestra aplicación va a correr en distintos dispositivos, con distintas conexiones y en condiciones impredecibles.

Por esto no podemos confiarnos en las métricas del servidor; no nos alcanzan. Necesitamos medir la experiencia de usuario.

Web vitals

Google propone los Web Vitals como una guía unificada de señales para medir la calidad de nuestra web. Específicamente, existe un subconjunto llamado Core Web Vitals, diseñado para cuantificar la experiencia directa de los usuarios.

Estos pueden variar con el tiempo, pero hoy el foco está puesto en tres pilares: carga, interactividad y estabilidad visual. Es súper importante que sepamos traducir el dato numérico a la sensación del usuario:

  • Largest Contentful Paint (LCP): Mide la carga. Se enfoca en ver cuánto tiempo tarda en aparecer el contenido más grande visible en pantalla. Para considerar que la experiencia es buena, debe ocurrir en menos de 2.5 segundos.
  • Interaction to Next Paint (INP): Mide la interactividad. Se enfoca en ver qué pasa cuando el usuario hace un click. ¿La página reacciona inmediatamente o se congela? Debería ser menor a 200ms.
  • Cumulative Layout Shift (CLS): Mide la estabilidad visual. Mientras carga la página, ¿los elementos se mueven de forma inesperada? Esta métrica debe ser menor a 0.1.

Algo crucial es la forma en que medimos. Podemos hacerlo desde nuestras Chrome DevTools, pero esto se conoce como Lab Data: un escenario idealista. Si tenemos la última MacBook Pro y fibra óptica, el dato no será representativo.

Por eso, es interesante incluir la librería web-vitals en nuestro proyecto para reportar métricas de usuarios reales (Field Data) y contar con un panorama real.

Error Boundaries

En React, cuando ocurre un error durante el renderizado, la librería desmonta por defecto toda la interfaz. Esto da como resultado una pantalla en blanco.

Los Error Boundaries son componentes que atrapan esos errores y reemplazan ese pantallazo blanco por una interfaz alternativa que nosotros decidamos (“Ups, algo salió mal”).

Es importante contar con estas alternativas para comunicar al usuario lo que ocurre, pero nuestro trabajo no termina ahí. Si el cartel de error aparece 100 veces al día, indica un problema profundo, aunque la app no se haya “roto”. Necesitamos medir la frecuencia de activación de estos boundaries para entender la salud real de la aplicación.

Cuantificar la frustración

Hay un escenario en el que los Web Vitals se ven bien y no hay errores de código, pero el usuario sigue descontento. ¿Qué pasa ahí?

Existe un campo muy interesante para medir la frustración mediante el comportamiento:

  • Rage Clicks: Ocurre cuando el usuario clickea rápido y muchas veces sobre un mismo elemento. Señal de que la UI no da feedback, es confusa o no responde.
  • Dead Clicks: El usuario hace click sobre algo que parece interactivo, pero no hace nada. Suele ser un problema de diseño.
  • Error Clicks: Un click que lanza un error inmediato de JavaScript.

Herramientas como PostHog, Sentry o LogRocket nos permiten visualizarlo mediante Session Replays o Heatmaps. Ver a un usuario frustrado en una grabación vale más que mil logs.

Performance percibida

Quizás la estrategia más importante de todas es el uso de la psicología. La percepción de fluidez es más importante que la velocidad real.

El ejemplo clásico es el del ascensor. En el pasado, la gente se quejaba de que eran lentos. La solución de ingeniería hubiera sido invertir en motores más rápidos (costoso e ineficiente). La solución de producto consistió en instalar espejos.

La gente empezó a usar el tiempo para acomodarse la ropa o para mirarse. El tiempo de viaje era el mismo, pero la percepción cambió: el viaje se sentía más corto.

En el frontend pasa lo mismo:

  • Un spinner en una pantalla blanca hace que 500ms parezcan una hora.
  • Un Skeleton animado hace que el usuario sienta progreso y la espera disminuya.

Un ejemplo moderno son los LLMs (como ChatGPT). En lugar de un simple “Cargando…”, muestran mensajes como “Analizando…”, “Buscando…” y “Generando…”. Dan feedback constante para generar sensación de avance.

Como ingenieros, tenemos herramientas para mejorar esto: Optimistic UI, Local-first, Background Sync. Temas en los que profundizaremos más adelante.

Conclusión

Para conocer el impacto de nuestro trabajo necesitamos medir la experiencia real, y eso requiere ver lo que hace el usuario. Si dominamos los Core Web Vitals, controlamos los errores y reducimos las frustraciones, tendremos una base sólida.

Pero eso no alcanza. Una app rápida y sin errores no es garantía de éxito. En el próximo artículo hablaré de las otras métricas: las de negocio. ¿Cómo medimos si lo que lanzamos a producción está aportando valor real?

Blog

Your User Doesn't Live on the Server: Measuring the Real Experience

Updated: November 30, 2025 • Federico Miranda

In the previous article, I discussed the role of the Product Engineer and the importance of understanding the impact of our work, even beyond the release moment. Today, I want to dive deeper into the concept of measurement.

Usually, when we talk about performance, the first thing that comes to mind is backend performance data. We think about CPU usage, memory, response time, error rates, and latency. But what happens when all of that looks green, yet users still feel the application is slow?

The problem is that the frontend isn’t as easy to measure because we don’t control it 100%. Our application will run on different devices, with different connections, and under unpredictable conditions.

That’s why we can’t rely solely on server metrics; they aren’t enough. We need to measure the user experience.

Web Vitals

Google proposes Web Vitals as a unified guide of signals to measure the quality of our web. Specifically, there is a subset called Core Web Vitals that quantifies the user experience.

These currently focus on three areas: loading, interactivity, and visual stability. Translating these numbers into user perception is crucial:

  • Largest Contentful Paint (LCP): Measures loading. It focuses on how long it takes for the largest visible content element to appear on the screen. To be considered a good experience, it must happen in under 2.5 seconds.
  • Interaction to Next Paint (INP): Measures interactivity. It focuses on what happens when the user clicks. Does the page react immediately, or does it freeze? It should be under *200ms.
  • Cumulative Layout Shift (CLS): Measures visual stability. As the page loads, do elements move unexpectedly? This metric must be under 0.1.

How we measure this is key. While we can get numbers from Chrome DevTools—known as Lab Data—these are based on ideal conditions. If you have a high-end computer and a fast connection, the results won’t reflect the typical user’s experience.

That is why it’s worth including the web-vitals library in our project to report metrics from real users (Field Data) and get a realistic overview.

Error Boundaries

In React, when an error occurs during rendering, the library unmounts the entire interface by default. This results in a white screen.

Error Boundaries are components that catch errors and replace the white screen with an alternative interface we decide on (“Oops, something went wrong”).

Clearly communicating to users is only the start. If an error message shows up 100 times a day, that’s a sign of a deeper issue, even if the app hasn’t crashed. We must monitor how often these boundaries activate to truly assess application health.

Quantifying Frustration

There is a scenario where Web Vitals look good, and there are no code errors, but the user is still unhappy. What’s happening there?

There is a very interesting field for measuring frustration through behavior:

  • Rage Clicks: User rapidly clicks the same UI element in frustration, signaling that the interface lacks feedback, is unclear, or is unresponsive.
  • Dead Clicks: These happen when a user clicks on something that appears interactive, but nothing occurs. This typically points to a design issue. Measuring dead clicks tells us which interface elements mislead users or fail to function.
  • Error Clicks: A click that triggers an immediate JavaScript error.

Tools like PostHog, Sentry, or LogRocket show this through Session Replays or Heatmaps. Watching a frustrated user’s session tells you more than a thousand logs ever could.

Perceived Performance

The most important strategy is psychology: perceived fluidity outweighs real speed.

The classic example is the elevator. People used to complain about slow rides. Instead of faster motors (costly and inefficient), mirrors were installed. Riders spent time looking at themselves, making the ride feel shorter even though the duration remained the same.

On the frontend, perceived speed works the same: a spinner on a white screen makes 500ms feel endless, while an animated Skeleton reassures users and makes the wait feel shorter.

  • An animated Skeleton makes the user feel progress and reduces wait time.

Modern LLMs (like ChatGPT) use progress messages—“Analyzing…”, “Searching…”, “Generating…” — instead of just “Loading…” to give users a sense of steady progress.

As engineers, we have tools to improve this: *Optimistic UI, Local-first, and Background Sync—topics we will explore further later.

Conclusion

To understand the impact of our work, we need to measure the real experience, which requires observing users in action. If we master Core Web Vitals, control errors, and reduce frustrations, we will have a solid foundation.

But that’s not enough. A fast and error-free app is no guarantee of success. In the next article, I will talk about the other metrics: business metrics. How do we measure whether what we ship to production provides real value?