🕠 🧜🏼 ⭐️ BFCache ou Lá e volta. Relatório Yandex 👩🏻‍🤝‍👨🏿 🔟 💴

As pessoas usam o botão de retorno para a página anterior no navegador com muita frequência - talvez com mais frequência do que você imagina. Se sim, por que jogar a página imediatamente fora da memória do navegador e depois de um segundo gastar tempo e tráfego reabrindo-a? Para que o usuário possa voltar rapidamente, a tecnologia BFCache foi inventada, o que é importante lembrar ao desenvolver interfaces. Victor Khomyakovvictor-homyakov descobriu o "cache de ida e volta" e compilou uma tabela de compatibilidade do BFCache com diferentes APIs.

Olá, meu nome é Victor. Eu trabalho como parte de uma equipe bastante grande que lida com a página de pesquisa.

No mínimo, você já viu a mesma página ou similar no Google. E, em particular, trato do problema da velocidade de download desta página - para que ela seja renderizada no servidor o mais rápido possível e baixada e exibida para os clientes o mais rápido possível. Por que isso é importante? Quanto menos cliente aguardar o carregamento da sua página, menor a probabilidade de ele não esperar e deixar você. E quanto mais provável é que o cliente se converta com êxito em outra coisa, maior será a pontuação líquida da promoção. Ou seja, o cliente dirá com satisfação a todos que eles sabem que essa é uma página interessante - ela carrega muito rapidamente, é muito conveniente de usar. E, finalmente, quanto mais dinheiro você pode ganhar. Ou sua empresa, então ele lhe dará um prêmio.

Vou dar uma série de exemplos de empresas conhecidas. O Google conduziu um experimento. Eles intencionalmente incorporaram um atraso na página de pesquisa e mediram como isso afeta o desempenho. Descobriu-se que, em média, havia meio por cento menos pesquisas por usuário. Quanto é meio por cento? Calcular: meio por cento de centenas de milhões de usuários do Google é um número bastante grande.

Bing fez o mesmo experimento. Eles não acreditavam no Google, eles decidiram verificar. Eles obtiveram resultados semelhantes: notavelmente menos receita por usuário quando a página fica mais lenta. Por que desacelerar? Como é mais fácil diminuir a velocidade da página pelo número exato de milissegundos, para que ela possa ser facilmente reproduzida na produção do que para acelerá-la na mesma quantidade.

Exemplo do AliExpress. Eles aceleraram o site em 36% e receberam significativamente mais pedidos dos usuários. Os pedidos são diretos. Em geral, já está claro para todos que a velocidade é bastante importante, pois afeta, através de um certo número de métricas, o dinheiro ganho.

E mais um fator. Hoje já falamos sobre otimização de imagens. Ao otimizar seu tráfego, reduzindo o número de downloads, você paga menos dinheiro aos seus hosters pelo tráfego de saída. Este também é o dinheiro que permanecerá no seu bolso. E se de repente lhe oferecer um desconto de 10% no tráfego de qualquer host, sem restrições e condições? E se eu proponho garantir que o compartilhamento de suas páginas - por exemplo, 10% - seja carregado pelo usuário quase instantaneamente? Ninguém vai recusar.

A tecnologia sobre a qual tentarei falar hoje em dia é uma das soluções possíveis que impõe poucas restrições sobre a pilha com a qual você trabalha, quais tecnologias, mas ao mesmo tempo promete oferecer ganhos bastante significativos.

Para começar, o Google coleta estatísticas sobre como esses navegadores são usados em seus navegadores. E eles publicaram esse número: acontece, em média, de todas as aberturas de páginas, de toda a navegação no Chrome para dispositivos móveis, cerca de 19% é um movimento para a frente e para trás na história. Pense no que isso significa? Se você arredondar, 20% da navegação está se movendo para a página em que o usuário acabou de estar.

Para nós, assim como para os autores das páginas, isso significa: mesmo que o usuário saia, há uma chance considerável de que ele esteja prestes a retornar. Por um lado, esse pode ser o problema dos telefones celulares: tudo é pequeno, é fácil perder um dedo, clicar no link e sair da página e dizer: “Oh, droga! Eu quero retornar". Mas nos computadores de mesa, a situação é a mesma: lá o número é menor, mas ainda há uma porcentagem significativa de retornos.

