Las pantallas de carga existen porque la información no aparece al instante en una web, una app móvil o un videojuego. Cuando el front pide datos al backend mediante una solicitud HTTP, algo tiene que ocupar ese vacío visual, y aquí entra la batalla entre loading spinners y loading skeletons, dos estrategias muy distintas para mantener al usuario enganchado mientras llega la información.

¿Por qué los usuarios abandonan una página que carga lento?

Los usuarios no solo odian esperar, odian no tener el control. Si no entienden qué está pasando en pantalla, se van.

Un estudio de Google de 2017 [2:00] dejó cifras que duelen sobre el bounce rate, es decir, el porcentaje de gente que se devuelve a buscar otra opción cuando una página tarda en cargar:

• De 1 a 3 segundos de espera, el bounce rate sube 32%.
• Hasta 5 segundos, sube 90%.
• Hasta 6 segundos, ronda el 106 a 110%.
• Hasta 10 segundos, llega a 123%.

Y como hoy la mayoría navega desde el celular, esos números solo empeoran. Tu contenido puede ser brillante, pero si la app no carga rápido, tus usuarios se van con la competencia antes de leerte.

¿Qué es el bounce rate? Es el porcentaje de usuarios que entran a tu página y se devuelven sin interactuar. Si tu sitio carga lento, ese número se dispara.

¿Qué hace que una pantalla de carga sea buena?

Una buena loading screen cumple tres reglas básicas que se desprenden de la idea de darle control al usuario:

• Ser reconocible: que se distinga del estado de error y del estado con datos ya cargados. Mostrar la misma pantalla cuando hay error y cuando estás cargando es una mala práctica directa.
• Ser tolerable: si no puedes acelerar la API (como cuando dependes de algo externo tipo TheMovieDatabase), al menos haz que la espera no duela.
• Ser entendible, e incluso divertida si el tono de tu producto lo permite. Slack, por ejemplo, mostraba tips y chistes mientras cargaba mensajes [6:30]. En una app de banco, ese mismo recurso sería desastroso.

La clave está en comunicar qué se está cargando, no solo que algo se está cargando.

¿Loading spinners o loading skeletons: cuál funciona mejor?

Aquí es donde se define la pelea. Cada estrategia resuelve el problema de forma muy distinta.

¿Por qué los loading spinners suelen fallar?

Un loading spinner es esa ruedita que gira infinitamente. Es fácil de implementar y se entiende rápido que algo está pasando, pero ahí termina su utilidad.

El spinner no te dice qué está cargando ni cuánto falta. Puede ser un video, un libro, una imagen, una API, lo que sea. Y cuando da vueltas demasiado tiempo, no sabes si avanza, si se cayó el internet o si la app falló. Rompe la sensación de control.

Una evolución son las loading animations con barra de porcentaje, típicas de videojuegos o actualizaciones de Windows. Funcionan ahí porque el sistema sí sabe cuánto lleva descargado. Pero en web, ese porcentaje suele ser hardcodeado, es decir, programado a mano con tiempos inventados como cinco segundos divididos en tramos. No hay forma real de saber cuánto falta para que el backend responda, así que ese 60% es, casi siempre, una mentira piadosa.

¿Qué significa hardcodear un porcentaje de carga? Significa fijar manualmente los tiempos en el código en lugar de medir el progreso real. Es común en web porque no hay forma exacta de saber cuánto falta para que responda una API.

¿Cómo funciona un loading skeleton y por qué lo usan YouTube y Platzi?

Un loading skeleton muestra la estructura HTML de la página con bloques grises en los lugares donde irán el título, el botón de suscribirte, los videos recomendados y demás elementos.

YouTube lo aplica de manual: mientras carga el canal del video, los recomendados o el botón de suscripción, te muestra rectángulos grises con una animación sutil que indica actividad [11:00]. Apenas una sección termina de cargar, aparece su contenido real, sin esperar a que el resto termine. Platzi, Facebook y Twitter usan exactamente la misma estrategia.

Esto cumple las buenas prácticas:

• Te dice qué se está cargando, porque reconoces la estructura.
• Te da control, porque ves el progreso por secciones.
• Es tolerable, porque la animación suave indica que algo se mueve.

¿Cómo simular conexiones lentas para probar tu pantalla de carga?

Las DevTools del navegador tienen una opción de throttling en la pestaña Network [13:00] que te deja emular conexiones reales:

• Offline: simula sin internet. Útil para ver cómo se rompe la app sin Axios u otros recursos externos.
• Slow 3G: una conexión desesperantemente lenta. Una recarga puede tardar 15 segundos, suficiente para entrar en zona roja según Google.
• Fast 3G: lento pero no al punto de ser frustrante.

Al probar Slow 3G en una app sin pantalla de carga, te quedas con un HTML en blanco mientras llegan las fuentes, las categorías y luego las imágenes. Si es la primera vez que un usuario entra, ese vacío puede costarte la visita entera.

No controlas el internet de tu usuario, pero sí controlas la experiencia que le entregas durante la espera. Implementa un loading skeleton en tu proyecto, cuida que sea reconocible, tolerable y entendible, y cuéntame en los comentarios qué estrategia elegiste y por qué.