El coste que no se mide

Los cuatro capítulos anteriores han tratado la latencia como una magnitud: algo que se descompone, se acota y se esconde. Este trata su efecto, que es de otra clase. Una espera no solo consume tiempo: modifica lo que la persona se atreve a hacer con la herramienta. Ese segundo efecto es mucho mayor que el primero, y es también el único que ningún panel de métricas puede registrar, por razones que no son de instrumentación sino de lógica.

El impuesto por interacción

La latencia no se cobra una vez: se cobra cada vez. Su coste agregado no es su magnitud sino el producto de su magnitud por su frecuencia, y ese producto se comporta de forma contraintuitiva.

Una espera larga en una acción rara —exportar un informe, cerrar un ejercicio contable— es visible, se comenta y se prioriza. Una espera modesta en una acción que se repite cientos de veces por sesión —abrir un elemento, filtrar, cambiar de pestaña, editar una celda— es invisible individualmente y, en agregado, mucho mayor. La atención de los equipos se dirige hacia lo visible, es decir, hacia el sumando pequeño.

// El coste agregado es el producto, no la magnitud
const coste = (esperaMs, vecesPorSesion) => esperaMs * vecesPorSesion;

coste(3000, 2);    // la accion lenta y rara: se ve, se comenta, se prioriza
coste(180, 400);   // la accion rapida y constante: nadie la menciona nunca

Pero el agregado temporal, con ser real, sigue siendo la parte menos importante del argumento. Lo importante ocurre antes de que el tiempo se sume.

Lo que haces cambia cuando la respuesta es inmediata

Cuando una acción responde al instante, es barata de intentar. Cuando cuesta una espera, deja de ser barata, y la persona empieza a hacer algo que no aparece en ningún registro: decidir si merece la pena.

Esa deliberación cambia la forma del trabajo. Con respuesta inmediata, el usuario explora: prueba una opción, la deshace, prueba otra, compara. La herramienta funciona como una extensión del pensamiento, y el pensamiento avanza por tanteo. Con respuesta lenta, el usuario planifica: agrupa cambios, evita deshacer, escoge una sola vía y la sigue aunque dude. La herramienta pasa de ser un instrumento de exploración a ser un formulario que se rellena con cuidado porque enviarlo cuesta.

Y hay un tercer mecanismo, el más silencioso de todos: la adaptación. Pasadas unas sesiones, el usuario deja de experimentar la latencia como un evento y la incorpora como una propiedad del mundo. Ya no piensa “esto tarda”: piensa “esto se hace así, agrupando cambios y revisando antes de guardar”. A partir de ese momento, ni siquiera un cuestionario de satisfacción detectará el problema, porque la persona no está insatisfecha con una herramienta lenta; está satisfecha con una herramienta cuyo uso ya ha reducido para que la lentitud no le estorbe.

Hay un segundo mecanismo, complementario y bien documentado en la literatura de interacción: la continuidad de la atención. Una espera lo bastante larga rompe el hilo de lo que la persona estaba haciendo, y entonces el coste real no es la espera sino la reconstrucción del contexto al volver. Ese coste de reentrada puede exceder con mucho la duración de la propia espera, y es estrictamente invisible: ocurre dentro de la cabeza del usuario, después de que el sistema haya respondido y haya registrado un éxito.

flowchart TB
A[Respuesta lenta] --> B[Intentar cuesta]
B --> C[El usuario deja de explorar]
C --> D[Menos interacciones por sesion]
D --> E[Menos peticiones al servidor]
E --> F[El panel muestra menos carga]
F --> G[Parece que el sistema va bien]
style A fill:#f38ba8,color:#11111b
style G fill:#f9e2af,color:#11111b

Sigue el bucle hasta el final, porque contiene la trampa entera. La conducta que la latencia induce —usar menos la herramienta— produce en el panel exactamente la misma señal que produciría una mejora: menos carga, menos peticiones, menos errores.

Por qué el panel no lo ve

Que la telemetría convencional no capture este coste no es un descuido corregible con más instrumentación. Es una consecuencia de cómo están definidas esas métricas, y conviene enumerar las razones porque cada una es independiente.

La primera es de frontera: las métricas de servidor se definen entre la llegada de la petición y la salida de la respuesta, así que excluyen por construcción el trabajo del cliente, el renderizado y el enlace del usuario, que es donde vive buena parte de la espera percibida.

La segunda es de unidad de análisis: los percentiles se calculan por petición, pero la gente vive sesiones. Si asumes independencia entre peticiones, la probabilidad de que una sesión con muchas peticiones contenga al menos una lenta crece muy deprisa con el número de peticiones.

// Probabilidad de que una sesion contenga al menos una peticion lenta
// suponiendo independencia y una tasa p de peticiones lentas
const alMenosUnaLenta = (p, peticiones) => 1 - (1 - p) ** peticiones;

alMenosUnaLenta(0.01, 20);   // una sesion corta: mas o menos una de cinco
alMenosUnaLenta(0.01, 200);  // una sesion de trabajo: casi con certeza

Con una tasa de peticiones lentas del uno por ciento —lo que un panel presentaría como un percentil noventa y nueve saludable— una sesión larga de trabajo real atraviesa el caso lento con práctica certeza. El percentil describe bien las peticiones y describe muy mal a las personas.

La tercera es de supervivencia: quien abandona deja de generar tráfico. La población que el panel observa está sesgada hacia quienes toleraron la latencia y hacia las condiciones de red en las que la aplicación funcionaba. Los peores casos se autoexcluyen de la muestra.

La cuarta es de ausencia: la acción que no se intentó no emite ningún evento. No existe, ni existirá jamás, una métrica llamada “interacciones que el usuario decidió no hacer porque iban a tardar”. Es el coste principal y es literalmente inobservable desde el servidor.

Nótese que las cuatro razones son de distinta naturaleza y ninguna se arregla con la solución de la otra. La primera se corrige moviendo la frontera de medición al cliente. La segunda, cambiando la unidad de análisis de petición a sesión. La tercera exige razonar sobre quién falta en la muestra, no sobre quién está. Y la cuarta no se corrige en absoluto: es un límite lógico de lo que un registro de sucesos puede contener.

Medir lo que no ocurrió

No se puede instrumentar directamente una ausencia, pero sí se pueden buscar sus sombras. Cuatro familias de señales se acercan más que cualquier panel de servidor.

Ninguna de las cuatro es una medida limpia y todas admiten interpretaciones alternativas. Su valor no es demostrativo sino correctivo: existen para impedir que la ausencia de señal se confunda con la ausencia de problema.

Hay además una fuente de evidencia que suele estar disponible y casi nunca se explota: la variación natural. Tus usuarios ya están repartidos por distintas distancias y distintas calidades de enlace, así que la población contiene un experimento que nadie diseñó. Comparar la conducta —no la satisfacción, la conducta— entre quienes están cerca del servicio y quienes están lejos aísla el efecto de la latencia mejor que cualquier encuesta, precisamente porque ninguno de los dos grupos sabe que forma parte de una comparación.

// La variacion natural ya existe: solo hay que agruparla
const porDistancia = agrupar(sesiones, (s) => s.regionDelUsuario);
const conducta = (grupo) => ({
  interaccionesPorMinuto: media(grupo, 'interacciones'),
  tasaDeDeshacer: media(grupo, 'deshacer'),
  abandonoEnEspera: media(grupo, 'abandonos'),
});