O que estamos fazendo neste momento? Gastamos ineficazmente no tempo e no tráfego do usuário. Ou seja, começamos a recarregar a mesma página, analisá-la, recriar o DOM, redesenhar tudo na tela, carregar, executar JavaScript.

O navegador é uma coisa bastante poderosa. Ele está tentando usar caches sempre que possível. E a maioria dos recursos pode estar em seu cache. Ele não esperará por eles da rede, mas o buscará diretamente no cache. Por exemplo, no mecanismo V8, o resultado da análise do JavaScript também é armazenado em cache. Ou seja, o navegador não recarregará e analisará o JS e, na maioria dos casos, será necessário para executá-lo imediatamente. Mas ainda assim, reconstruir o DOM, recarregar recursos não armazenados em cache e executar JS leva um tempo considerável.

A solução se sugere. O que estamos fazendo? Quando o usuário sai da página, não a limpamos imediatamente. Simplesmente salvamos seu estado e o escondemos visualmente do usuário para que, sob o capô, ele fique à disposição do navegador.

O que faremos se o usuário decidir retornar? Apenas mostre a ele a mesma página salva. Pode ser mostrado quase instantaneamente.

Essa tecnologia é chamada de cache de retorno / encaminhamento, a partir das palavras "para frente e para trás". Abreviação de bfcache.

Aqui está um exemplo de como o mesmo navegador, o mesmo assembly se comporta quando o bfcache está desativado e ativado. A abertura da primeira página é igualmente lenta lá e ali. Além disso, quando começamos a avançar e retroceder na história, uma pausa é notada à esquerda e não está à direita. À esquerda, o movimento usual pela história leva um tempo perceptível. À direita, tudo acontece muito, muito rápido.

Mostrar GIF

Um exemplo semelhante da nossa pesquisa. À esquerda está o Safari usual no macOS com o bfcache desativado, à direita está o mesmo Safari com as configurações padrão e o bfcache ativado. Este é um caso bastante comum: uma pessoa entra em busca, pode não saber exatamente o que está procurando, pode solicitar várias opções de consulta. Eu pedi o primeiro pedido - algo não está certo. O segundo pedido parece ser melhor. Terceiro - não, pior, volte ao pedido anterior. E nesse momento seria muito bom não fazê-lo esperar. Ele acabou de ver esse pedido anterior, mostrá-lo imediatamente.

Ou a segunda opção, se você tiver paginação e várias páginas sobre o assunto. Homem folheando a questão. Eu fui para a segunda, terceira, quarta página, olhei - não, há algo errado, eu volto. E nós, novamente, podemos mostrar a ele as páginas anteriores quase que instantaneamente.

Uma questão importante é a segurança. Embora a página em que o usuário não estava oculto, ele possa acessar várias APIs que permitem ler o status do hardware do seu telefone ou computador. Aqui está uma pequena lista do que veio à mente imediatamente: geolocalização, alteração da posição do seu dispositivo no espaço, acesso à câmera e som do microfone.

Então, quando a página aparecer, é importante que ela não obtenha acesso a todos os eventos que ocorreram durante o tempo em que foi ocultada. Caso contrário, um canal adicional será aberto para espionar os usuários. É importante que ela não tenha um histórico dos seus movimentos durante todo esse tempo e das gravações do microfone e da câmera. Os desenvolvedores de navegadores também não devem esquecer isso.

Suporte a API e navegador

Mais perto do tópico. Suponha que eu já o tenha convencido, você é: "Sim, um bom tópico, devemos trabalhar com isso". Com quais APIs temos à nossa disposição, com o que podemos trabalhar se concordamos em levar o bfcache em consideração e como isso é suportado pelos navegadores?

Onde o bfcache já existe, onde posso vê-lo?

- Há muito que é implementado nos navegadores Firefox, Safari (e macOS e iOS), bem como no Internet Explorer 11 (!). Normalmente, censuramos os desenvolvedores da Microsoft, mas aqui eles apenas tentaram.

- É implementado no navegador UC Browser 11/12, versão para Android.

