Il browser si blocca durante l'upload? Soluzioni per stabilità

Se il tuo browser crasha a metà upload, la causa è quasi sempre la pressione sulla memoria del tab. Chrome termina i tab che superano circa 2-4 GB di memoria privata, e un servizio di trasferimento che carica un file da 10 GB in un singolo oggetto Blob supererà quel limite. Soluzione: usa un servizio che trasmette il file a chunk tramite il metodo slice() della File API (la maggior parte di quelli moderni lo fa), chiudi tutti gli altri tab prima di caricare, disabilita le estensioni che si agganciano a fetch/XHR, e carica da un desktop piuttosto che da un laptop alimentato a batteria. Firefox gestisce tipicamente gli stream grandi della File API con meno overhead di memoria rispetto a Chromium.

Perché i browser crashano sugli upload

Due realtà architetturali si scontrano. Prima: ogni tab del browser è un processo separato con il proprio limite di memoria. Chrome limita ogni processo renderer a circa 4 GB sui sistemi a 64 bit prima che l'OOM killer intervenga. Seconda: il modo ingenuo per caricare un file in JavaScript è passare l'intero oggetto File nel body di un fetch, che i browser spesso cercano di bufferizzare in memoria prima di inviare.

Un servizio di trasferimento ben costruito non lo fa mai. Legge il file con File.slice(start, end) per produrre un Blob per ogni chunk di 5-20 MB, carica quel chunk, poi lo rilascia. La memoria resta limitata a circa chunkSize * concurrency byte indipendentemente dalla dimensione del file.

Se il tuo upload inizia bene a 500 MB di progresso e il tab diventa grigio a 2 GB, il servizio sta caricando tutto prima di inviare. Scegli un servizio diverso o un approccio diverso.

Chiudi gli altri tab in modo aggressivo

Chrome condivide un singolo processo renderer per alcuni tab raggruppati (Site Isolation cambia questo, ma la pressione sulla memoria è ancora condivisa a livello di sistema). Un secondo tab che riproduce YouTube in 4K, un terzo con Figma caricato, un quarto con Notion che consuma 800 MB di RAM ciascuno, tutto si somma. Un upload da 10 GB su un laptop con 8 GB di RAM e 12 tab aperti è giocare con il fuoco.

Prima di avviare un upload grande, chiudi Chrome completamente e riapri solo con il tab del servizio di trasferimento. Activity Monitor (macOS) o Task Manager (Windows) dovrebbe mostrare il browser che usa ben meno di 2 GB su quel singolo tab.

Disabilita le estensioni

Ad blocker, estensioni privacy, gestori di password e analizzatori di rete (uBlock Origin, Privacy Badger, LastPass, HTTP Toolkit) si inseriscono tutti nelle richieste di rete. La maggior parte non causa problemi. Alcune, specialmente quelle con codice obsoleto, bufferizzano i body delle richieste per ispezionarli, il che vanifica gli upload in streaming e fa esplodere la memoria.

Testa in una finestra in incognito (le estensioni sono disabilitate per impostazione predefinita). Se l'upload si completa correttamente in incognito, le estensioni sono il problema. Abilitale una alla volta per trovare il colpevole.

Disabilita l'accelerazione hardware quando la GPU è debole

I laptop più vecchi con GPU Intel UHD 620 integrata o simili a volte crashano durante il rendering di un aggiornamento della barra di avanzamento insieme al buffer di lettura file simultaneamente. Le Impostazioni di Chrome > Sistema > "Usa l'accelerazione hardware quando disponibile" può essere disattivata. Questo perde un po' di fluidità per tutto il resto ma stabilizza i grandi upload sui sistemi con memoria limitata.

Allo stesso modo, disabilita la modalità "Memory Saver" di Chrome per il tab di upload, che è nota per scaricare i tab sotto pressione durante l'upload. Fissa il tab o escludilo esplicitamente.

Passa a Firefox per file molto grandi

