¿Navegador se cierra al subir? Soluciones para estabilidad

Si el navegador se cierra a mitad de una carga, la causa es casi siempre la presión de memoria en la pestaña. Chrome mata las pestañas que superan aproximadamente 2 a 4 GB de memoria privada, y un servicio de transferencia que carga un archivo de 10 GB en un único objeto Blob superará ese límite. Solución: usa un servicio que transmita el archivo en fragmentos mediante el método slice() de la File API (la mayoría de los modernos lo hacen), cierra todas las demás pestañas antes de cargar, desactiva las extensiones que se enganchan en fetch/XHR, y carga desde un ordenador de escritorio en lugar de un portátil con batería. Firefox suele gestionar los flujos grandes de File API con menos uso de memoria que Chromium.

Por qué se cierran los navegadores al cargar

Dos realidades arquitectónicas colisionan. Primero, cada pestaña del navegador es un proceso separado con su propio límite de memoria. Chrome limita cada proceso de renderizado a unos 4 GB en sistemas de 64 bits antes de que intervenga el OOM killer. Segundo, la forma ingenua de cargar un archivo en JavaScript es pasar todo el objeto File al cuerpo de un fetch, que los navegadores a menudo intentan almacenar en memoria antes de enviar.

Un servicio de transferencia bien construido nunca hace esto. Lee el archivo con File.slice(inicio, fin) para producir un Blob para cada fragmento de 5 a 20 MB, carga ese fragmento y luego lo libera. La memoria se mantiene acotada a aproximadamente tamañoFragmento × concurrencia bytes independientemente del tamaño del archivo.

Si la carga empieza bien a los 500 MB de progreso y la pestaña se pone gris a los 2 GB, el servicio está cargando todo el archivo antes de enviarlo. Elige un servicio diferente o un enfoque diferente.

Cierra las demás pestañas de forma agresiva

Chrome comparte un único proceso de renderizado para algunas pestañas agrupadas (Site Isolation cambia esto, pero la presión de memoria sigue siendo compartida a nivel del sistema). Una segunda pestaña reproduciendo YouTube en 4K, una tercera con Figma cargado, una cuarta con Notion consumiendo 800 MB de RAM cada una, todo suma. Una carga de 10 GB en un portátil con 8 GB de RAM y 12 pestañas abiertas es jugar con fuego.

Antes de iniciar una carga grande, cierra Chrome por completo y vuelve a abrirlo solo con la pestaña del servicio de transferencia. El Monitor de Actividad (macOS) o el Administrador de tareas (Windows) deberían mostrar el navegador usando bien menos de 2 GB en esa única pestaña.

Desactiva las extensiones

Los bloqueadores de anuncios, las extensiones de privacidad, los gestores de contraseñas y los analizadores de red (uBlock Origin, Privacy Badger, LastPass, HTTP Toolkit) se inyectan en las solicitudes de red. La mayoría no causan problemas. Algunos, especialmente los que tienen código desactualizado, almacenan en buffer los cuerpos de las solicitudes para inspeccionarlos, lo que anula las cargas en streaming y dispara la memoria.

Prueba en una ventana de incógnito (las extensiones están desactivadas por defecto). Si la carga se completa limpiamente en incógnito, las extensiones son el problema. Actívalas de una en una para encontrar la culpable.

Desactiva la aceleración por hardware cuando la GPU es débil

Los portátiles más antiguos con GPUs Intel UHD 620 integradas o similares a veces se cierran al renderizar una actualización de la barra de progreso junto con el buffer de lectura del archivo simultáneamente. Se puede desactivar desde Configuración de Chrome > Sistema > "Usar aceleración de hardware cuando esté disponible". Esto pierde algo de fluidez en todo lo demás, pero estabiliza las cargas grandes en sistemas con poca memoria.

De forma similar, desactiva el modo "Ahorro de memoria" de Chrome para la pestaña de carga, que se sabe que expulsa pestañas bajo presión a mitad de carga. Fija la pestaña o exclúyela explícitamente.

Cambia a Firefox para archivos muy grandes