- De repente ele não está no Chrome. E no Chromium esse recurso está em desenvolvimento.

Portanto, quando eles fazem isso no Chromium, quase todos esses navegadores (e essa não é uma lista completa), mais cedo ou mais tarde, obterão essa funcionalidade - de graça, sem SMS e registro.

Existe algum tipo de API? Eu quero gerenciar o bfcache, quero ativá-lo e desativá-lo diretamente do JavaScript, para descobrir se há alguma página no bfcache ou não. Que tal uma API? Não existe essa API. E isso foi feito conscientemente: a página não deve querer ativar ou desativar o bfcache para todos e para si. Ou descubra se há alguém neste bfcache ou não. Tudo isso é devido à segurança.

^{_{Link do slide}}

Mas o que nós temos? Tipos de navegação. Existe um tipo de link - pré-renderizador de link, quando queremos renderizar uma página com antecedência. Existe um tipo especial de navegação para ele: esta página será aberta com o NavigationType "prerender". Se apenas abrirmos a página em um navegador, haverá "navegar". Se clicarmos no botão "Atualizar", ele será "recarregado".

Estamos interessados no tipo de navegação "back_forward" aqui, isso indica claramente que o usuário avançou e retrocedeu na história. Esse é exatamente o tipo de navegação com o qual o bfcache pode trabalhar.

Outra API são os eventos de exibição de página de exibição de página. Eles já existiam nos navegadores. Consequentemente, a exibição de página é acionada quando sua página é exibida no navegador para o usuário, o ocultar da página é acionado quando a página está oculta por qualquer motivo. E eles foram complementados pelo campo persistente. Se a página estiver oculta e ao mesmo tempo for colocada no bfcache, o campo persistido será verdadeiro. Se a página for exibida ao levantá-la do bfcache, o campo persistido será verdadeiro novamente.

Assim, se o navegador não estiver armazenando em cache a página, o ocultar da página persistirá como falso. E se o navegador exibir a página durante o carregamento normal ou não usar o bfcache, a pageshow também persistirá como false.

^{_{Link do slide}}

O suporte a eventos está disponível em quase todos os navegadores, mesmo naqueles que ainda não suportam o bfcache.

^{_{Link do slide}}

O mesmo vale para o campo persistente. Ele já existe no Chrome, e o Chrome ainda não suporta bfcache. Ou seja, esse campo estará sempre nele, mas por enquanto será falso.

Quando me deparei com esse fenômeno, bfcache, tive que estudá-lo, tocar por todos os lados, ver como ele funciona. Eu imediatamente quis ver na minha página quando abro qual é o valor do campo persistente em meus manipuladores.

Parece que tudo é bastante simples. Eu escrevi um manipulador e produzi para console.log () o que vem a mim. Mas, ao abrir o DevTools em alguns navegadores, o bfcache pode ser desligado repentinamente. Ou seja, abri o DevTools, voltei e voltei pelas páginas e meu persistente é sempre falso, a página não entra no bfcache. Ok, eu tenho outra ferramenta poderosa - alerta.

Mas não. Navegadores modernos ao descarregar uma página no oculto da página, antes que os manipuladores de descarregar e descarregar simplesmente ignorem o alerta, ele simplesmente não funciona lá. E, novamente, não vejo o que quero.

Ok, eu tenho um produto ainda mais matador. Estou em um bloco na minha própria página, que estou explorando, apenas adicionando o texto do conteúdo do meu evento e, assim, registrando tudo. Este método funcionou.

Tudo, por favor, pode ser usado. Eu depurei meu código, ele funciona para mim, posso continuar com ele. Obviamente, não esqueço que, afinal, um script estático externo é mais adequado para não carregar o mesmo código embutido na página, mas para usar o cache de arquivos.

Eu coloquei esse código depurado em um script externo.

Mas não, os manipuladores de páginas paginadas caíram no Safari! Por alguma razão, eles não funcionam a partir de um script externo.

Ok, eu já tenho uma versão funcional. Eu tive que deixar assim.

