Navegador bloqueia durante o carregamento? Soluções para estabilidade

Se o seu navegador bloqueia a meio de um carregamento, a causa é quase sempre a pressão de memória no separador. O Chrome elimina separadores que excedam cerca de 2 a 4 GB de memória privada, e um serviço de transferência que carrega um ficheiro de 10 GB num único objeto Blob ultrapassa esse limite. Solução: use um serviço que transmite o ficheiro em partes (chunks) através do método slice() da File API (a maioria dos modernos faz-o), feche todos os outros separadores antes de carregar, desative extensões que se ligam ao fetch/XHR, e carregue a partir de um computador de secretária em vez de um portátil a funcionar com bateria. O Firefox tende a lidar com streams grandes da File API com menos sobrecarga de memória do que o Chromium.

Por que os navegadores bloqueiam em carregamentos

Duas realidades arquiteturais colidem. Em primeiro lugar, cada separador do navegador é um processo separado com o seu próprio limite de memória. O Chrome limita cada processo de renderização a cerca de 4 GB em sistemas de 64 bits antes que o OOM killer intervenha. Em segundo lugar, a forma ingénua de carregar um ficheiro em JavaScript é passar o objeto File inteiro para o corpo de um fetch, o que os navegadores frequentemente tentam guardar em memória antes de enviar.

Um serviço de transferência bem construído nunca faz isto. Lê o ficheiro com File.slice(start, end) para produzir um Blob para cada parte de 5 a 20 MB, carrega essa parte e depois liberta-a. A memória fica limitada a aproximadamente tamanhoDaParte * concorrência bytes independentemente do tamanho do ficheiro.

Se o carregamento começa bem a 500 MB de progresso e o separador fica cinzento a 2 GB, o serviço está a carregar tudo antes de enviar. Escolha um serviço diferente ou uma abordagem diferente.

Feche os outros separadores

O Chrome partilha um único processo de renderização para alguns separadores agrupados (o Site Isolation altera isto, mas a pressão de memória ainda é partilhada ao nível do sistema). Um segundo separador a reproduzir YouTube em 4K, um terceiro com o Figma carregado, um quarto com o Notion a consumir 800 MB de RAM cada — tudo soma. Um carregamento de 10 GB num portátil com 8 GB de RAM e 12 separadores abertos é problemático.

Antes de iniciar um carregamento grande, feche completamente o Chrome e reabra-o apenas com o separador do serviço de transferência. O Monitor de Atividade (macOS) ou o Gestor de Tarefas (Windows) deve mostrar o navegador a usar bem menos de 2 GB nesse único separador.

Desative as extensões

Os bloqueadores de anúncios, extensões de privacidade, gestores de palavras-passe e analisadores de rede (uBlock Origin, Privacy Badger, LastPass, HTTP Toolkit) injetam-se nos pedidos de rede. A maioria não causa problemas. Algumas, especialmente as com código desatualizado, guardam os corpos dos pedidos em memória para os inspecionar, o que destrói o streaming de carregamento e excede a memória.

Teste numa janela de navegação privada (as extensões estão desativadas por defeito). Se o carregamento for concluído sem problemas em modo privado, as extensões são o problema. Ative-as uma a uma para encontrar a culpada.

Desative a aceleração de hardware quando a GPU é fraca

Os portáteis mais antigos com GPUs integradas Intel UHD 620 ou similares por vezes bloqueiam a renderizar uma atualização da barra de progresso juntamente com o buffer de leitura do ficheiro. Em Definições > Sistema do Chrome, "Usar aceleração de hardware quando disponível" pode ser desativado. Isto perde alguma fluidez para tudo o resto mas estabiliza os carregamentos grandes em sistemas com memória limitada.

Da mesma forma, desative o modo "Poupança de memória" do Chrome para o separador de carregamento, que já causou problemas ao eliminar separadores sob pressão a meio de um carregamento. Fixe o separador ou exclua-o explicitamente.

Mude para Firefox para ficheiros muito grandes

