Estados de carga y skeletons: cómo diseñar la espera para que parezca más rápida

En una reunión con el equipo de una plataforma de formación online, alguien comentó que los alumnos se quejaban de que la web «iba lentísima». Medimos los tiempos y la sorpresa fue general: la página de cursos tardaba alrededor de un segundo y medio en cargar, una cifra razonable. El problema era lo que se veía durante ese segundo y medio: una pantalla completamente en blanco con un pequeño círculo girando en el centro. Después, de golpe, aparecía todo y el pie de página daba un salto.

Cambiamos la espera, no la velocidad. La cabecera y el menú aparecían al instante, el listado de cursos mostraba sus tarjetas en gris con la forma exacta del contenido final, y las imágenes llegaban con un fundido suave sobre un fondo del color dominante. El tiempo real apenas varió. Las quejas sobre lentitud, en cambio, prácticamente desaparecieron.

La velocidad tiene dos caras: la que miden las herramientas y la que siente la persona. La primera se trabaja con ingeniería; la segunda, con diseño. En esta guía nos centramos en la segunda: qué indicador usar según la duración de la espera, cómo diseñar un buen skeleton, cómo usar interfaces optimistas y qué decir mientras se espera.

01Por qué la velocidad percibida importa tanto

Nuestra percepción del tiempo es muy elástica. Una espera con algo que mirar parece más corta que una espera en blanco. Una espera que avanza visiblemente se tolera mejor que una que no da pistas. Y una espera explicada («Estamos calculando tu presupuesto») se lleva mejor que una muda.

Hay tres umbrales clásicos que describen cómo vivimos los tiempos de respuesta. Proceden de los trabajos de Robert Miller en 1968 y de Card, Robertson y Mackinlay en 1991, y Jakob Nielsen los popularizó para la web:

Estos umbrales conviven con las métricas actuales de Google. El INP, que mide la respuesta a las interacciones, se considera bueno por debajo de 200 milisegundos; el LCP, que mide cuándo aparece el contenido principal, por debajo de 2,5 segundos. La parte técnica de esas métricas la tratamos en la guía para optimizar LCP, INP y CLS. Aquí nos ocupamos de lo que ve la persona mientras tanto.

02Qué indicador de carga usar en cada caso

No hay un indicador mejor que los demás; hay uno adecuado para cada tipo de espera. Esta es la guía rápida que usamos en el estudio:

1. 01Menos de unos 300 ms: nada. Mostrar un spinner que aparece y desaparece en un parpadeo inquieta más que ayuda. Lo correcto es esperar un instante antes de mostrar cualquier indicador.
2. 02Acción puntual de hasta unos segundos: indicador en el propio control. Al pulsar «Guardar», el botón muestra un pequeño spinner y se desactiva para evitar dobles envíos. La persona sabe exactamente qué está esperando.
3. 03Carga de una pantalla o bloque de contenido: skeleton. Listados, fichas, paneles, perfiles. La estructura se anticipa y el contenido la va rellenando.
4. 04Proceso largo y medible: barra de progreso determinada. Subir archivos, exportar un informe, procesar un pago con varios pasos. Si puedes estimar el tiempo, dilo.
5. 05Proceso muy largo: segundo plano. Generar un vídeo o importar miles de registros. La persona puede seguir trabajando y recibe un aviso cuando termina.

Spinner o barra de progreso

El spinner, o indicador indeterminado, dice «estoy trabajando» pero no dice cuánto falta. Para esperas breves es suficiente. La barra de progreso determinada dice cuánto falta, y eso cambia la experiencia: la persona puede decidir si espera o si va a por un café. Cuando el progreso real no es lineal, conviene que la barra avance de forma suave y no se quede clavada en el 99 %.

03Skeleton screens bien diseñados

El skeleton es una maqueta provisional de la pantalla: rectángulos donde irán las imágenes, líneas donde irán los textos, círculos donde irán los avatares. Su gran ventaja es que convierte la espera en una carga progresiva. La pantalla ya está ahí; solo falta que se llene.

Qué hace que un skeleton funcione

• →Refleja la estructura real. Mismo número aproximado de tarjetas, mismas proporciones, misma disposición. Un skeleton genérico que no se parece al resultado final desorienta.
• →Ocupa el mismo espacio que el contenido final. Es la clave para que la página no salte cuando llega la información. Google mide esos saltos con el CLS, que se considera bueno por debajo de 0,1.
• →Es discreto. Grises suaves, sin contraste fuerte, adaptados al modo oscuro si lo hay. El protagonismo es del contenido que viene.
• →Muestra lo que ya se sabe. Si el título de la sección, los filtros o la cabecera no dependen de la carga, aparecen ya con su contenido real. Solo lo desconocido va en gris.
• →Tiene un movimiento sutil o ninguno. Un brillo que recorre los bloques lentamente indica que algo está pasando. Y quien ha pedido a su sistema reducir el movimiento ve el skeleton quieto.

Un skeleton en CSS

Este es el tipo de base que usamos en nuestros proyectos: el bloque reserva su espacio con aspect-ratio, el brillo se desactiva si la persona prefiere menos movimiento y el contenedor anuncia a los lectores de pantalla que está cargando.