Vou listar brevemente o que consegui seguir em apenas um dia. Primeiro, o DevTools pode desativar o cache. Você provavelmente se lembra que no DevTools, na guia Rede do Chrome, há uma caixa de seleção "Desativar cache". Ele desativa o cache da rede, pode não afetar o bfcache ou pode. A analogia é clara: abrimos o DevTools, o que significa que estamos desenvolvendo e talvez não precisemos de cache. Talvez isso nos incomode.

O segundo recurso é alerta. O Firefox e o Safari ignoram silenciosamente e continuam a executar manipuladores ainda mais, como se não houvesse alerta. E apenas um Chrome antigo no console gravará um erro em vermelho - você tem um alerta, eu o bloqueei, saiba!

Mais uma vez, lembro que os manipuladores de um script externo no Safari podem não ser chamados, isso é muito estranho.

E mais uma notícia importante. Se sua página estiver armazenada em cache, ou seja, você recebeu um evento de ocultação de página, que diz "persistence true", e o navegador diz: "Sim, eu coloquei no cache", isso não garante que a página será mais tarde desse cache é gerado e mostrado de volta ao usuário. Porque o navegador pode decidir limpar esse cache se ficar sem memória. Porque o usuário pode fechar o navegador e não navegar em qualquer lugar. Lembre-se disso.

Recursos de implementação

Comecei a aprofundar a documentação, a pesquisar como posso viver com esse conhecimento. Surpreendentemente, a documentação foi. Ou seja, você pode desenterrar na Internet uma descrição de como o bfcache funciona nos navegadores. Mas, quanto mais eu leio, mais diferenças se acumulam entre diferentes navegadores.

Em um, funciona assim, no outro, funciona. Em um, um interfere, o outro não interfere. Os desenvolvedores não sabem como processar corretamente várias APIs ao colocar uma página no bfcache. Eles dizem: ok, se a página usa essa API, eu simplesmente a ignoro, nunca a coloque no cache sob nenhuma circunstância. E essa lista é diferente em navegadores diferentes, cada um faz o que é adequado.

E então comecei a combinar o que aprendi em uma tabela. Eu tenho algo como o seguinte:

Eu li a documentação para navegadores - para Firefox, Safari, a família Chromium. Havia documentação disponível no IE, embora desatualizada. Nós programadores não gostamos de atualizar a documentação após alterações no navegador? Quando percebi que as informações estavam desatualizadas, comecei a testar minhas pequenas páginas nos navegadores e verificar qual API funciona ou não.

Isso também não foi suficiente: não sei para quais APIs analisar, em princípio, mas não para classificar tudo? E tive que examinar o código fonte dos próprios mecanismos do navegador, ou seja, o código acabou sendo a fonte de conhecimento mais precisa e confiável. No momento, essa placa (à sua frente é uma parte dela, aqui está um link para a versão completa) é a coleção mais abrangente de conhecimento sobre quais APIs permitem ou proíbem o bfcache de trabalhar em navegadores.

APIs que não interferem com uma marca de seleção e cor verde, aquelas que definitivamente impedirão a página de entrar no bfcache estão marcadas em vermelho. Campos em branco são espaços que não são descritos em lugar algum.

Raposa de fogo

Aqui estão alguns detalhes interessantes de navegadores específicos. Vou começar com o Firefox, ele foi o primeiro a fazer tudo.

^{_{Link do slide}}

A coisa mais importante que aprendi com as fontes do Firefox é que, ao trabalhar com o bfcache, ele pode gravar no disco de log de texto todas as razões pelas quais não pode colocar a página no cache.

^{_{Link do slide}}

E eu até consegui descobrir como fazê-lo. Existem duas variáveis de ambiente secretas: em uma indicamos o que registrar, na segunda - em qual arquivo gravar um log. Depois disso, lançamos o binário e pronto! Veremos aproximadamente que no slide anterior, as linhas do formulário "esse html não podem ser armazenadas em cache por esse motivo, por outro motivo". Podemos lê-lo imediatamente, muito conveniente.

Se você quiser experimentar uma vez, poderá abrir a página sobre: rede no Firefox. Lá você pode inserir os mesmos campos na seção "Diário". Podemos indicar em dois campos o que e onde registrar, e com os botões iniciar e parar o registro.

^{_{Link do slide}}

