O evento unload será descontinuado gradualmente, mudando gradualmente o padrão, para que os gerenciadores unload parem de ser disparados nas páginas, a menos que uma página aceite reativá-los.
Cronograma de descontinuação
Observamos que o comportamento de descarregamento provavelmente está sujeito a mudanças a partir de janeiro de 2019, quando anunciamos nossa intenção de implementar um cache de avanço e retorno. Paralelamente ao trabalho de implementação, conduzimos uma grande divulgação que resultou em uma queda significativa no uso de descarregamento. Para complementar essa interação, também começamos a oferecer maneiras de testar o efeito do descarregamento do descarregamento do Chrome 115:
- Em condições de teste com a API Permission-Policy for unload no Chrome 115 (julho de 2023)
- Teste local ativando uma sinalização no Chrome 117 (setembro de 2023)
Após essas fases de contato e teste, esperamos que a descontinuação gradual seja lançada:
- Uma fase com escopo em que o descarregamento deixará gradualmente de funcionar nos 50 sites mais acessados (referência no momento em que este artigo foi escrito).
- A partir de 1% dos usuários a partir do Chrome 120 (final de novembro de 2023).
- Término com 100% dos usuários até o final do 3o 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 gradualmente de funcionar em qualquer site, começando com 1% dos usuários e terminando com 100% até o fim do primeiro trimestre de 2025.
Também oferecemos um menu de opções de desativação caso o cronograma de descontinuação gradual não tenha tempo suficiente para migrar do descarregamento. Nosso objetivo é usar essa suspensão reversível como base para o cronograma da última fase (descontinuação forçada do descarregamento) em que essas desativações serão removidas ou reduzidas.
Contexto
O unload foi criado para disparar quando o documento está sendo descarregado. Em teoria, ele pode ser usado para executar um código sempre que um usuário sai de uma página ou como um callback no fim da sessão.
Estes são os cenários em que esse evento foi mais usado:
- Salvar dados do usuário: salve dados antes de sair da página.
- Execução de tarefas de limpeza: feche os recursos abertos antes de abandonar a página.
- Envio de análises: envio de dados relacionados às interações do usuário no final da sessão.
No entanto, o evento unload não é muito confiável.
No Chrome e no Firefox para computadores, o unload é razoavelmente confiável, mas tem um impacto negativo no desempenho do site, impedindo o uso de bfcache (cache de avanço e retorno).
Em navegadores para dispositivos móveis, o unload geralmente não é executado, porque as guias frequentemente ficam em segundo plano e depois são encerradas. Por esse motivo, os navegadores priorizam o bfcache em dispositivos móveis em vez de unload, tornando-os ainda mais não confiáveis. O Safari também usa esse comportamento no computador.
A equipe do Chrome acredita que o uso do modelo para dispositivos móveis de priorizar o bfcache em vez de unload no computador seria inconveniente, tornando-o mais não confiável no Chrome (e no Firefox). O objetivo do Chrome é remover completamente o evento unload. Até lá, o recurso vai continuar confiável no computador para os usuários 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 atual. O evento unload proporciona 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 moderno da computação.
Os sistemas operacionais para dispositivos móveis frequentemente congelam ou descarregam páginas da Web para economizar memória, e os navegadores de computadores também estão fazendo isso pelos mesmos motivos. Mesmo sem intervenções do sistema operacional, os próprios usuários trocam de guia com frequência e encerram guias antigas sem "sair das páginas" formalmente.
Remover o evento unload como "obselete" é um reconhecimento de que nós, desenvolvedores da 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, se algum dia precisamos.
Alternativas aos eventos de unload
Em vez de unload, é recomendável usar:
visibilitychange: para determinar quando a visibilidade de uma página muda. Este evento acontece quando o usuário alterna guias, minimiza a janela do navegador ou abre uma nova página. Considere o estadohiddeno ú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 alterada para outra guia. Comopagehidenão torna uma página qualificada para o cache de avanço e retorno, é possível que uma página seja restaurada depois que esse evento é disparado. Se você estiver limpando algum recurso neste evento, talvez seja necessário restaurá-lo na restauração da página.
O evento beforeunload tem um caso de uso um pouco diferente de unload, porque é um evento cancelável. Geralmente, ele é usado para avisar os usuários sobre alterações não salvas ao navegar para outra página. Esse evento também não é real, já que não será acionado se uma guia em segundo plano for encerrada. É recomendável limitar o uso de beforeunload e adicioná-lo apenas condicionalmente. Em vez disso, use os eventos acima para a maioria das substituições de unload.
Para mais detalhes, consulte esta dica sobre nunca usar o gerenciador unload.
Detectar o uso de unload
Existem diferentes ferramentas para ajudar você 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 por meio de bibliotecas) e podem ser afetados pela futura suspensão de uso.
Farol
O Lighthouse tem uma auditoria no-unload-listeners, que avisa os desenvolvedores se algum JavaScript nas páginas deles (incluindo o de bibliotecas de terceiros) adicionar um listener de eventos unload.
Chrome DevTools
O Chrome DevTools inclui uma auditoria back-foward-cache para ajudar você a identificar problemas que podem impedir que sua página seja qualificada 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 sua página, abra o DevTools e acesse 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 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 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, você pode ver se 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 usComo usar a API Reporting para encontrar descarregamentos.
API notRestoredReasons do Bfcache
A propriedade notRestoredReasons, adicionada à classe PerformanceNavigationTiming, informa se os documentos foram impedidos de usar o bfcache na navegação e por quê. As instruções de uso podem ser encontradas aqui. Este é um exemplo da aparência do aviso de objeto de resposta de um listener unload existente:
{
blocked: true,
children: [],
id: "",
name: "",
reasons: [ "Internal Error", "Unload handler" ],
src: "",
url: "a.com"
}
Controlar o acesso a unload
O Chrome vai descontinuar o evento unload gradualmente. Enquanto isso, você pode usar diferentes ferramentas para controlar esse comportamento e se preparar para a futura suspensão de uso. Tenha em mente que você não deve confiar nessas técnicas a longo prazo e deve planejar migrar para as alternativas o quanto antes.
As opções a seguir permitem ativar ou desativar os gerenciadores unload para testar como seu site funcionaria sem eles. Assim, você pode se preparar para a futura descontinuação. Há diferentes tipos de políticas:
- Política de permissões: essa é uma API de plataforma para que os proprietários de sites controlem o acesso a recursos no nível do site ou da página individual com o uso de cabeçalhos HTTP.
- Políticas corporativas: ferramentas para administradores de TI configurarem o Chrome para organizações ou empresas. Eles podem ser configurados em um painel de administrador, como o Google Admin Console.
- Sinalizações do Chrome: com elas, um desenvolvedor pode mudar 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. Veja estes exemplos sobre como definir isso no seu site. Isso permite que os sites se adiantam à descontinuação do unload.
Isso será estendido no Chrome 117 para permitir que os sites façam o inverso e ativem a ação de continuar a disparar gerenciadores unload, já que o Chrome muda o padrão para que eles não sejam acionados no futuro. Veja estes exemplos sobre como continuar a permitir que gerenciadores de descarregamento sejam disparados no seu site. Essa ativação não será permanente e precisa ser usada para dar tempo para os sites migrarem dos gerenciadores unload.
Política corporativa
As empresas com 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 esta política for ativada, o unload continuará ativado por padrão para todas as origens. A página ainda poderá definir uma política mais rigorosa. 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 específicos usando as sinalizações do Chrome e as linhas de comando:
Definir chrome://flags/#deprecate-unload como enabled aciona o padrão de descontinuação e impede que os gerenciadores unload sejam disparados. Elas ainda podem ser substituídas site por 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 interruptores de linha de comando.
Comparação de opções
A tabela a seguir resume os diferentes usos das opções discutidas anteriormente:
| Aumentar a descontinuação | Avançar a descontinuação (com exceções) | Impedir a descontinuação para garantir tempo para uma migração | |
|---|---|---|---|
| Política de permissões (aplica-se a páginas/sites) |
Sim | Sim | Sim |
| Política corporativa (aplica-se a dispositivos) |
Não | Não | Sim |
| Sinalizações do Chrome (aplicam-se a usuários individuais) |
Sim | Não | Não |
| Chaves de linha de comando do Chrome (aplica-se a usuários individuais) |
Sim | Não | Sim |
Conclusão
Os gerenciadores 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 for destruído. Além disso, os gerenciadores unload são incompatíveis com 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, adiando a descontinuação se mais tempo for necessário.
Agradecimentos
Agradecemos a Kenji Baheux, Fergal Daly, Adriana Jara e Jeremy Wagner pela ajuda ao analisar este artigo.
Imagem principal de Anja Bauermann no Unsplash (em inglês)