Optimización de carga por lotes: transfiere carpetas rápido

La estrategia de carga por lotes más rápida: empaqueta la carpeta en un único .zip (modo almacenamiento, sin compresión) y sube un solo objeto grande en lugar de miles de archivos pequeños. Una carpeta de 5.000 fotos .jpg a 500 KB cada una suma 2,5 GB, pero tarda 10-20 veces más en subirse individualmente que como un único archivo de 2,5 GB, porque cada archivo pequeño paga la sobrecarga completa de TLS y HTTP. Los servicios con soporte de subida paralela (HexaTransfer, Dropbox, rclone) ayudan cuando muchos fragmentos son grandes. Los servicios sin paralelismo siguen ganando en rendimiento una vez que combinas archivos pequeños en un solo archivo. Añade la deduplicación de archivos duplicados accidentalmente, omite el desorden .DS_Store y Thumbs.db, y terminarás en una fracción del tiempo ingenuo.

Por qué miles de archivos pequeños son lentos

Cada subida de archivo por HTTPS lleva una sobrecarga fija: handshake TLS (reutilizable con keep-alive de conexión), cabeceras HTTP (~500 bytes), confirmación del servidor y volcado en disco en el lado receptor. Para un archivo de 50 KB, esa sobrecarga puede superar el propio tamaño del archivo. Para un archivo de 500 KB, la sobrecarga es del 10-20% del total de bytes en el cable.

Multiplica por 5.000 archivos y habrás quemado la mitad del tiempo en metadatos en lugar de en el payload. Por eso copiar una carpeta grande con muchos archivos pequeños al almacenamiento externo siempre es más lento que copiar un archivo de tamaño equivalente.

Primero el archivo, luego la subida

El mayor aumento de velocidad para subidas de carpetas: comprime en un único .zip, .7z o .tar primero. Para contenido ya comprimido (fotos, vídeos, documentos de Office), usa modo almacenamiento (sin compresión): obtienes el beneficio del agrupamiento sin el coste de CPU. Para carpetas con mucho texto (logs, código fuente), usa compresión normal para un ahorro de tamaño real además del agrupamiento.

Comandos:

• macOS/Linux: zip -0 -r archivo.zip carpeta/ para sin compresión; zip -r archivo.zip carpeta/ para compresión por defecto.
• Windows: Clic derecho en la carpeta → Enviar a → Carpeta comprimida. O usa 7-Zip con Añadir al archivo → Nivel de compresión → Almacenar.
• Carpetas grandes: tar -cf archivo.tar carpeta/ (sin compresión) o tar -czf archivo.tar.gz carpeta/ (gzip).

Deduplica antes de archivar

Las carpetas acumulan archivos duplicados con el tiempo. Los proyectos de diseño tienen "final_v2.psd", "final_v2_COPIA.psd", "final_v2_BACKUP.psd": mismo contenido, nombres distintos. Una carpeta de 20 GB puede reducirse rutinariamente a 12 GB después de deduplicar.

Herramientas: fdupes (Linux), rmlint (Linux/macOS), Duplicate File Finder (macOS), dupeGuru (multiplataforma). La mayoría trabaja generando hashes de archivos y marcando los hashes idénticos. Revisa los resultados, elimina los duplicados y luego archiva.

Para fotógrafos, el catálogo de Lightroom ya rastrea fotos únicas; exporta solo las selecciones marcadas en lugar de carpetas de captura completas.

Omite el desorden del sistema operativo

Cada carpeta de macOS acumula archivos .DS_Store (metadatos ocultos). Cada carpeta de Windows lleva Thumbs.db. Los archivos .directory de Linux aparecen desde KDE. Estos no aportan nada al receptor y aumentan el número de archivos del archivo.

Al comprimir en macOS:

zip -r archivo.zip carpeta/ -x "*.DS_Store" "__MACOSX"

En Windows con 7-Zip, excluye patrones en la interfaz o línea de comandos con -xr!Thumbs.db -xr!desktop.ini. Para transferencias tipo rsync, usa --exclude='.DS_Store' --exclude='Thumbs.db'.

Subidas fragmentadas paralelas

Cuando el servicio lo admite, los flujos HTTP paralelos saturan el ancho de banda que una sola conexión TCP no puede llenar en rutas de alta latencia. El protocolo tus.io lo admite mediante subidas de fragmentos concurrentes. Las bibliotecas de cliente como tus-js-client tienen por defecto una solicitud concurrente, pero pueden configurarse a más.

Para subidas intercontinentales (por ejemplo, un usuario en España a un servicio europeo del norte), el paralelismo dobla o triplica el rendimiento efectivo. Para subidas locales, un solo flujo habitualmente satura el ancho de banda de subida de todos modos y el paralelismo no aporta nada.

Ajuste del tamaño de fragmento

Los fragmentos grandes reducen la sobrecarga por solicitud; los fragmentos pequeños se recuperan más rápido de los fallos de red. El compromiso depende de tu conexión:

| Tipo de conexión | Tamaño de fragmento recomendado | |---|---| | Fibra gigabit, con cable | 32-64 MB | | Fibra residencial, Wi-Fi | 10-20 MB | | Banda ancha de oficina | 10 MB | | Móvil 4G/5G | 2-5 MB | | Wi-Fi inestable/hotel | 1-2 MB |

