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 obsoleto é 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 já não são verdade.
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 estadohidden
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 eventopagehide
não é disparado quando a página é simplesmente minimizada ou alterada para outra guia. Comopagehide
nã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 é confiável, 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.
Chrome DevTools
O Chrome DevTools inclui uma auditoria back-forward-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 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 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:
{
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, 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
unload
para 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 opções de sinalização do Chrome e de 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)