.skeleton {
  background: var(--skeleton-base, #e9e7e3);
  border-radius: 8px;
  position: relative;
  overflow: hidden;
}
.skeleton--image { aspect-ratio: 4 / 3; }
.skeleton--line  { height: 0.9em; margin-block: 0.4em; }
.skeleton--line:last-child { width: 60%; }
.skeleton::after {
  content: "";
  position: absolute;
  inset: 0;
  transform: translateX(-100%);
  background: linear-gradient(90deg, transparent, rgb(255 255 255 / 0.5), transparent);
  animation: shimmer 1.6s ease-in-out infinite;
}
@keyframes shimmer { to { transform: translateX(100%); } }
@media (prefers-reduced-motion: reduce) {
  .skeleton::after { animation: none; display: none; }
}

En el HTML, el contenedor que se está cargando lleva aria-busy="true" mientras dura la espera, y se retira cuando llega el contenido. Los bloques grises en sí no aportan nada a un lector de pantalla, así que se ocultan con aria-hidden="true".

Imágenes que llegan sin sobresaltos

Las imágenes suelen ser lo último en llegar. Tres técnicas ayudan mucho: reservar su espacio con las dimensiones o aspect-ratio correctos, mostrar mientras tanto un fondo con su color dominante o una versión diminuta y desenfocada, y hacer que la imagen final aparezca con un fundido breve. Sobre formatos y tamaños, en imágenes para la web entramos en detalle.

04Interfaces optimistas: cuando la respuesta se anticipa

Hay acciones que casi siempre salen bien: marcar un favorito, archivar un mensaje, cambiar una cantidad en el carrito, completar una tarea. Para ellas existe una técnica muy eficaz: mostrar el resultado al instante, como si el servidor ya hubiera respondido, y confirmar en segundo plano.

La sensación es de rapidez absoluta. El corazón se rellena al tocarlo, la tarea se tacha, el número del carrito cambia. Si la petición falla, que es raro, la interfaz deshace el cambio y lo explica con un aviso breve: «No hemos podido guardar el favorito. Inténtalo de nuevo».

Cuándo usarla y cuándo no:

• →Sí, en acciones reversibles, frecuentes y con muy pocas probabilidades de error.
• →Con cuidado, en acciones con dinero o con efectos fuera de la app, como pagos, reservas o envíos. Ahí la persona necesita una confirmación real, no anticipada.
• →Siempre, con una forma clara de saber si algo no se ha guardado.

05Carga progresiva: primero lo importante

Otra forma de acortar la espera percibida es no esperar a tenerlo todo para mostrar algo. La página se envía por partes: primero la estructura y el contenido principal, después lo secundario. Los frameworks actuales, como React con Suspense o Next.js con sus estados de carga por ruta, permiten precisamente eso: cada bloque de la pantalla tiene su propio estado de carga y aparece en cuanto está listo.

Para decidir el orden, hacemos una lista sencilla con el equipo:

1. 01¿Qué necesita ver la persona para orientarse? Cabecera, título, navegación. Esto va primero.
2. 02¿Qué vino a buscar? El listado, el precio, el formulario. Esto va inmediatamente después.
3. 03¿Qué la ayuda a decidir? Valoraciones, recomendaciones, contenido relacionado. Puede esperar unos instantes.
4. 04¿Qué es accesorio? Widgets, recomendaciones personalizadas, contenido inferior. Puede cargar al acercarse con el scroll.

Este orden también ayuda a la velocidad real. Menos JavaScript en la carga inicial significa una página que responde antes, como explicamos en JavaScript y rendimiento.

06Qué decir mientras se espera

En las esperas de varios segundos, el texto que acompaña al indicador cambia mucho la experiencia. Lo que funciona es decir qué está pasando, en lenguaje de la persona, y si se puede, cuánto falta:

• →«Buscando disponibilidad en los tres hoteles…» en lugar de «Cargando…».
• →«Subiendo 3 de 8 fotos» en lugar de un porcentaje sin contexto.
• →«Preparando tu informe. Suele tardar menos de un minuto; te avisaremos cuando esté».

En procesos largos con varias fases, cambiar el mensaje según avanza («Revisando datos», «Calculando precios», «Casi listo») da sensación de progreso real, siempre que los mensajes correspondan a lo que de verdad ocurre. Los principios de tono y claridad son los mismos que contamos en la guía de UX writing.

07Errores y tiempos de espera: el final de la carga

Toda carga tiene que terminar en algo. A veces termina en éxito y a veces en un error o en un tiempo de espera agotado. Diseñar ese final es parte del estado de carga:

• →Un límite razonable. Si una petición no responde en, por ejemplo, quince o veinte segundos, la interfaz deja de esperar y lo dice.
• →Un mensaje concreto y una salida. «No hemos podido cargar los cursos. Comprueba tu conexión e inténtalo de nuevo», con un botón de reintentar.
• →Lo que sí ha cargado se queda. Si falla un bloque, el resto de la pantalla sigue funcionando.
• →Sin conexión, con contexto. En apps y webs que se usan en movilidad, un aviso discreto de «Sin conexión» y el contenido guardado anteriormente son mucho mejores que una pantalla vacía.

08La espera también es parte de la experiencia

Ninguna web ni ninguna app carga en cero segundos, y probablemente ninguna lo hará. Por eso la espera merece el mismo cuidado de diseño que cualquier otra pantalla: es el primer contacto con cada página y se repite decenas de veces en cada visita. Un buen estado de carga no se nota; simplemente hace que todo parezca fluir.

En SIMA trabajamos la velocidad desde las dos caras, la técnica y la percibida, en los proyectos de desarrollo web y apps que diseñamos y construimos. Si tu web o tu plataforma da sensación de lentitud y quieres saber si es cuestión de velocidad o de cómo se vive la espera, escríbenos y lo miramos juntos.