La mayoría de los servicios de consumidor eligen un valor razonable por defecto (5-10 MB) y no exponen el ajuste. Las herramientas de línea de comandos (rclone, aws s3 cp, gsutil) permiten un ajuste preciso.

La estructura de carpetas importa menos que el volumen total

Un mito habitual: "las carpetas muy anidadas ralentizan las subidas." No es así. El formato de archivo aplana las rutas en cabeceras de cadena independientemente de la profundidad. Una carpeta de 10.000 archivos a 3 niveles de profundidad se sube de forma idéntica a una carpeta de 10.000 archivos a 10 niveles de profundidad una vez archivada.

Lo que sí importa: el número de archivos individuales. 10.000 archivos pequeños planos es el mismo problema que 10.000 archivos pequeños anidados: archívalos.

Estrategia de compresión por tipo de contenido

• Fotos mixtas (.jpg/.heic): .zip en modo almacenamiento. Sin desperdicio de CPU.
• Fotos RAW (.cr3/.arw/.nef): .zip en modo almacenamiento. Ya están comprimidas internamente.
• Proyectos de vídeo (.mp4, .mov, .prproj): .zip en modo almacenamiento.
• Código fuente: 7z con LZMA2 para máximo ratio.
• Archivos de log: 7z con LZMA2; espera reducciones de 10-20x.
• PDFs: modo almacenamiento. La mayoría de los PDF tienen compresión interna.
• Documentos Office (.docx, .xlsx): modo almacenamiento. Ya son XML comprimido en ZIP internamente.
• Volcados de bases de datos (.sql): 7z con LZMA2. Excelente compresión.

Fondo vs primer plano

Las subidas basadas en navegador deben mantener la pestaña abierta. Cerrar la pestaña suele matar la subida. Algunos servicios ofrecen subidas en segundo plano respaldadas por Service Worker que continúan brevemente después de cerrar la pestaña, pero esto es poco fiable en navegadores móviles y en algunos perfiles de navegador corporativo.

Para subidas masivas realmente grandes (más de 100 GB), los clientes de escritorio ganan porque se ejecutan como procesos a nivel del sistema operativo. rclone monta y sincroniza con cualquier nube importante. El cliente de escritorio de Dropbox encola las subidas de forma fiable. Estos sobreviven al cierre de la tapa del portátil y a los cambios de Wi-Fi de formas en que los navegadores tienen dificultades.

Para subidas por lotes de menos de 10 GB, un servicio moderno basado en navegador con subidas fragmentadas vía tus.io gestiona perfectamente la carga. La encriptación en el cliente de HexaTransfer añade una sobrecarga modesta de CPU pero no afecta materialmente al rendimiento en hardware actual.

Divide los lotes demasiado grandes

Cuando tu lote supera el techo de transferencia por operación del servicio, divídelo de forma lógica en lugar de mecánica. Las carpetas de "Fotos por fecha" de un rodaje de un mes funcionan mejor que las divisiones arbitrarias por número de bytes porque los receptores pueden verificar que cada lote está completo ("1-7_marzo.zip", "8-14_marzo.zip") en lugar de preguntarse si falta el volumen .005.

Para servicios sin límites por transferencia pero con límites de sesión, las subidas secuenciales de múltiples archivos evitan alcanzar los límites de subidas concurrentes.

Verifica antes de cerrar el portátil

Las subidas masivas son tentadoras para dejar en segundo plano. No lo hagas. Antes de cerrar el portátil:

• Confirma que la página de subida muestra "completado" y no "en progreso"
• Abre el enlace en un navegador diferente o en modo incógnito y verifica la experiencia del receptor
• Comprueba que el archivo se abre correctamente (un .zip corrupto durante la subida es raro pero posible)
• Confirma que los ajustes de caducidad son los que querías

Cinco minutos de verificación evitan el incómodo correo de mañana preguntando si el receptor recibió los archivos.

Sincronización delta para lotes repetidos

Si estás actualizando un lote —por ejemplo, copias de seguridad semanales de una carpeta de proyecto— volver a subir todo es un desperdicio. Herramientas como rclone, rsync sobre SSH o clientes de sincronización dedicados transfieren solo los archivos modificados. Esto requiere almacenamiento persistente (no servicios de transferencia efímeros), por lo que es un patrón de almacenamiento en la nube más que un patrón de transferencia.

Para flujos de trabajo de transferencia reales donde el receptor es diferente cada vez, el archivo completo de cada lote es el enfoque correcto.

Conclusión

El camino rápido para las subidas de carpetas: archiva todo en un único .zip (modo almacenamiento para contenido precomprimido, compresión real para texto), omite los archivos de desorden del sistema operativo, deduplica donde valga la pena y sube el único archivo a través de un servicio que admita subidas fragmentadas y reanudables. Para lotes muy grandes, usa un cliente de escritorio. La diferencia entre el enfoque ingenuo de "subir carpeta directamente" y el camino optimizado suele ser 10x en tiempo transcurrido.

Pruébalo en hexatransfer.com — gratis, sin cuenta, hasta 10 GB.