O evento unload será descontinuado gradualmente, mudando o padrão gradualmente para que os gerenciadores unload parem de disparar nas páginas, a menos que uma página aceite explicitamente reativá-los.
Cronograma de descontinuação
Observamos que o comportamento de descarregamento provavelmente estaria sujeito a mudanças a partir de janeiro de 2019, quando anunciamos nossa intenção de implementar um cache de avanço e retorno. Em paralelo ao trabalho de implementação, realizamos uma grande divulgação que resultou em uma queda significativa no uso de descarregamento. Para complementar esse contato, também começamos a oferecer maneiras de testar o efeito da descontinuação do descarregamento do Chrome 115:
- Em teste com a APIPermission-Policy para descarregamento no Chrome 115 (julho de 2023)
- Teste local ativando uma sinalização no Chrome 117 (setembro de 2023)
Após as fases de contato e teste, veja como esperamos que a suspensão de uso gradual seja lançada:
- Uma fase com escopo em que o descarregamento vai deixar de funcionar gradualmente para os 50 sites mais acessados (referência no momento da redação deste artigo).
- Começando com 1% dos usuários do Chrome 120 (final de novembro de 2023).
- Encerrar com 100% dos usuários até o fim do terceiro trimestre de 2024
- Além disso, a partir do terceiro trimestre de 2024, planejamos iniciar uma fase genérica em que o descarregamento vai deixar de funcionar gradualmente em qualquer site, começando com 1% dos usuários e terminando com 100% deles até o final do primeiro trimestre de 2025.
Também oferecemos um menu de opções de desativação caso esse cronograma de descontinuação gradual não forneça tempo suficiente para deixar de ser usado no descarregamento. Nossa meta é usar essa suspensão temporária de descontinuação para definir o cronograma da última fase (descontinuação pesada de descarregamento) em que essas recusas serão removidas ou reduzidas.
Contexto
unload foi projetado para ser acionado quando o documento estiver sendo descarregado. Em teoria, ele pode ser usado para executar um código sempre que um usuário estiver navegando para fora de uma página ou como um callback de fim de sessão.
Os cenários em que esse evento foi mais usado incluem:
- Salvar dados do usuário: salve os dados antes de sair da página.
- Executar tarefas de limpeza: fechar recursos abertos antes de abandonar a página.
- Enviar análises: enviar dados relacionados às interações dos usuários no final da sessão.
No entanto, o evento unload é extremamente não confiável.
No Chrome e no Firefox para computadores, o unload é razoavelmente confiável, mas causa um impacto negativo no desempenho de um site, impedindo o uso do bfcache (cache de avanço e retorno).
Em navegadores para dispositivos móveis, o unload geralmente não é executado, já que as guias frequentemente ficam em segundo plano e depois eliminadas. Por esse motivo, os navegadores optam por priorizar o bfcache em dispositivos móveis em vez de unload, o que os torna ainda mais confiáveis. O Safari também usa esse comportamento no computador.
A equipe do Chrome acredita que usar o modelo para dispositivos móveis de priorizar o bfcache em vez de unload no computador poderia causar interrupções, tornando-o mais não confiável nesse local também, quando antes era razoavelmente confiável no Chrome (e no Firefox). Em vez disso, o objetivo do Chrome é remover completamente o evento unload. Até lá, ela vai continuar confiável no computador para as pessoas que recusaram explicitamente a descontinuação.
Por que suspender o uso do evento unload?
A descontinuação do unload é uma etapa fundamental para um reconhecimento muito maior da Web em que vivemos atualmente. O evento unload oferece uma falsa sensação de controle do ciclo de vida do app, que é cada vez mais falsa em relação à forma como navegamos na Web no mundo da computação moderna.
Os sistemas operacionais para dispositivos móveis frequentemente congelam ou descarregam páginas da Web para economizar memória, e os navegadores de computador estão fazendo isso cada vez mais pelos mesmos motivos. Mesmo sem intervenções do sistema operacional, os próprios usuários costumam alternar guias e encerram guias antigas sem "sair das páginas formalmente".
Remover o evento unload como obsoleto é um reconhecimento de que nós, como desenvolvedores Web, precisamos garantir que nosso paradigma corresponda ao do mundo real, e não dependa de conceitos desatualizados que não são mais verdadeiros, caso isso aconteça.
Alternativas para eventos unload
Em vez de unload, é recomendável usar:
visibilitychange: para determinar quando a visibilidade de uma página muda. Esse evento acontece quando o usuário troca de guia, minimiza a janela do navegador ou abre uma nova página. Considere o estadohiddencomo o último momento confiável para salvar dados do app e do usuário.pagehide: para determinar quando o usuário saiu da página. Esse evento acontece quando o usuário sai da página, recarrega a página ou fecha a janela do navegador. O eventopagehidenão é disparado quando a página é simplesmente minimizada ou muda para outra guia. Comopagehidenão desqualifica a página para o cache de avanço e retorno, é possível que ela seja restaurada depois que esse evento for disparado. Se você estiver limpando recursos neste evento, talvez eles precisem ser restaurados na restauração da página.
O evento beforeunload tem um caso de uso um pouco diferente de unload, porque é cancelável. Geralmente, ele é usado para avisar os usuários sobre alterações não salvas quando eles saem da página. Esse evento também não é confiável, porque não será disparado se uma guia em segundo plano for eliminada. É recomendável limitar o uso de beforeunload e só adicioná-lo condicionalmente. Em vez disso, use os eventos acima para a maioria das substituições de unload.
Para mais detalhes, consulte esta dica sobre como nunca usar o gerenciador unload.
Detectar o uso de unload
Existem ferramentas diferentes para ajudar a encontrar aparências do evento unload nas páginas. Isso permite que os sites descubram se estão usando esse evento (no próprio código ou em bibliotecas) e, portanto, pode ser afetado pela futura descontinuação.
Chrome DevTools
O Chrome DevTools inclui uma auditoria back-forward-cache para ajudar a identificar problemas que podem impedir a qualificação da página para o cache de avanço e retorno, incluindo o uso do gerenciador unload.
Para testar o cache de avanço e retorno, siga estas etapas:
Na página, abra o DevTools e navegue até Aplicativo > Serviços em segundo plano > Cache de avanço e retorno.
Clique em Testar o cache de avanço e retorno. O Chrome leva você automaticamente para
chrome://terms/e de volta à página. Se preferir, você pode clicar nos botões "Voltar" e "Avançar" do navegador.
Caso sua página não esteja qualificada para o armazenamento em cache de avanço e retorno, a guia Cache de avanço e retorno vai mostrar uma lista de problemas. Em Acionável, confira se você está usando unload:
API Reporting
A API Reporting pode ser usada em conjunto com uma política de permissão somente leitura para detectar o uso de unload pelos usuários do seu site.
Para mais detalhes, consulte Como usar a API Reporting para encontrar descarregamentos.
API Bfcache notRestoredReasons
A propriedade notRestoredReasons, adicionada à classe PerformanceNavigationTiming, informa se os documentos foram impedidos de usar o bfcache na navegação e o motivo. As instruções de uso podem ser encontradas aqui. Este é um exemplo de como é o aviso do objeto de resposta de um listener unload existente:
{
children: [],
id: null,
name: null,
reasons: [
{"reason", "unload-handler"}
],
src: null,
url: "https://www.example.com/page/"
}
Controlar o acesso a unload
O Chrome vai descontinuar o evento unload gradualmente. Enquanto isso, use ferramentas diferentes para controlar esse comportamento e se preparar para a futura descontinuação. Lembre-se de que você não deve confiar nessas técnicas a longo prazo e deve planejar migrar para as alternativas o mais rápido possível.
As opções a seguir permitem que você ative ou desative os gerenciadores de unload para testar como seu site funcionaria sem eles e se preparar para a futura descontinuação. Há diferentes tipos de políticas:
- Política de permissões: esta é uma API de plataforma para que os proprietários de sites controlem o acesso a recursos no nível do site ou de uma página individual por meio do uso de cabeçalhos HTTP.
- Políticas corporativas: ferramentas para os administradores de TI configurarem o Chrome para a organização ou empresa. Eles podem ser configurados em um painel de administração, como o Google Admin Console.
- Sinalizações do Chrome: permitem que um desenvolvedor específico mude a configuração de descontinuação do
unloadpara testar o impacto em vários sites.
Política de permissões
Uma política de permissões foi adicionada a partir do Chrome 115 para permitir que os sites desativem o uso de gerenciadores unload e se beneficiem imediatamente do bfcache para melhorar o desempenho do site. Veja estes exemplos sobre como definir isso para seu site. Isso permite que os sites fiquem à frente da descontinuação do unload.
Isso será estendido no Chrome 117 para permitir que os sites façam o inverso e ativem a opção de continuar a tentar disparar gerenciadores unload, já que o Chrome muda o padrão para que eles não sejam disparados no futuro. Veja estes exemplos sobre como continuar permitindo que gerenciadores de descarregamento sejam disparados para seu site. Essa ativação não será permanente e será usada para permitir que os sites migrem dos gerenciadores unload.
Política corporativa
As empresas que têm software que depende do evento unload para funcionar corretamente podem usar a política ForcePermissionPolicyUnloadDefaultEnabled para evitar a descontinuação gradual dos dispositivos sob controle. Se a política for ativada, o unload vai continuar ativado por padrão para todas as origens. Uma página ainda poderá definir uma política mais rígida se quiser. Assim como a desativação da política de permissões, essa é uma ferramenta para reduzir possíveis alterações interruptivas, mas não pode ser usada indefinidamente.
Sinalizações do Chrome e chaves de linha de comando
Além da política corporativa, você pode desativar a descontinuação para usuários individuais com as chaves de linhas de comando e sinalizações do Chrome:
Definir chrome://flags/#deprecate-unload como enabled trará o padrão de descontinuação e impedirá que os gerenciadores unload sejam disparados. Elas ainda podem ser substituídas para cada site pela política de permissões, mas continuarão a ser disparadas por padrão.
Essas configurações também podem ser controladas por chaves de linha de comando.
Comparação de opções
A tabela a seguir resume os diferentes usos das opções discutidas anteriormente:
| Trazer a descontinuação para frente | Sugerir a descontinuação (com exceções) | Impedir a descontinuação para garantir tempo para uma migração | |
|---|---|---|---|
| Política de permissões (se aplica a páginas/sites) |
Sim | Sim | Sim |
| Política corporativa (aplicável a dispositivos) |
Não | Não | Sim |
| Sinalizações do Chrome (aplicáveis a usuários individuais) |
Sim | Não | Não |
| Chaves de linha de comando do Chrome (aplicável a usuários individuais) |
Sim | Não | Sim |
Conclusão
O uso dos gerenciadores unload está sendo descontinuado. Eles não são confiáveis há muito tempo e não há garantia de que eles serão disparados em todos os casos em que um documento for destruído. Além disso, os gerenciadores unload são incompatíveis com o bfcache.
Os sites que usam gerenciadores unload atualmente precisam se preparar para essa descontinuação. Para isso, teste os gerenciadores unload atuais, remova ou migre esses gerenciadores ou, como último recurso, adie a descontinuação se precisar de mais tempo.
Agradecimentos
Agradecemos a Kenji Baheux, Fergal Daly, Adriana Jara e Jeremy Wagner pela ajuda na revisão deste artigo.
Imagem principal de Anja Bauermann no Unsplash (links em inglês)