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
Em janeiro de 2019, anunciamos nossa intenção de implementar um cache de avanço e retorno. Paralelamente ao trabalho de implementação, realizamos uma grande divulgação, o que resultou em uma queda significativa no uso de unload. Para complementar essa divulgação, também começamos a oferecer maneiras de testar o efeito da descontinuação do unload no Chrome 115:
- Testes em ambientes reais com a API Permission-Policy para desligamento 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, saiba como esperamos que a suspensão de uso gradual seja lançada:
- Uma fase de escopo em que o descarregamento vai deixar de funcionar gradualmente nos 50 principais sites (referência no momento da escrita).
- Começando com 1% dos usuários do Chrome 120 (final de novembro de 2023).
- Até o final do terceiro trimestre de 2024, 100% dos usuários
- Além disso, a partir do terceiro trimestre de 2024, vamos iniciar uma fase genérica em que o descarregamento vai deixar de funcionar gradualmente em todos os sites, começando com 1% dos usuários e terminando com 100% 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 suave não ofereça tempo suficiente para migrar do unload. Nosso objetivo é usar essa descontinuação temporária para informar o cronograma da última fase (descontinuação definitiva do unload), em que essas desativações serão removidas ou reduzidas.
Contexto
unload foi projetado para ser acionado quando o documento está sendo descarregado. Em teoria, ele pode ser usado para executar código sempre que um usuário sai 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 os dados do usuário: salve os dados antes de sair da página.
- Realizar 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 não é confiável.
No Chrome e no Firefox para computador, o unload é razoavelmente confiável, mas tem um impacto negativo na performance de um site, impedindo o uso do bfcache (cache de avanço/retorno).
Em navegadores para dispositivos móveis, o unload geralmente não é executado, porque as guias são frequentemente executadas em segundo plano e depois encerradas. Por esse motivo, os navegadores priorizam o bfcache em dispositivos móveis em vez de unload, o que os torna ainda menos confiáveis. O Safari também usa esse comportamento em computadores.
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 menos confiável nesse local também, quando antes isso era razoavelmente confiável no Chrome (e no Firefox). Em vez disso, o objetivo do Chrome é remover o evento unload completamente. Até lá, ela vai continuar confiável no computador para as pessoas que recusaram explicitamente a descontinuação.
Por que descontinuar o evento unload?
A descontinuação do unload é uma etapa fundamental no reconhecimento da Web em que vivemos atualmente. O evento unload dá uma falsa sensação de controle do ciclo de vida do app que não corresponde à forma como navegamos na Web no mundo da computação moderna.
Os sistemas operacionais para dispositivos móveis congelam ou descarregam páginas da Web com frequência para economizar memória, e os navegadores para computador também estão fazendo isso cada vez mais pelos mesmos motivos. Mesmo sem intervenções do sistema operacional, os usuários frequentemente alternam entre guias e fecham guias antigas sem "sair das páginas" formalmente.
A remoção do evento unload como obsoleto é um reconhecimento de que, como desenvolvedores da Web, precisamos garantir que nosso paradigma corresponda ao do mundo real e não depender de conceitos desatualizados que não são mais verdadeiros, se é que já foram.
Alternativas aos 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 muda 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 uma página para o cache de avanço e retorno, é possível que uma página seja restaurada depois que esse evento for acionado. 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 do unload, já que é um evento 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 é acionado se uma guia em segundo plano for encerrada. É recomendável limitar o uso de beforeunload e adicionar apenas condicionalmente. Em vez disso, use os eventos acima para a maioria das substituições de unload.
Para mais detalhes, consulte este conselho sobre nunca usar o gerenciador unload.
Detectar o uso de unload
Existem diferentes ferramentas para ajudar a encontrar aparições do evento unload nas páginas. Isso permite que os sites descubram se estão usando esse evento no próprio código ou nas bibliotecas e, portanto, podem ser afetados pela 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 as Ferramentas do desenvolvedor e navegue até Aplicativo > Serviços em segundo plano > Cache de avanço e retorno.
Clique em Testar cache de avanço e retorno. O Chrome vai levar você automaticamente para
chrome://terms/e depois para sua página. Se preferir, você pode clicar nos botões "Voltar" e "Avançar" do navegador.
Se a página não estiver qualificada para o cache de avanço e retorno, a guia Cache de avanço e retorno vai mostrar uma lista de problemas. Em Ações, você pode conferir se está usando unload:
API Reporting
A API Reporting pode ser usada com uma política de permissão de leitura somente 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 bloqueados de usar o bfcache na navegação e por quê. 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 é exibido:
{
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. Não confie nessas técnicas a longo prazo. Em vez disso, planeje migrar para as alternativas assim que possível.
As opções a seguir permitem ativar ou desativar os manipuladores unload para testar como o site funcionaria sem eles e se preparar para a descontinuação. Há diferentes tipos de políticas:
- Política de permissões: é uma API de plataforma que permite aos proprietários de sites controlar o acesso a recursos em um site ou em uma página individual usando cabeçalhos HTTP.
- Políticas corporativas: ferramentas para os administradores de TI configurarem o Chrome para a organização ou empresa. Elas podem ser configuradas em um painel de administrador, 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 ao Chrome 115 para permitir que os sites desativem o uso de processadores unload e se beneficiem imediatamente do bfcache para melhorar o desempenho do site. Confira estes exemplos de como definir isso para seu site. Isso permite que os sites se antecipem à descontinuação do unload.
Isso será estendido no Chrome 117 para permitir que os sites façam o inverso e continuem tentando acionar os manipuladores unload, já que o Chrome muda o padrão para que eles não sejam acionados no futuro. Consulte estes exemplos sobre como continuar permitindo que os gerenciadores de descarregamento sejam acionados no seu site. Essa ativação não vai permanecer para sempre e deve ser usada para permitir que os sites migrem dos gerenciadores unload.
Política empresarial
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. Ao ativar essa política, o unload vai continuar ativado por padrão para todas as origens. Uma página ainda pode 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 vai adiantar a descontinuação padrão e impedir que os manipuladores unload sejam acionados. 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:
| Fazer a transição para a descontinuação | Avançar a descontinuação (com exceções) | Evitar a descontinuação para garantir tempo para uma migração | |
|---|---|---|---|
| Política de permissões (aplicável a páginas/sites) |
Sim | Sim | Sim |
| Política corporativa (aplicável a dispositivos) |
Não | Não | Sim |
| Flags do Chrome (aplicável a usuários individuais) |
Sim | Não | Não |
| A linha de comando do Chrome muda (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 precisam se preparar para essa descontinuação testando os gerenciadores unload atuais, removendo ou migrando-os ou, como último recurso, atrasando a descontinuação se mais tempo for necessário.
Agradecimentos
Agradecemos a Kenji Baheux, Fergal Daly, Adriana Jara e Jeremy Wagner por ajudarem a revisar este artigo.
Imagem principal de Anja Bauermann no Unsplash (links em inglês)