Los desarrolladores de aplicaciones de fotos para eventos ahora cuentan con una lista de verificación concreta para mantener las subidas desde el navegador activas en entornos concurridos. Un solo usuario puede saltar de Wi-Fi a datos móviles mientras docenas de dispositivos compiten por el mismo punto de acceso. La guía muestra cómo evitar que una foto desaparezca tras un aviso de "subida completada", incluso si el invitado bloquea el teléfono o la red sufre un hipo.

Por qué las subidas ordinarias fallan en bodas y festivales

En una oficina, un portátil está conectado a un enlace Ethernet estable y un único usuario hace clic en "enviar". En la recepción de una boda o en un festival de música, la misma acción puede desencadenar una cascada de problemas: el invitado camina desde el salón de la ceremonia hasta el aparcamiento, el router colapsa bajo el peso de cientos de teléfonos, o el teléfono pierde la conexión Wi-Fi y pasa a datos móviles. Es posible que el navegador haya transmitido cada byte al servidor, pero que el servidor aún no haya guardado el archivo en el almacenamiento. Si la interfaz de usuario declara el éxito en el momento en que la barra de progreso llega al 100 %, el invitado podría borrar la foto, dejando al organizador con un archivo faltante.

El coste oculto de "simplemente subir"

Un enfoque ingenuo trata la subida como un único HTTP POST. Funciona cuando la conexión es estable, pero en una red congestionada, cada interrupción obliga a reiniciar todo el archivo. Los usuarios se frustran y se producen picos de ancho de banda cuando docenas de teléfonos reintentan la subida a la vez. Dividir el archivo en fragmentos (chunks) y rastrear cada pieza añade complejidad, pero la recompensa es una transferencia predecible y de baja carga que sobrevive a los cambios de red.

Cómo construir un sistema de subida por fragmentos y reanudables

A continuación, se presenta una receta práctica paso a paso.

1. Generar un ID de subida antes de que cualquier dato salga del navegador

Crea un identificador único universal (UUID) localmente y envíalo al servidor como la primera solicitud. El servidor registra una sesión bajo ese ID. Si el navegador reintenta más tarde debido a un tiempo de espera agotado, incluirá el mismo UUID, lo que permitirá al servidor reconocer la sesión y evitar una entrada duplicada. Esto hace que el flujo de trabajo sea idempotente: repetir la misma solicitud no tiene ningún efecto adverso.

2. Dividir el archivo en fragmentos de 5 a 10 MB

El tamaño del fragmento es un compromiso. Los fragmentos pequeños (menos de 1 MB) aumentan el número de solicitudes HTTP y la sobrecarga de encabezados asociada. Los fragmentos muy grandes hacen que cualquier interrupción sea costosa porque el cliente debe volver a enviar una pieza grande. Para fotos típicas y vídeos cortos, de 5 a 10 MB ofrece un equilibrio: cada solicitud termina lo suficientemente rápido como para mantener la interfaz de usuario receptiva, pero el número de solicitudes se mantiene manejable.

3. Limitar el número de subidas paralelas

Los navegadores móviles pueden abrir muchas conexiones, pero en una red Wi-Fi congestionada, cada flujo adicional compite por el ancho de banda limitado. Dos flujos constantes son mejores que ocho que compiten entre sí. Utiliza la API navigator.connection para detectar condiciones de bajo ancho de banda y reducir automáticamente la concurrencia.

4. Persistir el estado de la subida en IndexedDB

Almacena el ID de subida, la lista de fragmentos ya enviados y cualquier desplazamiento (offset) confirmado por el servidor en el IndexedDB del navegador. Si la página se recarga o el usuario cierra la pestaña, el cliente puede recuperar el estado en la siguiente carga. Cuando el usuario vuelva a abrir la página, pídale que seleccione el mismo archivo; los metadatos almacenados permiten que la subida se reanude desde el último fragmento confirmado en lugar de empezar de cero.

5. Detectar cambios reales en la red, no solo navigator.onLine

El indicador navigator.onLine a menudo informa que está "en línea" incluso cuando la conexión es inutilizable. En su lugar, establece un tiempo de espera de solicitud corto (por ejemplo, 5 segundos) para cada fragmento. Si ocurre un tiempo de espera, trata la red como si estuviera caída. Cuando la conectividad regrese, consulta al servidor la lista de fragmentos que ya tiene y luego continúa subiendo solo las piezas que faltan. Esto evita el envío de datos duplicados tras un breve corte.

6. Aplicar un retroceso exponencial con jitter para los reintentos

Cuando los dispositivos de muchos invitados detectan que la red ha vuelto, podrían lanzar reintentos todos al mismo tiempo, saturando el servidor. El retroceso exponencial (exponential backoff) hace que cada reintento espere más tiempo que el anterior, mientras que el jitter añade un pequeño desfase aleatorio. La combinación distribuye el tráfico de reintentos a lo largo de unos segundos, evitando un pico repentino.

7. Mostrar una retroalimentación por capas y accesible

Una barra de estado de tres niveles comunica el estado real del archivo:

  • Recibido – el servidor ha almacenado cada fragmento y ha marcado el archivo como completo.
  • Preparando – el servidor está generando miniaturas o transcodificando un vídeo.
  • Disponible – el organizador puede ver o descargar el archivo.

Evite depender únicamente del color; combine los iconos con un texto breve para que los usuarios de lectores de pantalla también comprendan el progreso.

¿Qué podría seguir saliendo mal?

Incluso una carga reanudable bien diseñada puede tropezar con algunos casos límite.

Qué observar a continuación

La plataforma web está evolucionando.

Conclusión

Una carga reanudable y fragmentada que rastrea cada parte, almacena el estado localmente y reintenta de forma inteligente convierte una red de eventos inestable en un conducto confiable para las fotos de los invitados. Implemente la lista de verificación anterior.