Quando o Firefox se recusa a armazenar em cache a página? Se você tiver solicitações incompletas, incluindo solicitações AJAX ou solicitações de recursos como imagens, ele se recusará a colocar a página no bfcache. Ele acredita que não está concluído, não terminou o download, há algum tipo de atividade suspeita. Mas tudo isso não se aplica ao favicon. Se você esqueceu o favicon, se ele não carregar, ele pensa - tudo bem, ele fará isso, é normal para o seu site.

Se você tiver um script de longa execução, o navegador perguntará: como leva tempo, bloqueia a interface do usuário, talvez supere? E se você concordou, essa página é considerada um pouco errada e não a armazenamos em cache.

Se você usa o IndexedDB ... Esta é uma história instrutiva. Anteriormente, na primeira implementação, eles olhavam: se você tem o IndexedDB e há uma transação incompleta, essa página não é armazenada em cache, porque não está claro como trabalhar com ela (estamos tentando ocultá-la bem no meio da transação). Mas eles simplesmente perderam esse pedaço de código durante a refatoração. E como você pode imaginar, eles não tinham testes para isso. Eles ainda têm um bug no bugtracker. Ele já tem dois anos com alguma coisa. As pessoas escreveram: "Meu bfcache com o IndexedDB não funciona corretamente, o que devo fazer?" Os desenvolvedores do Firefox responderam - ele realmente falha, perdemos esse pedaço de texto durante a refatoração, ok, deixe-o continuar. Moral: escreva testes, mesmo se você escreve o Firefox, caso contrário tudo pode acabar tristemente.

E mais um fator interessante de indisponibilidade no bfcache - se o conteúdo misto for explicitamente permitido. O que é isso?

^{_{Link do slide}}

Suponha que sua página seja aberta via HTTPS, mas você ainda carregará alguns recursos via HTTP, especialmente scripts. Ou seja, você possui um script que não é de segurança, que pode ser modificado por qualquer pessoa.

^{_{Link do slide}}

Por padrão, o Firefox, como outros navegadores, não executa um script que não seja de segurança agora. Mas se for muito importante para você, você acessou as configurações e permitiu que ela fosse executada; portanto, ela não armazenará essa página em cache. Ele dirá - bem, você me disse para não executar o código, mas depois não, não!

Outro ajuste é o tamanho do próprio bfcache. Aqui, o padrão é menos um. Isso significa quanta memória o Firefox tem, tantas páginas que ele tenta armazenar em cache. Mas podemos desativar à força o cache colocando um zero ou definindo explicitamente um número - por exemplo, lembre-se de não mais que cinco páginas.

Aviso: o próximo slide contém código de exemplo na linguagem assustadora C ++, isso pode ser perigoso em uma conferência de front-end. Não tente copiá-lo, execute-o no console do navegador. Seu disco pode estar formatado, a tela pode explodir ou os bitcoins podem ser extraídos. Eu te avisei.

^{_{Link do slide}}

Então, o código Gecko. Pode ser aberto, lido, visualizado gratuitamente na Internet. E eu vasculhei. Existe o método mais importante - CanSavePresentation (), que responde à pergunta: é possível armazenar em cache este documento? Ou seja, essa é a melhor fonte de verdade sobre o que agora está implementado no Firefox. E, no entanto - foi a partir daí que aprendi que você pode ler o log. Existe essa variável - gPageCacheLog. Este é o log no qual tudo está escrito. Aqui está uma história tão interessante sobre uma excursão em C ++.

Ou seja, você abre o link, analisa o código, pesquisa (existe uma pesquisa conveniente e, além disso, rápida) e pode descobrir os detalhes reais da implementação na versão mais recente do navegador - aqueles que simplesmente estão ausentes na documentação.

Safári

A coisa mais cruel que o Safari faz quando uma página atinge o bfcache: se você tiver solicitações AJAX pendentes, o Safari as mata.

Mesmo se você os tiver sobreposto com manipuladores de erro e tentar verificar tudo, corrija-o - parece que a solicitação não existia. Depois de se recuperar do bfcache, você não terá nenhum erro, nenhum “OK”, nada.

