O evento unload será descontinuado gradualmente, mudando o padrão para que os manipuladores de unload parem de ser acionados nas páginas, a menos que uma página os ative explicitamente.
Cronograma de descontinuação
Em janeiro de 2019, anunciamos nossa intenção de implementar um cache de avanço e retorno. Na época, já sabíamos que o comportamento de desligamento provavelmente seria sujeito a mudanças. 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)
- Testes locais ativando uma flag no Chrome 117 (setembro de 2023)
Após essas fases de divulgação e teste, confira como a descontinuação parcial será lançada:
- Uma fase de escopo em que o descarregamento vai deixar de funcionar gradualmente para os 50 sites mais populares (referência no momento da escrita).
- Começando com 1% dos usuários do Chrome 120 (final de novembro de 2023).
- 100% dos usuários até o final do terceiro trimestre de 2024
- 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.
Confira alguns cenários em que esse evento foi mais usado:
- 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 do usuário 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 no computador.
A equipe do Chrome acredita que usar o modelo para dispositivos móveis de priorizar o bfcache em vez de unload em computadores seria prejudicial, tornando-o menos confiável, quando antes ele era razoavelmente confiável no Chrome (e no Firefox). Em vez disso, o objetivo do Chrome é remover o evento unload completamente. Até lá, o recurso vai continuar confiável no computador para quem desativou a descontinuação.
Por que descontinuar o evento unload?
A descontinuação do unload é uma etapa importante para um reconhecimento muito maior da Web em que vivemos. 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, atualiza a página ou fecha a janela do navegador. O eventopagehidenão é acionado quando a página é simplesmente minimizada ou alternada para outra guia. Comopagehidenão torna uma página inelegível 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 nesse 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. Ele é usado com frequência para alertar os usuários sobre mudanças não salvas ao sair 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 que sua página seja qualificada para o cache de ida e volta, incluindo o uso do gerenciador unload.
Para testar o cache de ida e volta, 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. Como alternativa, clique 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 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 notRestoredReasons do Bfcache
A propriedade notRestoredReasons, adicionada à classe PerformanceNavigationTiming, informa se os documentos foram bloqueados de usar o bfcache na navegação e por quê. Confira as instruções de uso neste link. 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 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 gerenciadores 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 que os proprietários de sites controlem o acesso a recursos em um site ou em uma página específica usando cabeçalhos HTTP.
- Políticas corporativas: ferramentas para 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.
- Flags do Chrome: permite que um desenvolvedor individual 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 sobre 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 desligamento 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 seu 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 opção de desativar a Política de permissões, essa é uma ferramenta para evitar possíveis mudanças importantes, mas não deve ser usada indefinidamente.
Flags do Chrome e opções de linha de comando
Além da política corporativa, você pode desativar a descontinuação para usuários individuais usando as flags e as linhas de comando 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 por site por site usando a política de permissões, mas vão continuar sendo acionadas 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 (aplica-se 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
Os manipuladores unload estão sendo descontinuados. Eles não são confiáveis há muito tempo e não há garantia de que serão acionados em todos os casos em que um documento é destruído. Além disso, os manipuladores 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