API Page Lifecycle

Compatibilidade com navegadores

  • Chrome: 68.
  • Borda: 79.
  • Firefox: incompatível.
  • Safari: incompatível.

Os navegadores modernos às vezes suspendem ou descartam páginas quando os recursos do sistema são restritos. No futuro, os navegadores precisarão fazer isso proativamente, para que consumam menos energia e memória. A API Page Lifecycle fornece ganchos de ciclo de vida para que suas páginas possam lidar com esses navegadores intervenções sem afetar a experiência do usuário. Dê uma olhada na API para verifique se é preciso implementar esses recursos no aplicativo.

Contexto

O ciclo de vida do aplicativo é fundamental para o gerenciamento dos sistemas operacionais do Google Cloud. No Android, no iOS e em versões recentes do Windows, é possível iniciar e interrompido a qualquer momento pelo SO. Isso permite que essas plataformas simplifiquem e realoquem os recursos onde eles melhor beneficiam o usuário.

Historicamente, na Web não existe esse ciclo de vida, e os apps podem ser mantidos vivas indefinidamente. Com um grande número de páginas da Web em execução, sistemas essenciais recursos como memória, CPU, bateria e rede podem ter excesso de assinaturas, levando a uma experiência ruim para o usuário final.

A plataforma da Web já tem eventos relacionados aos estados do ciclo de vida há muito tempo como load, unload e visibilitychange com esses eventos, só os desenvolvedores para responder a mudanças de estado do ciclo de vida iniciadas pelo usuário. Para que a Web funcione de forma confiável em dispositivos de baixa potência e, em geral, priorizar os recursos todas as plataformas) os navegadores precisam de uma forma de recuperar e realocar proativamente do Google Cloud.

Na verdade, hoje em dia, os navegadores já tomam medidas ativas para economizar recursos. para páginas em guias de fundo, e muitos navegadores (especialmente o Chrome) gostariam para fazer muito mais disso — para diminuir a pegada geral de recursos.

O problema é que os desenvolvedores não têm como se preparar para esses tipos de de intervenções iniciadas pelo sistema ou mesmo saber que elas estão acontecendo. Isso significa que navegadores devem ser conservadores ou correr o risco de corromper páginas da web.

A API Page Lifecycle tenta resolver esse problema da seguinte forma:

  • Introdução e padronização do conceito de estados do ciclo de vida na Web.
  • Definir novos estados iniciados pelo sistema que permitem que os navegadores limitem a recursos que podem ser consumidos por guias ocultas ou inativas.
  • Criar novas APIs e eventos que permitem aos desenvolvedores Web responder transita de e para esses novos estados iniciados pelo sistema.

Essa solução oferece a previsibilidade que os desenvolvedores Web precisam para criar resilientes a intervenções do sistema e permite que os navegadores otimizar de forma agressiva os recursos do sistema, beneficiando todos os usuários da Web.

O restante desta postagem vai apresentar os novos recursos de ciclo de vida da página e vamos descobrir como eles se relacionam com todos os estados atuais da plataforma da Web. e eventos. Ele também traz recomendações e práticas recomendadas para os tipos de trabalho que os desenvolvedores deveriam (e não deveriam) estar fazendo em cada estado.

Visão geral de eventos e estados do ciclo de vida da página

Todos os estados do ciclo de vida da página são discretos e mutuamente exclusivos, o que significa que uma página só podem estar em um estado por vez. E a maioria das mudanças no estado do ciclo de vida de uma página são geralmente observáveis por meio de eventos DOM (consulte as recomendações do desenvolvedor para cada estado para ver as exceções).

Talvez a maneira mais fácil de explicar os estados do ciclo de vida da página e eventos que sinalizam transições entre elas, é com um diagrama:

Uma representação visual do estado e do fluxo de eventos descritos ao longo deste documento.
Estado da API Page Lifecycle e fluxo de eventos.

Estados

