Los patrones que lo esconden

La industria ha desarrollado un repertorio notable de técnicas para que una espera se sienta menos larga. Son buenas técnicas y funcionan de verdad, pero casi todas operan sobre la percepción del tiempo, no sobre el tiempo. Distinguir cuáles esconden la latencia y cuál la elimina es la diferencia entre maquillar un problema y resolverlo, y ambas cosas son legítimas siempre que sepas cuál estás haciendo.

El repertorio de la espera

Cuando un sistema no puede responder de inmediato, tiene tres respuestas posibles ante el usuario: no decir nada, decir que está trabajando, o fingir que ya ha terminado.

No decir nada es la peor: una interfaz congelada es indistinguible de una interfaz rota, y el usuario reacciona repitiendo el gesto, lo cual empeora la carga. Decir que está trabajando es el territorio del indicador de progreso, y su valor es real: un cuerpo abundante de trabajo en interacción persona-ordenador muestra que la retroalimentación cambia la duración percibida de una espera, incluso cuando la duración medida es idéntica. Fingir que ya ha terminado es el territorio del optimismo, y es el único de los tres que altera la estructura del problema.

flowchart TB
A[El usuario actua] --> B{Hay respuesta inmediata}
B -->|No, y no se avisa| C[Interfaz congelada]
B -->|No, pero se avisa| D[Spinner o esqueleto]
B -->|Si, aplicada en local| E[Actualizacion optimista]
C --> F[Espera sufrida]
D --> G[Espera gestionada]
E --> H[Espera eliminada del camino critico]
style F fill:#f38ba8,color:#11111b
style G fill:#f9e2af,color:#11111b
style H fill:#a6e3a1,color:#11111b

Fíjate en la etiqueta del último nodo. No dice que la espera desaparezca: dice que sale del camino crítico. El viaje al servidor sigue ocurriendo; lo que cambia es que el usuario ya no está dentro de él.

El indicador y el esqueleto

Un indicador de progreso hace dos afirmaciones. La primera es “he recibido tu gesto”, y es la más valiosa, porque elimina la ambigüedad entre lentitud y avería. La segunda es “esto va a tardar”, y es una confesión: el sistema admite que el usuario debe detenerse.

Los indicadores indeterminados —una rueda que gira sin fin— cumplen la primera afirmación pero no la segunda, y por eso su utilidad decae con el tiempo: pasado cierto punto dejan de informar y se vuelven un símbolo de impotencia. Los determinados, que muestran cuánto falta, son mejores cuando existe una fracción honesta que mostrar, y peores cuando esa fracción es inventada.

El esqueleto va un paso más allá: en lugar de anunciar que falta contenido, dibuja su forma anticipada. Su ventaja no es solo estética. Al reservar el espacio, evita el desplazamiento del contenido cuando los datos llegan, y ese desplazamiento es una de las agresiones más caras de una interfaz, porque invalida la posición que el usuario ya había memorizado.

Hay además una paradoja de umbral que casi todo el mundo descubre tarde. Si la respuesta llega muy rápido, mostrar el indicador es peor que no mostrarlo: aparece y desaparece en un parpadeo, y ese destello se percibe como un defecto, no como información. Pero si la respuesta es lenta, no mostrarlo es intolerable. La solución habitual —retrasar el indicador un instante y mostrarlo solo si la operación sigue viva— es correcta, y también instructiva, porque revela que el indicador no informa sobre la operación sino sobre una hipótesis acerca de su duración.

// El indicador no informa de la operacion: informa de una sospecha
let visible = false;
const t = setTimeout(() => { visible = true; pintarIndicador(); }, umbral);

operacion().finally(() => {
  clearTimeout(t);              // si llego antes del umbral, nunca se vio
  if (visible) ocultarIndicador();
});

La actualización optimista

La actualización optimista invierte el orden convencional. En lugar de pedir, esperar y luego reflejar, la interfaz aplica el efecto localmente de inmediato, envía la petición en segundo plano y reconcilia cuando llega la respuesta.

// Aplicar primero, confirmar despues
function marcarHecha(tarea) {
  const anterior = clonar(estado);            // guarda para poder revertir
  aplicarEnLocal(estado, { id: tarea.id, hecha: true });
  pintar(estado);                             // el usuario ya lo ve

  enviar({ tipo: 'marcarHecha', id: tarea.id })
    .then((confirmado) => reconciliar(estado, confirmado))
    .catch(() => {
      estado = anterior;                      // deuda: hay que revertir
      pintar(estado);
      avisarDelFallo(tarea);
    });
}

Este patrón es, estructuralmente, una arquitectura local-first reducida a su mínima expresión. Hay una réplica local del estado, hay una escritura que se aplica sin coordinación, hay un envío asíncrono y hay una política de reconciliación. La política, eso sí, es primitiva: gana el servidor y, si rechaza, se revierte.

Y ahí aparece la deuda. Revertir es aceptable cuando el rechazo es raro y el usuario sigue mirando; es terrible cuando el rechazo es frecuente o llega tarde, porque para entonces la persona ya ha construido sobre una realidad falsa. Además, el estado revertido puede haber sido usado como base de otras acciones, y deshacer una cadena es mucho más difícil que deshacer un paso.

El problema se agrava en cuanto hay más de una operación en vuelo, que es lo normal en cuanto el patrón funciona bien. Dos peticiones enviadas en orden pueden completarse en orden inverso, así que aplicar las respuestas conforme llegan puede revertir un cambio posterior con el resultado de uno anterior. La solución exige llevar la cuenta de qué operaciones locales están pendientes y reconstruir el estado visible como la última verdad confirmada más las operaciones aún no resueltas, en orden. Quien haya escrito ese bucle habrá notado la sensación familiar: acaba de implementar, a mano, un registro de operaciones con reordenación causal.

Esconder frente a eliminar

Con esto podemos ordenar el repertorio en dos familias con propiedades muy distintas.

La última tarjeta contiene la prueba decisiva. Un patrón que esconde la latencia depende de que la respuesta acabe llegando; si no llega, el disfraz cae y aparece la espera desnuda. Un patrón que elimina la latencia del camino crítico no depende de eso: la interacción ya se completó antes de que la red importara.

Nada de esto convierte a la familia perceptual en un error. Ocultar es la respuesta correcta siempre que la espera sea genuinamente inevitable: una operación que solo el servidor puede resolver, un cómputo pesado, una transferencia grande. Lo que hay que evitar es el uso de la familia perceptual como sustituto de la arquitectónica, es decir, decorar una espera que existía únicamente porque alguien decidió, sin pensarlo, que ese dato viviría lejos.