O Firefox tende historicamente a lidar com a File API com orçamentos de memória mais apertados do que o Chromium. Num carregamento de 10 GB que bloqueia o Chrome repetidamente, o Firefox completa frequentemente o mesmo trabalho sem problemas. A diferença não é grande em serviços bem construídos (ambos lidam bem com streaming fragmentado), mas em serviços com implementações menos ideais, o modelo de memória conservador do Firefox é mais tolerante.

O Safari no macOS também é fiável para carregamentos grandes, com a ressalva de que o Safari no iOS encerra agressivamente os separadores em segundo plano.

Mantenha o separador em primeiro plano

Os separadores em segundo plano são os primeiros a ser eliminados sob pressão de memória. Mantenha o separador de carregamento em primeiro plano. Não mude para outra janela durante 30 minutos e volte para encontrar o separador recarregado. Os separadores "descartados" do Chrome mostram um marcador de posição cinzento ao regressar, e qualquer carregamento em curso está perdido.

Use caffeinate no macOS (caffeinate -s) ou desative o modo de suspensão de poupança de energia do Windows durante o carregamento. Um portátil em suspensão fecha as ligações WebSocket e XHR, e nem todos os serviços conseguem retomar de forma limpa depois.

Carregue a partir de computador com tomada ligada

Os portáteis a funcionar com bateria limitam a CPU e a RAM de forma agressiva. O "Modo de Baixo Consumo" do macOS e a "Poupança de Bateria" do Windows reduzem a prioridade das tarefas em segundo plano, o que para um separador do navegador a fazer encriptação AES e escritas de rede significa bloqueios.

Ligue à tomada. Desative os modos de poupança de bateria. Se o portátil tem perfis de desempenho da CPU (Dell Power Manager, Lenovo Vantage), defina para "Desempenho" durante o carregamento.

Reinicie o navegador antes de começar

O Chrome, o Firefox e o Edge apresentam fugas de memória lentamente ao longo de sessões longas. Um navegador que esteve aberto dois dias com 40 separadores abertos e fechados pode ter 2 GB de memória "fantasma" antes de sequer abrir a página de carregamento. Feche completamente (Cmd+Q, não apenas fechar a janela, no macOS; clique com o botão direito na barra de tarefas > Sair no Windows) e reabra.

Ajuste o tamanho dos chunks ao hardware

Para serviços que permitem configurar o tamanho dos chunks (a maioria não, mas algumas ferramentas de linha de comandos como o rclone permitem), chunks menores usam menos memória. Chunks de 5 MB com 4 workers concorrentes são 20 MB de buffer em qualquer momento. Chunks de 100 MB com 4 workers são 400 MB. Numa máquina com 4 GB, a diferença é significativa.

Os serviços baseados na web escolhem os valores por defeito, tipicamente na gama de 5 a 20 MB por chunk, o que é sensato. Mas os scripts personalizados por vezes usam chunks maiores por defeito para "ser mais rápido", e falham em máquinas com menos recursos.

Monitorize a RAM no Monitor de Atividade durante o carregamento

Durante o carregamento, observe a memória do processo do navegador. Monitor de Atividade do macOS: separador Memória, filtre pelo nome do navegador. Gestor de Tarefas do Windows: separador Detalhes, ordene por "Memória (conjunto de trabalho privado)".

Um carregamento fragmentado saudável mantém-se estável em algumas centenas de MB de memória do navegador independentemente do progresso. Se a memória sobe linearmente com o progresso do carregamento (chegando a 5 GB a 50% de um ficheiro de 10 GB), o serviço está a guardar tudo em memória. Esse é o problema. Escolha um serviço diferente.

Use serviços concebidos para carregamentos grandes no navegador

Um serviço de transferência bem concebido usa carregamentos fragmentados com um conjunto de Web Workers para encriptação, memória limitada e repetição explícita em chunks falhados. O HexaTransfer lê ficheiros via File.slice() em Web Workers, encripta com AES-256-GCM por chunk e nunca excede algumas centenas de MB de memória do navegador, quer esteja a enviar 50 MB ou o limite completo de 10 GB por transferência — o que importa quando o seu navegador já está a lidar com tudo o resto do seu dia.

Experimente em hexatransfer.com — gratuito, sem conta, até 10 GB.