Firefox históricamente gestiona la File API con presupuestos de memoria más ajustados que Chromium. En una carga de 10 GB que sigue cerrando Chrome, Firefox a menudo completa el mismo trabajo sin problemas. La diferencia no es enorme en servicios bien construidos (ambos gestionan bien el streaming fragmentado), pero en servicios con implementaciones menos ideales, el modelo de memoria conservador de Firefox es más tolerante.

Safari en macOS también es fiable para cargas grandes, con la advertencia de que iOS Safari termina agresivamente las pestañas en segundo plano.

Fija la pestaña y mantenla en primer plano

Las pestañas en segundo plano son las primeras en ser expulsadas bajo presión de memoria. Mantén la pestaña de carga en primer plano. No cambies a otra ventana durante 30 minutos y vuelvas a encontrar la pestaña recargada. Las pestañas "descartadas" de Chrome muestran un marcador de posición gris al volver, y cualquier carga en curso está muerta.

Activa Caffeinate en macOS (caffeinate -s) o desactiva el modo de ahorro de energía de Windows durante la carga. Un portátil que se duerme cierra las conexiones WebSocket y XHR, y no todos los servicios pueden reanudarse limpiamente después.

Carga desde el escritorio, no desde un portátil con batería

Los portátiles con batería limitan la CPU y la RAM de forma agresiva. El "Modo de bajo consumo" de macOS y el "Ahorro de batería" de Windows reducen la prioridad de las tareas en segundo plano, lo que para una pestaña del navegador que hace cifrado AES y escrituras de red significa pausas.

Enchúfalo. Desactiva los modos de ahorro de batería. Si el portátil tiene opción de perfiles de rendimiento de CPU (Dell Power Manager, Lenovo Vantage), establece "Rendimiento" para la duración de la carga.

Reinicia el navegador antes de empezar

Chrome, Firefox y Edge filtran memoria lentamente durante sesiones largas. Un navegador que ha estado abierto dos días con 40 pestañas abiertas y cerradas puede llevar 2 GB de memoria zombie antes de que siquiera abras la página de carga. Cierra completamente (Cmd+Q, no solo la ventana, en macOS; clic derecho en la barra de tareas > Salir en Windows) y vuelve a abrir.

Ajusta el tamaño de fragmento al hardware

Para servicios que permiten configurar el tamaño de fragmento (la mayoría no, pero algunas herramientas CLI como rclone sí), los fragmentos más pequeños usan menos memoria. Fragmentos de 5 MB con 4 trabajadores concurrentes son 20 MB de buffer en cualquier momento. Fragmentos de 100 MB con 4 trabajadores son 400 MB. En una máquina de 4 GB, la diferencia importa.

Los servicios web eligen los valores predeterminados por ti, normalmente entre 5 y 20 MB por fragmento, lo cual es razonable. Pero los scripts personalizados a veces usan fragmentos más grandes para "ir más rápido" y fallan en máquinas pequeñas.

Comprueba la RAM con el Monitor de Actividad durante la carga

Durante la carga, observa la memoria del proceso del navegador. Monitor de Actividad en macOS: pestaña Memoria, filtra por nombre del navegador. Administrador de tareas de Windows: pestaña Detalles, ordena por "Memoria (conjunto de trabajo privado)".

Una carga fragmentada saludable mantiene estable unos pocos cientos de MB de memoria del navegador independientemente del progreso. Si la memoria sube linealmente con el progreso de la carga (llegando a 5 GB al 50 por ciento de un archivo de 10 GB), el servicio está almacenando todo en buffer. Ese es el bug. Busca un servicio diferente.

Usa servicios diseñados para cargas grandes en el navegador

Un servicio de transferencia bien diseñado usa cargas fragmentadas con un pool de Web Workers para el cifrado, memoria acotada y reintento explícito de fragmentos fallidos. HexaTransfer lee archivos con File.slice() en Web Workers, cifra con AES-256-GCM por fragmento y nunca supera unos pocos cientos de MB de memoria del navegador independientemente de si estás enviando 50 MB o los 10 GB completos por transferencia, lo que importa cuando tu navegador ya está gestionando todo lo demás del día.

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