Mientras carga, ya te está contando algo

Antes de que empiece Chasing the Moment, recibís una entrada de cine. El ticket se curva mientras carga la web y su talón te deja elegir si entrás con sonido. Una pantalla de carga puede prepararte para la experiencia mientras el navegador termina de armarla.

Para una web pesada, ahí hay una pregunta útil: qué puede llevarse el visitante de esa espera. En Labba pondríamos una condición: la pantalla de carga tiene que ganarse su lugar dentro del tiempo que la experiencia realmente necesita. Cuando la página ya se puede usar, la introducción debería dejarte pasar.

El ticket tiene un trabajo

En el artículo que publicó en Codrops el 12 de octubre de 2026, su creador, Canberk Polat, explica que prepara efectos visuales durante la carga y usa el ticket para resolver la elección de audio. Documenta la implementación, sin un estudio de visitantes que demuestre que esa entrada reduce el abandono.

La decisión sirve para mirar algo concreto. Elegir el sonido tiene sentido antes de una película. Llevar esa elección al ticket hace que la entrada pertenezca al mismo mundo. Podemos rescatar esa conexión sin adoptar el resto del sitio como modelo.

Si estuviéramos definiendo una experiencia inmersiva, pediríamos que el diseño explique qué recibe el visitante antes de que abra la primera escena. Poder tomar una decisión útil es una respuesta. Entender cómo funciona lo que viene también. Una animación de logo merecería más discusión, sobre todo si su duración decide cuándo te dejan avanzar.

Sentir que carga más rápido se puede investigar

En un paper presentado en CHI en 2010, Chris Harrison, Zhiquan Yeo y Scott Hudson probaron variaciones visuales en barras de progreso. En el experimento final, con 16 participantes, una barra convencional de cinco segundos se sintió equivalente a una animada que duraba 5,61 segundos. Es una comparación controlada y pequeña entre barras; no permite predecir cómo va a rendir una web cinematográfica.

La distinción importa cuando alguien propone entretener durante la carga. Podemos investigar si la espera se siente más corta. También necesitamos medir cuánto dura, si se entiende qué está pasando y si el visitante completa lo que vino a hacer. Que una respuesta dé bien no resuelve las demás.

Otra posibilidad es explicar el trabajo. En una investigación de 2011 con servicios simulados de viajes y citas, Ryan Buell y Michael Norton encontraron que mostrar el esfuerzo aparente del servicio podía aumentar su valor percibido. También encontraron límites al alargar las esperas. Estudiaban la evaluación de servicios, no la carga de una web inmersiva.

Nuestra lectura es que vale la pena hacer comprensible el trabajo real. Si una aplicación está comparando rutas disponibles, mostrar esa etapa podría explicar la demora. Agregaríamos esa información mientras ocurre la búsqueda. Cuando los resultados están listos, dejaríamos de representar el esfuerzo y mostraríamos las opciones.

Hay páginas que podrían dejarte empezar

Un catálogo plantea un problema distinto al de una película web. Imaginá que entrás para consultar un precio. Poder leer el nombre del producto mientras llegan las fotos ya te permitiría avanzar. Una introducción que tape toda la página tendría que justificar por qué te quita esa posibilidad.

El patrón de carga de Carbon, el sistema de diseño de IBM, actualizado el 11 de agosto de 2026, describe la carga progresiva: mostrar primero una versión simple y completar los detalles después. También contempla skeletons, formas simplificadas que reservan el lugar del contenido pendiente. Son patrones documentados, no una prueba de que un tratamiento gane siempre.

Para ese catálogo, empezaríamos identificando qué información y qué controles pueden estar disponibles por separado. La decisión de carga seguiría la tarea de compra. Para la película, la primera escena necesita preparación suficiente para reproducirse con coherencia. Un mismo estudio puede diseñar las dos entradas y darles formas muy distintas.

La pantalla de carga también consume

La animación de entrada tiene su propio costo. La documentación de Google sobre tareas largas explica que la animación con JavaScript y el trabajo de arranque pueden compartir el hilo principal del navegador, donde se resuelve buena parte de la interfaz. Las tareas largas pueden demorar la respuesta a una interacción. El costo depende de la implementación; ver movimiento no alcanza para diagnosticar un problema.

Por eso revisaríamos la pantalla de carga en los dispositivos que la experiencia necesita soportar. Si la entrada requiere archivos pesados o una preparación costosa, ese trabajo entra en el mismo presupuesto. Lo que queremos saber es cuándo alguien puede hacer algo útil con el diseño completo funcionando.

Medir cuándo podrías haber entrado

En una revisión registraríamos dos momentos: cuándo la primera acción útil ya es técnicamente posible y cuándo la entrada permite hacerla. La diferencia merece una explicación. A veces una transición breve ayuda a entender dónde caíste. Otras veces la animación está esperando su último cuadro.

Después miraríamos una segunda visita. Quien ayer disfrutó una introducción puede volver hoy por un dato concreto. Dejarlo avanzar apenas la experiencia esté lista sería un requisito del brief. También revisaríamos las alternativas para teclado y movimiento reducido, junto con las decisiones de animación del resto del sistema de diseño.

La prueba más reveladora podría llegar con la conexión más rápida. Cuando el contenido está listo antes de que termine la entrada, el equipo tiene que decidir a quién sigue la web: a la animación o al visitante.

Fuentes

• Canberk Polat, Chasing the Moment, Codrops, 12 de octubre de 2026.
• Harrison, Yeo y Hudson, Faster Progress Bars, CHI, abril de 2010.
• Buell y Norton, The Labor Illusion, Management Science, septiembre de 2011.
• IBM, Loading, Carbon, actualizado el 11 de agosto de 2026.
• Wagner y Kenny, Optimize long tasks, web.dev, actualizado el 19 de diciembre de 2024.