Browser crasht tijdens upload? Oplossingen voor stabiliteit

Als je browser halverwege een upload crasht, is de oorzaak bijna altijd geheugendruk op het tabblad. Chrome beëindigt tabbladen die ruwweg 2 tot 4 GB privégeheugen overschrijden, en een overdrachtsdienst die een bestand van 10 GB in één Blob-object laadt, schiet ver voorbij dat plafond. Oplossing: gebruik een dienst die het bestand in chunks streamt via de slice()-methode van de File API (de meeste moderne diensten doen dit), sluit alle andere tabbladen voor het uploaden, schakel extensies uit die zich koppelen aan fetch/XHR, en upload op een desktop in plaats van een laptop op batterij. Firefox verwerkt grote File API-streams doorgaans met minder geheugenoverhead dan Chromium.

Waarom browsers crashen bij uploads

Twee architecturele realiteiten botsen. Ten eerste is elk browsertabblad een apart proces met een eigen geheugenplafond. Chrome begrenst elk renderer-proces op ongeveer 4 GB op 64-bits systemen voordat de OOM-killer ingrijpt. Ten tweede is de naïeve manier om een bestand te uploaden in JavaScript het doorgeven van het volledige File-object aan een fetch-body, wat browsers vaak proberen te bufferen in geheugen vóór het verzenden.

Een goed gebouwde overdrachtsdienst doet dit nooit. Het leest het bestand via File.slice(start, end) om een Blob te produceren voor elke chunk van 5 tot 20 MB, uploadt die chunk en geeft het geheugen vrij. Het geheugen blijft begrensd op ruwweg chunkGrootte * gelijktijdigheid bytes ongeacht de bestandsgrootte.

Als je upload prima begint bij 500 MB voortgang en het tabblad grijs wordt bij 2 GB, laadt de dienst het hele bestand voor het verzenden. Kies een andere dienst of een andere aanpak.

Sluit andere tabbladen agressief

Chrome deelt één renderer-proces voor sommige gegroepeerde tabbladen (Site Isolation verandert dit, maar geheugendruk is nog steeds gedeeld op systeemniveau). Een tweede tabblad dat YouTube in 4K afspeelt, een derde met Figma geladen, een vierde met Notion dat 800 MB RAM verbruikt — dat telt allemaal op. Een upload van 10 GB op een laptop met 8 GB RAM en 12 open tabbladen is vragen om problemen.

Sluit Chrome volledig voor een grote upload en heropen het met alleen het tabblad van de overdrachtsdienst. Activiteitsmonitor (macOS) of Taakbeheer (Windows) moet laten zien dat de browser ruim onder 2 GB zit op dat ene tabblad.

Schakel extensies uit

Advertentieblokkers, privacy-extensies, wachtwoordmanagers en netwerkanalysatoren (uBlock Origin, Privacy Badger, LastPass, HTTP Toolkit) injecteren allemaal in netwerkverzoeken. De meeste veroorzaken geen problemen. Sommige, met name die met verouderde code, bufferen verzoekbodies om ze te inspecteren, wat streaming-uploads tenietdoet en geheugen opblaast.

Test in een incognito-venster (extensies zijn standaard uitgeschakeld). Als de upload schoon voltooit in incognito, zijn extensies het probleem. Schakel ze één voor één in om de dader te vinden.

Schakel hardwareversnelling uit bij zwakke GPU

Oudere laptops met geïntegreerde Intel UHD 620 of vergelijkbare GPU's crashen soms bij het tegelijkertijd renderen van een voortgangsbalkupdate en de bestandslesebuffer. Chrome's Instellingen > Systeem > "Hardwareversnelling gebruiken indien beschikbaar" kan worden uitgeschakeld. Dit verliest wat soepelheid voor al het andere maar stabiliseert grote uploads op geheugenbeperkte systemen.

Schakel ook Chrome's "Geheugenbespaarder"-modus uit voor het uploadtabblad, wat bekendstaat tabbladen onder druk te verwijderen midden in een upload. Maak het tabblad vast of sluit het expliciet uit.

Schakel over naar Firefox voor zeer grote bestanden

Firefox verwerkt de File API historisch met strakker geheugenbudget dan Chromium. Een upload van 10 GB die Chrome herhaaldelijk laat crashen, voltooit Firefox vaak probleemlos. Het verschil is niet enorm bij goed gebouwde diensten (beide verwerken chunked streaming prima), maar bij diensten met minder ideale implementaties is Firefox's conservatief geheugenmodel vergevingsgezinder.

Safari op macOS is ook betrouwbaar voor grote uploads, met het voorbehoud dat iOS Safari achtergrondtabbladen agressief beëindigt.

Houd het tabblad vastgespeld en op de voorgrond

Achtergrondtabbladen worden als eerste verwijderd onder geheugendruk. Houd het uploadtabblad op de voorgrond. Wissel niet 30 minuten naar een ander venster en kom terug om te zien dat het tabblad is herladen. Chrome's "verwijderde" tabbladen tonen een grijs plaatshouder bij terugkeer, en elke upload in uitvoering is dan gestopt.

Gebruik caffeinate op macOS (caffeinate -s) of schakel Windows' energiebesparende slaapstand uit tijdens de upload. Een slapende laptop sluit WebSocket- en XHR-verbindingen, en niet elke dienst kan daarna schoon hervatten.

Upload vanaf desktop, niet laptop op batterij

Laptops op batterijstroom throttelen CPU en RAM agressief. macOS's "Energiebesparende modus" en Windows' "Batterijbespaarder" verlagen beide de prioriteit van achtergrondtaken, wat voor een browsertabblad dat AES-versleuteling en netwerkschrijven doet, betekent: stagnatie.

Sluit in. Schakel energiespaarstand uit. Als de laptop CPU-prestatieprofielen heeft (Dell Power Manager, Lenovo Vantage), stel die in op "Prestaties" voor de duur van de upload.

Herstart de browser voor je begint

Chrome, Firefox en Edge lekken alle langzaam geheugen tijdens lange sessies. Een browser die twee dagen open is geweest met 40 geopende en gesloten tabbladen kan 2 GB zombiegeheugen dragen voordat je ook maar de uploadpagina opent. Sluit volledig af (Cmd+Q, niet alleen het venster sluiten, op macOS; rechts klik taakbalk > Afsluiten op Windows) en heropen.

Controleer RAM via Activiteitsmonitor tijdens het uploaden

Bekijk tijdens de upload het geheugen van het browserproces. macOS Activiteitsmonitor: tabblad Geheugen, filter op browsernaam. Windows Taakbeheer: tabblad Details, sorteer op "Geheugen (private working set)".

Een gezonde chunked upload houdt het browsergeheugen stabiel op een paar honderd MB, ongeacht de voortgang. Als geheugen lineair stijgt met uploadvoortgang (5 GB bij 50 procent van een bestand van 10 GB), buffert de dienst alles. Dat is de bug. Zoek een andere dienst.

Gebruik diensten gebouwd voor grote browser-uploads

Een goed ontworpen overdrachtsdienst gebruikt chunked uploads met een Web Worker-pool voor versleuteling, begrensd geheugen en expliciete herpoging bij mislukte chunks. HexaTransfer leest bestanden via File.slice() in Web Workers, versleutelt met AES-256-GCM per chunk, en overschrijdt nooit een paar honderd MB browsergeheugen, ongeacht of je 50 MB of het volledige plafond van 10 GB verstuurt — wat telt wanneer je browser al alles verwerkt wat je dag op je afstuur.

Probeer het op hexatransfer.com — gratis, zonder account, tot 10 GB.