A tabela a seguir explica cada estado em detalhes. Ele também lista os possíveis estados que podem vir antes e depois, bem como os eventos que os desenvolvedores podem usar para observar as mudanças.

Estado Descrição
Ativa

Uma página vai estar no estado ativo se estiver visível e tiver o foco de entrada.

Possíveis estados anteriores:
passivo (no evento focus)
congelado (por meio do evento resume, os pageshow)

Próximos estados possíveis:
passivo (no evento blur)

Passivo

Uma página vai estar no estado passivo se estiver visível e não têm foco de entrada.

Possíveis estados anteriores:
ativo (no evento blur)
oculta (por meio da visibilitychange)
congelado (por meio do evento resume, os pageshow)

Próximos estados possíveis:
ativo (no evento focus)
oculta (por meio da visibilitychange)

Ocultos

Uma página fica no estado oculto quando não está visível (e não congelados, descartados ou encerrados).

Possíveis estados anteriores:
passivo (por meio do visibilitychange)
congelado (por meio do evento resume, os pageshow)

Próximos estados possíveis:
passivo (por meio do visibilitychange)
congelado (no evento freeze)
descartado (nenhum evento acionado)
encerrado (nenhum evento acionado)

Congelado

No estado congelado, o navegador suspende a execução de congelável tarefas no filas de tarefas até que a página seja descongelada. Isso significa que itens como Os timers do JavaScript e os callbacks de busca não são executados. Já em execução tarefas podem terminar (o mais importante é o callback freeze), mas eles podem ter limitações podem fazer e por quanto tempo podem ser executados.

Os navegadores congelam as páginas como uma forma de preservar o uso de CPU/bateria/dados; elas fazer isso como uma forma de acelerar navegação de avanço e retorno, evitando a necessidade de uma página inteira atualizar.

Possíveis estados anteriores:
oculto (no evento freeze)

Próximos estados possíveis:
ativo (por meio do evento resume, depois o pageshow)
passiva (por meio do evento resume, o pageshow)
oculta (no evento resume)
descartado (nenhum evento acionado)

Encerrado

Uma página fica no estado encerrado assim que começa a ser descarregado e apagado da memória pelo navegador. Não novas tarefas podem começar nesse estado, e as tarefas em andamento podem ser mortos se executarem por muito tempo.

Possíveis estados anteriores:
oculto (no evento pagehide)

Próximos estados possíveis:
SEM COR

Descartada

A página fica no estado descartada quando é descarregada pelo navegador para economizar recursos. Nenhuma tarefa, callback de evento JavaScript de qualquer tipo pode ser executado nesse estado, já que o descarte normalmente ocorrem devido a restrições de recursos, em que iniciar novos processos é impossível.

No estado discarded, a própria guia (incluindo o título da guia e o favicon) geralmente fica visível para o usuário. mesmo que a página não esteja mais disponível.

Possíveis estados anteriores:
oculto (nenhum evento acionado)
congelado (nenhum evento acionado)

Próximos estados possíveis:
SEM COR

Eventos

Os navegadores distribuem muitos eventos, mas apenas uma pequena parte deles sinaliza uma uma possível mudança no estado do ciclo de vida da página. A tabela a seguir descreve todos os eventos que pertencem ao ciclo de vida e lista para quais estados eles podem passar.

Nome Detalhes
focus

Um elemento DOM recebeu foco.

Observação:um evento focus não indicam necessariamente uma mudança de estado. Ele só sinalizaria uma mudança de estado se antes, a página não tinha o foco de entrada.

Possíveis estados anteriores:
passivo

Possíveis estados atuais:
ativo

blur

Um elemento DOM perdeu o foco.

Observação:um evento blur não indicam necessariamente uma mudança de estado. Ele só sinalizaria uma mudança de estado se a página não tem mais o foco de entrada (ou seja, a página não apenas mudou o foco de um elemento para outro).