Os manipuladores do pageshow pagehide, como eu disse, no Safari são chamados apenas se forem escritos em um script embutido na página. De um script externo, eles podem ou não funcionar - que sorte. Mas eu te avisei.

Outra diferença interessante: antes dos manipuladores de descarregar e descarregar, não interferem na entrada da página no bfcache. Nesse caso, o beforeunload é sempre chamado, e quando entra no cache e quando não é atingido. Mas descarregar quando a página atinge o cache não é chamado. E aqui está outro rake localizado: a página pode ir para o cache e nunca aparecer a partir dele, e se você escreveu algum código importante no descarregamento, ele nunca pode ser chamado, embora nenhum erro tenha ocorrido na página. Ou seja, ele foi corretamente para o cache, e dele para lugar nenhum, e sua descarga nunca será chamada.

Outro ponto interessante. Como você sabe, você pode abrir várias janelas através de window.open (). E, ao mesmo tempo, essas janelas têm links entre si. Ou seja, eles podem subir simultaneamente na janela um do outro, ler / escrever diferentes propriedades. Essa abertura das janelas filho não interfere no bfcache. E aqui, muito provavelmente, o Safari é tão cruel quanto é com as solicitações AJAX, ou seja, tudo está rasgando muito e até logo. Os desenvolvedores da Apple adoram mais.

Novamente um minuto em C ++! As fontes do WebKit também não são secretas, elas também podem ser abertas, lidas e estudadas.

^{_{Link do slide}}

Eles estão no GitHub, destacando duas funções importantes:

- canCacheFrame () - verifique se esse quadro pode ser armazenado em cache.
- Em diferentes objetos da página, como um elemento ou fonte HTML, existem métodos canSuspendForDocumentSuspension (). Esse objeto é responsável por saber se pode armazenar em cache, congelar ou não.

E mais um aspecto importante: o WebKit tem testes muito convenientes. Lá, na pasta LayoutTests / fast / history, na forma de html pequeno, compacto e conciso, há testes para o trabalho de diferentes APIs implementadas no Safari com bfcache. Este é um exemplo vivo de como você pode escrever código no Safari com essas APIs e como elas afetam ou não, permitindo ou não permitir hits do bfcache. Muito interessante ver.

A partir daí, aprendi que o Safari também grava todo o seu conhecimento sobre o bfcache, todos os recursos, em um log de texto. Infelizmente, nunca descobri como habilitar esse log ou, se estiver habilitado, onde encontrar esse arquivo em disco. Se alguém souber, me diga, ficarei muito agradecido.

Crómio.

Como eu já disse, ainda há trabalhos em andamento, tudo está fechado sob a bandeira. Você pode fazer o download do Chrome Canary fresco, acessar as bandeiras. A configuração está oculta lá - você pode tentar brincar com ela. Você pode ver alguma coisa.

Pelo interessante - eu já falei sobre abrir uma página através de window.open (). No Chromium, essas páginas não são armazenadas em cache até o momento. Eles não descobriram como resolver tudo isso corretamente, e descaradamente o cortaram, como no Safari, a consciência deles não os permite.

Se o DOMContentLoaded não ocorrer, a página também não será armazenada em cache.

Existem muitas APIs novas que começam com "Web" - também é difícil e incompreensível para elas, e até agora todas elas desativam o bfcache por padrão. Ou seja, se algo novo e moderno for usado na página, como WebGL, WebVR, WebUSB, WebBluetooth etc., essa página não entrará no bfcache.

Trabalhador de serviço. Além disso, ainda não armazenamos essa página em cache, mas planejamos processá-la corretamente, ocultá-la dos olhos vigilantes do profissional de serviço.

Se a geolocalização estiver ativada, ainda não a armazenamos em cache. Tão mais simples por enquanto.

Se durante o tempo em que a página estava no cache, os cookies foram podres, acreditamos que algum tipo de autorização expirou. Talvez fosse bancário on-line ou algo mais. Isso significa que a página não é mais válida - nós a limpamos do cache.

^{_{Link do slide}}

Os caras do Google foram ainda mais longe. Eles sugeriram que unificássemos tudo o que formalizamos, unificamos em todos os navegadores, propusemos uma especificação do ciclo de vida da página para todos os estados, sugerimos a adição de novos eventos às transições entre diferentes estados. Você pode olhar para o link que eles pensaram lá em cima.

