Resumo

  • O AppCache prometia manter um aplicativo web disponível sem conexão. A página apontava para um manifesto, e o navegador guardava os arquivos indicados nele. Trocar um script ou uma imagem no servidor não atualizava automaticamente essa cópia: era preciso mudar o manifesto.
  • Se o manifesto ou um recurso obrigatório falhasse no download, a atualização inteira podia ser descartada e a versão antiga continuava em uso. O Chrome começou a retirar o AppCache por padrão em 2020. A pequena lista de arquivos havia se tornado um comando de lançamento.

O conserto estava no servidor, não na tela

O desenvolvedor corrige main.js e publica o arquivo. O visitante seguinte ainda encontra o defeito. Num site com AppCache, a explicação estava no documento mais discreto da aplicação. O guia técnico do Google dizia que alterar um script ou uma imagem já guardados não bastava para o navegador buscar a nova cópia. O manifesto da aplicação precisava mudar. Uma linha de comentário com nova marca de versão podia ser a diferença entre entregar a correção e deixá-la do lado de fora.

O arranjo comprava continuidade: a aplicação permanecia acessível quando a rede desaparecia. Em troca, o arquivo recém-enviado ao servidor não tinha passagem direta até o usuário. A lista que preservava a aplicação também controlava o momento de substituí-la.

Guardar a aplicação inteira, não torcer pelo cache comum

A nota do W3C de maio de 2008 partia de uma necessidade concreta. Pessoas queriam abrir correio, calendário ou outros programas da web fora da cobertura de rede. O cache HTTP normal podia não ter retido todas as peças necessárias. O atributo manifest no elemento html indicava um arquivo text/cache-manifest com os recursos a guardar. Uma seção NETWORK: declarava as requisições que ainda precisavam sair para a rede.

A lista explícita substituía o acaso por uma escolha do autor. O navegador, porém, passou a instalar versões como conjuntos. Segundo o guia do Google, se o próprio manifesto ou qualquer recurso exigido não fosse baixado, todo o processo de atualização falhava. O cache antigo continuava servindo a aplicação. E uma página já aberta só passava a usar os novos arquivos depois de ser recarregada.

Era uma maneira de evitar um aplicativo meio novo e meio quebrado. Também criava dois modos de atrasar uma correção. Alterar main.js sem tocar na lista deixava o arquivo antigo no navegador. Alterar a lista sem garantir a chegada de cada arquivo obrigatório também deixava o arquivo antigo no navegador. O estado do servidor e o estado da tela do leitor já não eram a mesma prova.

Uma lista parada; outra que muda depressa demais

A disciplina de atualização tinha mais uma exigência. O manifesto imutável não chamava a nova versão. Um manifesto modificado a cada pedido, por exemplo com um horário sempre novo, podia atrapalhar a própria instalação. O guia explicava que o navegador conferia a lista antes e depois de baixar os recursos; se ela mudasse nesse intervalo, poderia reunir arquivos de revisões diferentes e rejeitar o conjunto para tentar de novo mais tarde.

CACHE, NETWORK e FALLBACK distinguiam o que ficava no dispositivo, o que iria à rede e o que apareceria quando uma rota falhasse. Poucas linhas definiam uma política operacional inteira. Um arquivo ausente deixava de ser apenas um link ruim: podia impedir que uma nova versão completa passasse pelo portão.

Preferir o lote anterior completo ao novo lote incompleto era uma escolha compreensível para quem precisava trabalhar sem conexão. Para quem acabara de corrigir um problema, significava que publicar os arquivos era só a primeira etapa. Era preciso ver o navegador aceitar e mostrar a atualização.

A saída do Chrome exigiu outra operação

O plano de retirada publicado em 2020 trouxe um calendário por etapas. O Chrome 85 desativava o AppCache por padrão, com uma extensão temporária por teste de origem para sites em migração. Service workers apareciam como alternativa para oferecer funcionamento offline. Uma regra impedia soluções pela metade: no Chrome, uma página controlada por service worker deixava de usar AppCache. Não havia como instalar parte do novo plano e pedir que o antigo completasse o resto.

A equipe precisava redesenhar quais requisições seriam atendidas pelo novo mecanismo, que arquivos seriam conservados e como uma página já aberta receberia outra versão. O Google ofereceu uma ferramenta de migração que reproduzia alguns comportamentos antigos, mas não substituía a interface window.applicationCache nem seus eventos. O cronograma dizia respeito ao Chrome e à sua transição, não a uma data única de desligamento para todos os navegadores.

A promessa original era simples: manter a aplicação disponível quando a conexão sumisse. A engrenagem de atualização era menos simples. O servidor podia oferecer o conserto, e o usuário continuar trabalhando com a cópia de ontem. Entre os dois estava o manifesto, pequeno o bastante para ser esquecido e poderoso o bastante para segurar a versão.