Se uma aplicação ainda depende de unload para salvar estado, encerrar recursos ou enviar analytics, a migração deixou de ser apenas preventiva. O cronograma oficial do Chrome, atualizado em 14 de julho de 2026, prevê que o Chrome 152 alcance 80% das cargas de página em 25 de agosto e que o Chrome 154 leve a desativação padrão de unload a 100% das cargas de página no rollout geral em 22 de setembro de 2026. A própria documentação ressalva que versões e datas podem mudar conforme o impacto observado.
Esse “100%” não significa que o evento foi removido da plataforma nem que todos os usuários serão afetados de uma vez. Significa que, no rollout geral descrito pelo Chrome, a mudança de padrão passa a abranger 100% das cargas de página: handlers de unload deixam de disparar por padrão, salvo quando o site usa um mecanismo de opt-in temporário. A migração recomendada é abandonar a dependência do evento, não transformar o opt-in em solução permanente. A referência principal é a documentação de descontinuação do unload no Chrome.
O que muda no Chrome 154
O Chrome iniciou em 2026 a expansão da descontinuação para todas as origens. A tabela pública passa por 1%, 5%, 10%, 20%, 40%, 60% e 80% até o Chrome 152; a etapa seguinte publicada é o Chrome 154, com 100% em 22 de setembro. Não há uma etapa de rollout do Chrome 153 na tabela atual.
Na prática, código que trata unload como callback garantido passa a falhar de modo mais visível. Isso é especialmente perigoso quando o handler contém uma tarefa que o produto considera obrigatória, como gravar o último estado de um formulário, marcar o fim de uma sessão ou enviar um lote final de telemetria.
O problema não nasceu com o Chrome 154. O evento já era pouco confiável, sobretudo em dispositivos móveis, porque páginas podem ser colocadas em segundo plano, congeladas ou encerradas sem uma sequência clássica de “saída”. Além disso, handlers de unload prejudicam o uso do back/forward cache, ou bfcache, que permite restaurar páginas rapidamente ao navegar para trás ou para frente.
Primeiro passo: encontre todas as dependências de unload
Comece pelo repositório, mas não pare nele. Procure por unload, onunload e registros equivalentes em addEventListener. Revise código próprio, bundles gerados e integrações de terceiros que possam registrar o evento em runtime.
- Classifique cada ocorrência por função: persistência, telemetria, limpeza de recursos, aviso ao usuário ou código legado sem efeito claro.
- Identifique se o handler executa chamadas de rede, gravações em storage, fechamento de conexões ou mutações globais.
- Verifique bibliotecas de analytics, widgets e tags carregadas fora do bundle principal.
- Use o teste de Back/forward cache no Chrome DevTools para detectar listeners que tornam a página inelegível ao bfcache.
- Em produção, a Reporting API e a propriedade notRestoredReasons podem ajudar a localizar uso de unload e motivos de não restauração do bfcache.
A ausência de “unload” no código-fonte da aplicação não prova que a página está livre dele. Um script de terceiros pode adicionar o listener depois do carregamento, por isso a auditoria em runtime é importante.
Qual alternativa usar em cada caso
| Caso de uso | Substituição principal | Cuidado de implementação |
|---|---|---|
| Salvar rascunho ou estado local | visibilitychange quando o documento fica hidden, combinado com salvamento incremental | Não espere um “último evento” para persistir tudo; torne a operação repetível e barata. |
| Enviar analytics ou telemetria | visibilitychange + navigator.sendBeacon(); use fetch com keepalive quando precisar de mais controle | Evite duplicidade, porque uma página pode ficar hidden mais de uma vez ou ser restaurada. |
| Detectar navegação para outra página | pagehide | O evento também pode preceder entrada no bfcache; não assuma destruição definitiva do documento. |
| Liberar e depois restaurar recursos | pagehide e pageshow | Se a página voltar do bfcache, reative o que foi suspenso ou limpo. |
| Avisar sobre alterações não salvas | beforeunload, apenas de forma condicional | Use somente enquanto houver mudanças realmente não salvas; ele também não é garantia contra encerramento em segundo plano. |
Persistência: salve antes do ponto de não retorno
Para formulários, editores e estados de interface, a recomendação do Chrome é tratar a transição para hidden em visibilitychange como o último momento confiável para salvar dados do app e do usuário. Isso funciona melhor quando o sistema já faz salvamentos incrementais durante a interação, em vez de concentrar toda a responsabilidade no encerramento da página.
O objetivo é transformar “salvar ao sair” em “manter o estado suficientemente atualizado”. Assim, se o processo do navegador for encerrado sem outro evento, a perda potencial fica limitada ao menor intervalo possível.
Analytics: separe fim de sessão de envio confiável
Para telemetria pequena, navigator.sendBeacon() foi projetado para enviar dados assíncronos sem bloquear a próxima navegação. A documentação da MDN recomenda acioná-lo na transição para hidden. Quando a requisição exige método diferente de POST, cabeçalhos específicos ou mais controle, fetch com a opção keepalive pode ser mais adequado. Consulte a referência de sendBeacon.
Não trate cada visibilitychange como um “fim definitivo de sessão”. O usuário pode alternar de aba e voltar. Adote identificadores de evento, checkpoints ou deduplicação no servidor para não inflar métricas.
Limpeza: pagehide não significa destruição definitiva
pagehide é indicado para detectar que a página está sendo deixada, mas ele é compatível com bfcache. Se a página entrar no cache de navegação, seu estado poderá ser restaurado depois. Por isso, qualquer limpeza que torne a aplicação incapaz de continuar precisa de uma etapa complementar em pageshow. A Page Lifecycle API documenta os estados e os eventos envolvidos.
Como migrar sem trocar um bug por outro
- Extraia a lógica do handler. Separe a tarefa real do gatilho “unload”. Uma função de salvar, enviar telemetria ou suspender recursos deve poder ser chamada por outro evento.
- Torne a operação idempotente. visibilitychange pode ocorrer várias vezes. Uma mesma ação repetida não deve duplicar pedidos, eventos de analytics ou gravações incompatíveis.
- Escolha o evento pelo significado. Use visibilitychange para persistência e telemetria de encerramento provável; pagehide para saída de página; pageshow para restauração; beforeunload apenas para avisos de alterações não salvas.
- Trate restauração do bfcache. Em pageshow, a propriedade persisted indica que a página foi restaurada do cache. Reavalie dados que precisam ser atualizados e recursos que foram suspensos.
- Teste com o unload já desativado. Não valide apenas no comportamento atual do navegador.
Como testar agora, antes de 22 de setembro
O Chrome oferece formas de antecipar o comportamento futuro. A opção chrome://flags/#deprecate-unload, quando habilitada conforme a documentação, antecipa o padrão de descontinuação e permite testar a aplicação com handlers de unload deixando de disparar. A Permissions Policy também pode ser usada para controlar o acesso ao evento por página ou site. Esses mecanismos servem para teste e contingência, não para manter a dependência indefinidamente.
Monte uma matriz mínima de regressão:
- navegação interna e navegação para outro domínio;
- voltar e avançar no histórico;
- recarregar a página;
- fechar a aba;
- alternar de aba, minimizar o navegador e, em mobile, alternar de aplicativo;
- restaurar uma página pelo bfcache;
- simular conexão lenta ou offline durante autosave e telemetria.
O objetivo não é provar que existe um novo “evento final garantido”. O objetivo é mostrar que o sistema continua consistente mesmo quando a página deixa de receber um callback de encerramento.
bfcache: a migração pode mudar performance e analytics
Remover listeners de unload pode tornar mais páginas elegíveis ao bfcache. Isso tende a melhorar a experiência de voltar e avançar, mas também muda a forma como o ciclo de vida é observado: uma restauração do bfcache recupera a página existente, inclusive o heap JavaScript, em vez de executar um carregamento completo.
Para analytics, isso significa que uma restauração pode não gerar automaticamente o mesmo pageview de um carregamento novo. O Chrome recomenda observar pageshow e verificar event.persisted quando o produto precisa contabilizar restaurações. Para estado de dados, avalie se algum conteúdo deve ser revalidado após a restauração. Veja também a orientação de bfcache do web.dev.
beforeunload não é substituto geral
beforeunload continua existindo porque resolve um problema diferente: permitir um aviso cancelável quando o usuário tenta sair com alterações não salvas. Ele não deve substituir unload para analytics, persistência ou limpeza. A orientação do Chrome é adicioná-lo apenas quando houver mudanças não salvas e removê-lo assim que elas forem persistidas.
Também não é uma garantia de execução quando uma aba em segundo plano é encerrada. Portanto, mesmo em editores que usam beforeunload como rede de segurança para UX, o salvamento real deve acontecer antes.
Checklist para chegar ao Chrome 154 sem depender de unload
- Nenhum fluxo crítico depende de um callback final de unload.
- Rascunhos e estado importante são persistidos incrementalmente e no visibilitychange para hidden.
- Telemetria usa sendBeacon ou fetch keepalive quando apropriado e possui deduplicação.
- Limpeza ligada a pagehide pode ser revertida ou reativada em pageshow.
- beforeunload só existe enquanto há alterações realmente não salvas.
- O site foi testado com a descontinuação antecipada e com back/forward cache no DevTools.
- Restaurações via bfcache foram consideradas nos dados e no analytics.
- Qualquer opt-in para continuar usando unload é tratado como contingência temporária, com plano de retirada.
Com o estágio de 100% previsto para 22 de setembro de 2026, o risco maior não é o desaparecimento de uma API isolada: é descobrir tarde demais que uma rotina de persistência ou telemetria dependia de um evento que nunca foi confiável. A migração segura distribui essas responsabilidades ao longo do ciclo de vida da página e testa explicitamente navegação, segundo plano e restauração.