Possíveis estados anteriores:
ativo

Possíveis estados atuais:
passivo

visibilitychange

O campo O valor visibilityState mudou. Isso pode acontecer quando um usuário navega para uma nova página, alterna entre guias, fecha uma guia, minimiza ou fecha o navegador ou muda de app no sistema operacional móvel sistemas.

Possíveis estados anteriores:
passivo
oculto

Possíveis estados atuais:
passivo
oculto

freeze *

A página acaba de ser congelada. Qualquer um freezable das filas de tarefas da página não serão iniciadas.

Possíveis estados anteriores:
oculto

Possíveis estados atuais:
congelado

resume *

O navegador retomou uma página congelada.

Possíveis estados anteriores:
congelado

Possíveis estados atuais:
ativo (se seguido pelo pageshow)
passiva (se seguido pelo pageshow
oculta

pageshow

Uma entrada de histórico de sessão está sendo acessada.

Pode ser um carregamento de página totalmente novo ou uma página extraída da cache de avanço e retorno. Se a página foi retirado do cache de avanço e retorno, o evento A propriedade persisted será true. Caso contrário, será false

Possíveis estados anteriores:
congelado (um resume evento também seria acionado)

Possíveis estados atuais:
ativo
passivo
oculto

pagehide

Uma entrada do histórico de sessão está sendo extraída.

Se o usuário navegar para outra página e o navegador puder adicionar página atual para a etapa de volta/avanço cache para ser reutilizado mais tarde, a propriedade persisted do evento é true. Quando true, a página está entrando no congelado, caso contrário, ele entrará no estado terminado.

Possíveis estados anteriores:
oculto

Possíveis estados atuais:
congelado (event.persisted é verdadeiro, freeze evento)
encerrado (event.persisted é falso, unload evento segue)

beforeunload

A janela, o documento e os recursos estão prestes a ser descarregados. O documento continua visível e o evento pode ser cancelado nesta ponto

Importante:o evento beforeunload só deve ser usada para alertar o usuário sobre alterações não salvas. Uma vez que essas alterações forem salvas, o evento deverá ser removido. Nunca deve ser adicionados incondicionalmente à página, já que isso pode prejudicar o desempenho em alguns casos. Consulte a documentação seção APIs para mais detalhes.

Possíveis estados anteriores:
oculto

Possíveis estados atuais:
encerrado

unload

A página está sendo descarregada.

Aviso: usar o evento unload nunca é recomendado porque não confiáveis e podem prejudicar o desempenho em alguns casos. Consulte a seção de APIs legadas para mais detalhes.

Possíveis estados anteriores:
oculto

Possíveis estados atuais:
encerrado

* Indica um novo evento definido pela API Page Lifecycle

Novos recursos adicionados no Chrome 68

O gráfico anterior mostra dois estados que são iniciados pelo sistema, em vez de iniciado pelo usuário: congelado e descartado. Como mencionado anteriormente, hoje os navegadores já congelam e descartam guias ocultas (a seu critério), mas os desenvolvedores não têm como saber quando que isso está acontecendo.

No Chrome 68, os desenvolvedores agora podem observar quando uma guia oculta está congelada e descongelado ouvindo o evento freeze e resume no dia document.

document.addEventListener('freeze', (event) => {
  // The page is now frozen.
});

document.addEventListener('resume', (event) => {
  // The page has been unfrozen.
});

A partir do Chrome 68, o objeto document agora inclui um wasDiscarded no Chrome para computadores (o suporte do Android está sendo acompanhado neste problema). Para determinar se uma página foi descartada enquanto estava em um ambiente você poderá inspecionar o valor dessa propriedade no tempo de carregamento da página (observação: páginas descartadas devem ser recarregadas para usá-las novamente).

if (document.wasDiscarded) {
  // Page was previously discarded by the browser while in a hidden tab.
}

Para orientações sobre o que é importante fazer nos freeze e no resume , além de como lidar e se preparar para páginas que estão sendo descartadas, consulte recomendações do desenvolvedor para cada estado.

As próximas seções oferecem uma visão geral de como esses novos recursos se encaixam estados e eventos atuais da plataforma da Web.

Como observar os estados do ciclo de vida da página no código

No modo ativo, passivo e oculto é possível executar um código JavaScript que determina o estado Estado do ciclo de vida da página das APIs atuais da plataforma da Web.

const getState = () => {
  if (document.visibilityState === 'hidden') {
    return 'hidden';
  }
  if (document.hasFocus()) {
    return 'active';
  }
  return 'passive';
};

Os estados congelado e terminado na por outro lado, só podem ser detectados no respectivo listener (freeze e pagehide), como o estado é mudando.

Como observar mudanças de estado.

Com base na função getState() definida anteriormente, é possível observar todos os atributos Mudanças de estado do ciclo de vida com o código a seguir.

// Stores the initial state using the `getState()` function (defined above).
let state = getState();

// Accepts a next state and, if there's been a state change, logs the
// change to the console. It also updates the `state` value defined above.
const logStateChange = (nextState) => {
  const prevState = state;
  if (nextState !== prevState) {
    console.log(`State change: ${prevState} >>> ${nextState}`);
    state = nextState;
  }
};

// Options used for all event listeners.
const opts = {capture: true};

// These lifecycle events can all use the same listener to observe state
// changes (they call the `getState()` function to determine the next state).
['pageshow', 'focus', 'blur', 'visibilitychange', 'resume'].forEach((type) => {
  window.addEventListener(type, () => logStateChange(getState()), opts);
});

// The next two listeners, on the other hand, can determine the next
// state from the event itself.
window.addEventListener('freeze', () => {
  // In the freeze event, the next state is always frozen.
  logStateChange('frozen');
}, opts);

window.addEventListener('pagehide', (event) => {
  // If the event's persisted property is `true` the page is about
  // to enter the back/forward cache, which is also in the frozen state.
  // If the event's persisted property is not `true` the page is
  // about to be unloaded.
  logStateChange(event.persisted ? 'frozen' : 'terminated');
}, opts);

Esse código faz três coisas:

  • Define o estado inicial usando a função getState().
  • Define uma função que aceita um próximo estado e, se houver uma mudança, registra as mudanças de estado no console.
  • Adiciona capturando listeners de evento para todos os eventos de ciclo de vida necessários, que, por sua vez, chamam logStateChange(), transmitindo o próximo estado.

Uma coisa a observar sobre o código é que todos os listeners de evento são adicionados para window, e todas elas passaram {capture: true}. Existem alguns motivos para isso acontecer, entre eles:

  • Nem todos os eventos de ciclo de vida da página têm o mesmo destino. pagehide e pageshow são disparadas em window. visibilitychange, freeze e resume são disparados em document, e focus e blur são disparados na própria respectivos elementos DOM.
  • A maioria desses eventos não surge, o que significa que é impossível adicionar ouvintes de eventos sem captura a um elemento ancestral comum e observam todos um deles.
  • A fase de captura é executada antes das fases de destino ou de balão. Portanto, a adição para garantir que sejam executados antes que outros códigos possam cancelá-los.

Recomendações do desenvolvedor para cada estado

Como desenvolvedores, é importante entender os estados do ciclo de vida da página e saber observá-los no código, porque o tipo de trabalho que você deve (e deve não) estão fazendo depende muito do estado em que sua página está.

Por exemplo, claramente não faz sentido exibir uma notificação temporária para o usuário se a página estiver oculta. Esse exemplo é bastante óbvia, há outras recomendações que não são tão óbvias que valem a pena enumerando.

Estado Recomendações para desenvolvedores
Active

O estado ativo é o momento mais crítico para o usuário e, portanto, o momento mais importante para que sua página seja responsivo à entrada do usuário.

Qualquer trabalho que não seja da interface e que possa bloquear a linha de execução principal não deve ser priorizado para períodos de inatividade ou transferidos para um worker da Web.

Passive

No estado passivo, o usuário não está interagindo com a página. mas ainda podem vê-lo. Isso significa que as atualizações e animações da interface ser suave, mas o momento em que essas atualizações ocorrem é menos importante.

Quando a página muda de ativa para passiva, trata-se de uma um bom momento para manter o estado do aplicativo não salvo.

Hidden

Quando a página muda de passiva para oculta, é o usuário não interagirá com ele novamente até que seja recarregado.

A transição para o estado oculto geralmente também é a última mudança de estado que podem ser observados com segurança pelos desenvolvedores (isso é especialmente válido para dispositivos móveis, já que os usuários podem fechar guias ou o próprio navegador, e os beforeunload, pagehide e unload não são acionados nesses casos).

Isso significa que você deve tratar o estado oculto como a extremidade provável para sessão do usuário. Em outras palavras, manter qualquer estado do aplicativo não salvo e enviar dados de análise não enviados.

Você também deve parar de fazer atualizações de interface (já que elas não serão vistas pelo usuário), e interrompa todas as tarefas que o usuário não queira executados em segundo plano.

Frozen

No estado congelado, tarefas congeláveis filas de tarefas ficam suspensas até que a página seja descongelada, o que pode nunca acontecer (por exemplo, se a página for descartada).

Isso significa que, quando a página muda de oculta para congelada é essencial parar os timers ou desativar as conexões que, se estiver congelado, poderá afetar outras guias abertas na mesma origem ou afetar o a capacidade do navegador de colocar a página no cache de avanço e retorno.

Especificamente, é importante que você:

Você também precisa manter qualquer estado de visualização dinâmica (por exemplo, posição de rolagem). em uma visualização de lista infinita) sessionStorage (ou IndexedDB via commit()) que você gostaria de restaurar se a página fosse descartados e recarregados mais tarde.

