Браузер падает при загрузке? Решения для стабильных передач

Если браузер падает в середине загрузки, причина почти всегда — нехватка памяти во вкладке. Chrome уничтожает вкладки, превысившие примерно 2–4 ГБ собственной памяти, а сервис передачи, загружающий 10-гигабайтный файл в единственный Blob-объект, с лёгкостью превышает этот порог. Решение: используйте сервис, который передаёт файл по частям через метод slice() File API (большинство современных так и делает), закройте все остальные вкладки перед загрузкой, отключите расширения, перехватывающие fetch/XHR, и загружайте с десктопа, а не с ноутбука на батарее. Firefox, как правило, справляется с большими потоками File API, потребляя меньше памяти, чем Chromium.

Почему браузеры падают при загрузке

Сталкиваются два архитектурных ограничения. Во-первых, каждая вкладка браузера — отдельный процесс со своим потолком памяти. Chrome ограничивает каждый процесс рендеринга примерно 4 ГБ на 64-битных системах, прежде чем вмешается OOM-killer. Во-вторых, наивный способ загрузить файл в JavaScript — передать весь объект File в тело fetch, а браузеры нередко буферизуют его в памяти перед отправкой.

Хорошо написанный сервис передачи так не делает. Он читает файл через File.slice(start, end), чтобы получить Blob для каждого фрагмента по 5–20 МБ, отправляет его, затем освобождает память. Занятый объём остаётся ограниченным примерно chunkSize * concurrency байтами независимо от размера файла.

Если загрузка идёт нормально до 500 МБ, а вкладка серее при 2 ГБ — сервис загружает всё целиком перед отправкой. Выберите другой сервис или другой подход.

Закрывайте остальные вкладки

Chrome иногда объединяет вкладки в один процесс рендеринга, хотя Site Isolation изменяет это поведение; нагрузка на память всё равно суммируется на уровне системы. Вторая вкладка с YouTube в 4K, третья с Figma, четвёртая с Notion, каждая потребляющая по 800 МБ, — это большая нагрузка. Загрузка 10 ГБ на ноутбуке с 8 ГБ RAM и 12 открытыми вкладками — опасная игра.

Перед крупной загрузкой закройте Chrome полностью и откройте только вкладку с нужным сервисом. Activity Monitor (macOS) или Диспетчер задач (Windows) должны показывать, что браузер занимает не более 2 ГБ на этой единственной вкладке.

Отключайте расширения

Блокировщики рекламы, расширения конфиденциальности, менеджеры паролей и анализаторы сети (uBlock Origin, Privacy Badger, LastPass, HTTP Toolkit) встраиваются в сетевые запросы. Большинство не создаёт проблем. Некоторые, особенно с устаревшим кодом, буферизуют тела запросов для их проверки, что сводит на нет потоковую загрузку и переполняет память.

Проверьте в режиме инкогнито (расширения там отключены по умолчанию). Если загрузка завершилась без проблем — виноваты расширения. Включайте их по одному, чтобы найти виновника.

Отключайте аппаратное ускорение на слабом GPU

На старых ноутбуках с интегрированным Intel UHD 620 или похожими GPU иногда происходят сбои при одновременном обновлении индикатора прогресса и чтении буфера файла. В Chrome: Настройки > Система > «Использовать аппаратное ускорение (при наличии)» — этот параметр можно отключить. Всё остальное немного теряет плавность, но крупные загрузки на системах с ограниченной памятью становятся стабильнее.

Также отключите режим «Memory Saver» Chrome для вкладки с загрузкой — он может сбросить вкладку под давлением памяти прямо в процессе. Закрепите вкладку или явно исключите её.

Переходите на Firefox для очень больших файлов

Firefox исторически управляет File API с более жёсткими бюджетами памяти, чем Chromium. При загрузке 10 ГБ, которая раз за разом падает в Chrome, Firefox нередко справляется с той же задачей без лишних проблем. Разница невелика на хорошо написанных сервисах (оба нормально справляются с потоковой передачей по частям), но на сервисах с не идеальной реализацией консервативная модель памяти Firefox оказывается снисходительнее.

Safari на macOS также стабилен при крупных загрузках, с оговоркой: iOS Safari агрессивно завершает фоновые вкладки.

Держите вкладку на переднем плане

Фоновые вкладки первыми выгружаются при нехватке памяти. Держите вкладку с загрузкой активной. Не переключайтесь на другое окно на 30 минут и не возвращайтесь к обнаруженной перезагруженной вкладке. «Выгруженные» вкладки Chrome показывают серую заглушку при возврате, и любая незавершённая загрузка на них потеряна.

Caffeinate на macOS (caffeinate -s) или отключение режима сна Windows на время загрузки. Ноутбук в режиме сна закрывает соединения WebSocket и XHR, и не каждый сервис умеет возобновлять их корректно.

Загружайте с десктопа, а не с ноутбука на батарее

Ноутбуки на батарее агрессивно ограничивают CPU и RAM. «Low Power Mode» в macOS и «Battery Saver» в Windows снижают приоритет фоновых задач — для вкладки браузера, выполняющей AES-шифрование и сетевую запись, это означает задержки.

Подключите ноутбук к питанию. Отключите режим экономии батареи. Если ноутбук поддерживает профили производительности (Dell Power Manager, Lenovo Vantage), установите «Производительность» на время загрузки.

Перезапускайте браузер перед началом

Chrome, Firefox и Edge медленно утекают по памяти в длинных сессиях. Браузер, открытый два дня с 40 вкладками, может уже занимать 2 ГБ «зомби-памяти» ещё до открытия страницы загрузки. Полностью закройте браузер (Cmd+Q, не просто окно, на macOS; правая кнопка на панели задач > Выход в Windows) и перезапустите.

Согласовывайте размер фрагмента с оборудованием

Для сервисов, позволяющих настраивать размер фрагмента (большинство не позволяет, но некоторые CLI-инструменты, например rclone, дают такую возможность), меньшие фрагменты занимают меньше памяти. Фрагменты по 5 МБ при 4 параллельных потоках — это 20 МБ буфера одновременно. Фрагменты по 100 МБ при 4 потоках — уже 400 МБ. На машине с 4 ГБ RAM разница критична.

Веб-сервисы выбирают настройки по умолчанию сами, обычно 5–20 МБ на фрагмент. Но пользовательские скрипты иногда используют крупные фрагменты ради скорости — и падают на маломощных машинах.

Следите за памятью в Activity Monitor во время загрузки

В процессе загрузки наблюдайте за памятью процесса браузера. Activity Monitor на macOS: вкладка «Память», фильтр по имени браузера. Диспетчер задач Windows: вкладка «Подробности», сортировка по «Память (частный рабочий набор)».

При корректной потоковой загрузке по частям занятая браузером память остаётся стабильной на уровне нескольких сотен МБ независимо от прогресса. Если память растёт линейно вместе с прогрессом (достигает 5 ГБ при 50% загрузки 10-гигабайтного файла) — сервис буферизует всё. Это баг. Найдите другой сервис.

Используйте сервисы, созданные для больших браузерных загрузок

Грамотно спроектированный сервис передачи использует загрузку по частям с пулом Web Workers для шифрования, ограниченную память и явный повтор при ошибке фрагмента. HexaTransfer читает файлы через File.slice() в Web Workers, шифрует каждый фрагмент с помощью AES-256-GCM и никогда не превышает нескольких сотен МБ памяти браузера — независимо от того, отправляете ли вы 50 МБ или полные 10 ГБ.

Попробуйте на hexatransfer.com — бесплатно, без регистрации, до 10 ГБ.