^{_{Link do slide}}

Fontes. Como você sabe, as fontes de cromo também estão disponíveis. Tudo isso está em uma classe chamada BackForwardCacheImpl - nomeação muito boa, quase não precisava ser visualizada. O principal método que verifica se um documento pode ser salvo é chamado CanStoreDocument (). Há também um método GetDisallowedFeatures (), que simplesmente lista todos os novos recursos e APIs que não são suportados no bfcache. Muito conveniente: concentrado em um só lugar, leu e percebeu o que é atualmente possível e o que não pode ser usado.

Internet Explorer 11

Uma excursão à história para quem ainda tem o IE 11. Para quem tem tudo de ruim.

Existe o bfcache lá, e esse é o principal problema, porque você precisa lidar com isso. A documentação diz que o bfcache supostamente funciona apenas em HTTP. De fato, na produção, ele também funciona em HTTPS por algum motivo. Moral: se você é um desenvolvedor, preste atenção à sua documentação. Então você tem que sofrer por causa dela.

Se houver um manipulador de beforeunload, ele impedirá que ele entre no cache. Eles não disseram nada sobre a descarga na documentação - talvez não soubessem ou se esquecessem disso.

Se a página não tiver terminado o carregamento, ela também não será armazenada em cache. Se alguém usa componentes ActiveX, também não fazemos cache. E se o DevTools também estiver aberto lá. esse é um ponto importante.

Como sem bugs? Adicionado campo persistente, mas às vezes não funciona. Ou seja, a página realmente entra no cache, retorna dele e persiste não está definida como true. O que fazer?

Tínhamos um código bonito que determina se retornamos do cache ou recarregamos do servidor.

Agora tinha que ser complementado com uma muleta para o IE. Determinamos que temos o IE e, em algumas soluções alternativas, entendemos que a página ainda foi extraída do cache e, ao mesmo tempo, tivemos uma navegação no histórico (back_forward).

Além disso, como você sabe se uma página é armazenada em cache? Nós levamos o tempo de carregamento dela. Se ele carregou do servidor em 50 milissegundos ou mais rápido, então isso basicamente não pode estar no IE - significa que é do cache! :)

Eu já mencionei a navegação através da história. Se tivermos o tipo de navegação back_forward, analisamos o histórico e, se a página for do cache, significa bfcache, não há outras opções no IE.

Qual é o próximo?

O que fazer em seguida com esse conhecimento? Eu não gostaria que você saísse e esquecesse tudo isso como um pesadelo.

- Em primeiro lugar, aqui está a coisa mais valiosa que eu me deparei e o que eu quero levar você: use navegadores de código aberto! No acesso aberto à Internet, no momento, estão o código fonte de todos os principais navegadores que nossos clientes usam. E esta é a documentação mais relevante sobre como e como é suportada, onde e como funciona. Incluindo existem testes escritos diretamente em HTML e JS. Use, olhe!

- Em segundo lugar, considere nos aplicativos existentes que eles podem executar o bfcache. Informe seus testadores sobre isso para que, quando verifiquem a navegação, eles saibam que, ao navegar pelo histórico, a página possa ser aberta no servidor e no bfcache. Aqui está um vídeo do bug real que corrigimos quando o bfcache trabalhava para nós:

Abrir GIF

O usuário digita quatro solicitações, vê quatro problemas. Depois disso, ele volta, vê o problema 3 e a consulta 4. Outro problema anterior é 2 e a consulta 3. Ou seja, ele possui um estado incompatível da página - o conteúdo das cadeias de pesquisa e pesquisa se contradizem. Lembre-se disso em seus aplicativos.

- E terceiro, se você estiver escrevendo um novo código, pense se precisa do bfcache. Nesse caso, use a tabela de compatibilidade da API. Caso contrário, não use, mas se você acidentalmente entrar no bfcache, considere os recursos do Safari e de outros navegadores que mencionei. Algumas coisas podem rasgar insolentemente e você não será capaz de entender por que isso acontece.

Como prometido, um link para os materiais.

BFCache ou Lá e volta. Relatório Yandex