Se a página mudar de congelada para oculta, é possível reabrir quaisquer conexões encerradas ou reiniciar qualquer pesquisa parou quando a página estava inicialmente congelada.

Terminated

Geralmente, você não precisa fazer nada quando uma página faz a transição ao estado terminated.

Como as páginas que estão sendo descarregadas como resultado de uma ação do usuário sempre aparecem pelo estado hidden antes de entrar no estado terminated o estado oculto é onde a lógica de encerramento de sessão (por exemplo, estado do aplicativo persistente e geração de relatórios para análise) devem ser realizada.

Além disso, como mencionado nas recomendações para o estado oculto), é muito importante que os desenvolvedores percebam que a transição para o estado encerrado não possa ser confiável são detectados em muitos casos (especialmente em dispositivos móveis), para que os desenvolvedores em eventos de encerramento (por exemplo, beforeunload, pagehide e unload) provavelmente estão perdendo dados.

Discarded

O estado discarded não é observável pelos desenvolvedores no hora que uma página é descartada. Isso ocorre porque as páginas normalmente são descartado por restrições de recursos e descongelar uma página apenas para permitir script a ser executado em resposta a um evento de descarte simplesmente não é possível em na maioria dos casos.

Como resultado, você deve se preparar para a possibilidade de descarte em é possível mudar de oculto para congelado. reagir à restauração de uma página descartada no tempo de carregamento da página por verificando document.wasDiscarded.