Firefox gestisce storicamente la File API con budget di memoria più ridotti rispetto a Chromium. Su un upload da 10 GB che crasha Chrome ripetutamente, Firefox spesso completa lo stesso lavoro senza problemi. La differenza non è enorme sui servizi ben costruiti (entrambi gestiscono lo streaming a chunk correttamente), ma sui servizi con implementazioni meno ideali, il modello di memoria conservativo di Firefox è più indulgente.

Anche Safari su macOS è affidabile per gli upload grandi, con la riserva che iOS Safari termina aggressivamente i tab in background.

Fissa il tab in primo piano

I tab in background sono i primi a essere scaricati sotto pressione di memoria. Tieni il tab di upload in primo piano. Non passare a un'altra finestra per 30 minuti e tornare a trovare il tab ricaricato. I tab "eliminati" di Chrome mostrano un placeholder grigio al ritorno, e qualsiasi upload in corso è morto.

Su macOS usa caffeinate -s o disabilita la modalità risparmio energetico di Windows durante l'upload. Un laptop in sleep chiude le connessioni WebSocket e XHR, e non tutti i servizi riescono a riprendere correttamente dopo.

Carica da desktop, non da laptop a batteria

I laptop a batteria limitano CPU e RAM in modo aggressivo. La "Low Power Mode" di macOS e il "Battery Saver" di Windows riducono entrambi la priorità delle attività in background, il che per un tab del browser che sta eseguendo crittografia AES e scritture di rete significa stalli.

Collega il cavo. Disabilita le modalità risparmio batteria. Se il laptop ha una scelta di profili di prestazione della CPU (Dell Power Manager, Lenovo Vantage), imposta su "Performance" per la durata dell'upload.

Riavvia il browser prima di iniziare

Chrome, Firefox e Edge perdono tutti memoria lentamente nel corso di sessioni lunghe. Un browser aperto da due giorni con 40 tab aperti e chiusi può portare 2 GB di memoria zombie prima che tu apra anche solo la pagina di upload. Esci completamente (Cmd+Q, non solo chiudere la finestra, su macOS; clic destro sulla barra delle applicazioni > Esci su Windows) e riapri.

Adatta la dimensione del chunk all'hardware

Per i servizi che consentono di configurare la dimensione del chunk (la maggior parte non lo fa, ma alcuni strumenti CLI come rclone sì), i chunk più piccoli usano meno memoria. Chunk da 5 MB con 4 worker concorrenti è un buffer di 20 MB in qualsiasi momento. Chunk da 100 MB con 4 worker è 400 MB. Su una macchina da 4 GB, la differenza conta.

I servizi web scelgono i valori predefiniti per te, tipicamente da 5 a 20 MB per chunk, che è sensato. Ma gli script personalizzati a volte usano chunk più grandi per "andare più veloci" e falliscono sui computer piccoli.

Monitora la RAM con Activity Monitor durante l'upload

Durante l'upload, osserva la memoria del processo del browser. Activity Monitor di macOS: scheda Memory, filtra per nome del browser. Task Manager di Windows: scheda Details, ordina per "Memory (private working set)."

Un upload a chunk corretto mantiene stabile alcuni centinaia di MB di memoria del browser indipendentemente dall'avanzamento. Se la memoria cresce linearmente con l'avanzamento dell'upload (raggiungendo 5 GB al 50 percento di un file da 10 GB), il servizio sta bufferizzando tutto. Questo è il bug. Trova un servizio diverso.

Usa servizi costruiti per upload grandi dal browser

Un servizio di trasferimento ben ingegnerizzato usa upload a chunk con un pool di Web Worker per la crittografia, memoria limitata e ripetizione esplicita sui chunk falliti. HexaTransfer legge i file tramite File.slice() nei Web Worker, cifra con AES-256-GCM per chunk, e non supera mai alcuni centinaia di MB di memoria del browser indipendentemente dal fatto che tu stia inviando 50 MB o l'intero limite di 10 GB per trasferimento — il che conta quando il tuo browser sta già gestendo tutto il resto della tua giornata.

Provalo su hexatransfer.com — gratis, senza registrazione, fino a 10 GB.