Como a confiabilidade e a ordem dos eventos do ciclo de vida não são implementadas consistentemente em todos os navegadores, a forma mais fácil de seguir os conselhos na tabela é usar PageLifecycle.js (link em inglês).

APIs de ciclo de vida legadas a serem evitadas

Os eventos a seguir devem ser evitados sempre que possível.

O evento de descarregamento

Muitos desenvolvedores tratam o evento unload como um callback garantido e o usam como um sinal de fim de sessão para salvar o estado e enviar dados de análise, mas fazer isso é extremamente não confiável, especialmente em dispositivos móveis. O evento unload não disparar em muitas situações típicas de descarregamento, incluindo o fechamento de uma guia a partir dela no dispositivo móvel ou fechar o navegador usando o seletor de apps.

Por isso, é sempre melhor confiar no Evento visibilitychange para determinar quando uma sessão e considere o estado oculto que tempo confiável da última vez para economizar dados do app e do usuário.

Além disso, a mera presença de um manipulador de eventos unload registrado (via onunload ou addEventListener()) pode impedir que os navegadores possam colocar páginas no cache de avanço e retorno para acelerar para frente e para trás.

Em todos os navegadores mais recentes, é recomendável sempre usar a O evento pagehide para detectar possíveis descarregamentos de página (também conhecidos como o estado terminado) em vez do evento unload. Se você for compatível com o Internet Explorer versão 10 e inferior, deverá apresentar detectar o evento pagehide e usar unload apenas se o navegador não oferecer suporte pagehide:

const terminationEvent = 'onpagehide' in self ? 'pagehide' : 'unload';

window.addEventListener(terminationEvent, (event) => {
  // Note: if the browser is able to cache the page, `event.persisted`
  // is `true`, and the state is frozen rather than terminated.
});

O evento beforeunload

O evento beforeunload tem um problema semelhante ao unload, por isso, historicamente, a presença de um evento beforeunload poderia impedir que as páginas qualificação para o cache de avanço e retorno. Navegadores modernos não têm essa restrição. Embora alguns navegadores, por precaução, não disparem o evento beforeunload ao tentar colocar uma página em "Voltar/avançar". o que significa que o evento não é confiável como sinal de fim de sessão. Além disso, alguns navegadores (incluindo o Chrome) exigem uma interação do usuário na página antes de permitir o evento beforeunload. disparar, o que afeta ainda mais sua confiabilidade.

Uma diferença entre beforeunload e unload é que há usos legítimos de beforeunload. Por exemplo, quando você quer avisar o usuário que há alterações não salvas que perderão se continuarem a descarregar a página.

Como há motivos válidos para usar beforeunload, é recomendável que você Adicione listeners beforeunload quando um usuário tiver mudanças não salvas e, em seguida, removê-los imediatamente depois de serem salvos.

Em outras palavras, não faça isso, já que adiciona um listener beforeunload. incondicionalmente):

addEventListener('beforeunload', (event) => {
  // A function that returns `true` if the page has unsaved changes.
  if (pageHasUnsavedChanges()) {
    event.preventDefault();

    // Legacy support for older browsers.
    return (event.returnValue = true);
  }
});

Em vez disso, faça isso, já que ele só adiciona o listener beforeunload quando necessário e a remove quando não são):

const beforeUnloadListener = (event) => {
  event.preventDefault();
  
  // Legacy support for older browsers.
  return (event.returnValue = true);
};

// A function that invokes a callback when the page has unsaved changes.
onPageHasUnsavedChanges(() => {
  addEventListener('beforeunload', beforeUnloadListener);
});

// A function that invokes a callback when the page's unsaved changes are resolved.
onAllChangesSaved(() => {
  removeEventListener('beforeunload', beforeUnloadListener);
});

Perguntas frequentes

Por que não há um "carregamento" estado?

A API Page Lifecycle define os estados para serem discretos e mutuamente exclusivos. Como uma página pode ser carregada nos estados ativo, passivo ou oculto, e já que pode mudar de estado ou até ser encerrado antes de terminar de carregar, uma estado de carregamento separado não faz sentido nesse paradigma.

Minha página funciona de forma importante quando está oculta. Como posso impedir que ela seja congelada ou descartada?

Existem muitos motivos legítimos para que páginas da Web não sejam congeladas durante a execução no estado oculto. O exemplo mais óbvio é um app que toca música.

Também há situações em que seria arriscado o Chrome descartar uma página, por exemplo, se o formulário tiver uma entrada de usuário não enviada ou se houver Gerenciador beforeunload que avisa quando a página está sendo descarregada.

Por enquanto, o Chrome será conservador ao descartar páginas e só faça isso quando tiver certeza de que não vai afetar os usuários. Por exemplo, as páginas que foram observados realizando as seguintes ações enquanto estiver no estado oculto, não terão serão descartados, a menos que sob restrições extremas de recursos:

  • Reproduzindo áudio
  • Como usar o WebRTC
  • Atualizar o título ou o favicon da tabela
  • Mostrando alertas
  • Como enviar notificações push

Para os recursos de lista atuais usados para determinar se uma guia pode ser congelados ou descartados, consulte: Heurística para congelamento e Descartando no Chrome.

O que é o cache de avanço e retorno?

Cache de avanço e retorno é um termo usado para descrever uma otimização da navegação que alguns navegadores implementam, fazendo com que o uso das funções de retorno e avançar mais rapidamente.

Quando o usuário sai de uma página, esses navegadores congelam uma versão da página para que ela possa ser retomada rapidamente caso o usuário navegue de volta usando os botões "Voltar" ou "Avançar". Lembre-se de que adicionar um unload manipulador de eventos impede que essa otimização seja possível.

Para todos os propósitos, esse congelamento é funcionalmente o mesmo que o congelamento dos navegadores funciona para economizar CPU/bateria; por isso é são considerados parte do estado congelado do ciclo de vida.

Se não for possível executar APIs assíncronas nos estados congelado ou encerrado, como salvar dados no IndexedDB?

Nos estados congelado e encerrado, tarefas congeladas nas filas de tarefas de uma página são suspensas, o que significa que APIs assíncronas e baseadas em callback, como IndexedDB, não pode ser usado de maneira confiável.

No futuro, adicionaremos um método commit() aos objetos IDBTransaction, o que oferecem aos desenvolvedores uma maneira de executar o que são, efetivamente, transações somente gravação que não exigem callbacks. Em outras palavras, se o desenvolvedor está apenas criando para IndexedDB e não realizam uma transação complexa que consiste em leituras e gravações, o método commit() poderá terminar antes que as filas de tarefas sejam suspenso (supondo que o banco de dados do IndexedDB já esteja aberto).

No entanto, para códigos que precisam funcionar hoje, os desenvolvedores têm duas opções:

  • Usar o armazenamento de sessão: armazenamento de sessão é síncrono e persiste entre descartes de páginas.
  • Use o IndexedDB do seu service worker: um service worker pode armazenar dados no IndexedDB após a página ter sido encerrada ou descartada. No freeze ou É possível enviar dados ao service worker por meio de um listener de eventos pagehide. postMessage(), e o service worker pode salvar os dados.
.

Como testar o app nos estados congelado e descartado

Para testar como o app se comporta nos estados congelado e descartado, acesse chrome://discards para congelar ou descartar qualquer uma das suas guias abertas.

Interface de descarte do Chrome
Interface de descartes do Chrome

Isso garante que sua página processe corretamente o freeze e o resume. bem como a sinalização document.wasDiscarded quando as páginas são atualizadas após um descarte.

Resumo

Desenvolvedores que querem respeitar os recursos do sistema dos dispositivos dos usuários precisam criar apps pensando nos estados do ciclo de vida da página. É fundamental que as páginas da web não estejam consumindo recursos excessivos do sistema em situações que o usuário não espera

Quanto mais desenvolvedores começarem a implementar as novas APIs de ciclo de vida de página, mais seguro ele será. farão com que os navegadores congelem e descartem páginas que não estão sendo usadas. Isso significa que os navegadores vão consumir menos recursos de memória, CPU, bateria e rede, o que é uma vitória para os usuários.