Como manter tudo atualizado com o método desatualizado-while-revalidate

Uma ferramenta adicional para ajudar você a equilibrar o imediatismo e a atualização ao disponibilizar seu app da Web.

Jeff Posnick

O que foi lançado?

O stale-while-revalidate ajuda os desenvolvedores a equilibrar o imediatismo (carregar o conteúdo em cache imediatamente) e a atualização (garantir que as atualizações do conteúdo em cache sejam usadas no futuro). Se você mantém um serviço da Web ou uma biblioteca de terceiros que é atualizada regularmente ou se os recursos próprios tendem a ter uma vida útil curta, o stale-while-revalidate pode ser uma adição útil às políticas de armazenamento em cache existentes.

A configuração de stale-while-revalidate com max-age no cabeçalho de resposta Cache-Control é compatível com o Chrome 75 e o Firefox 68.

Os navegadores que não são compatíveis com stale-while-revalidate vão ignorar silenciosamente esse valor de configuração e usar max-age, como vou explicar em breve…

O que isso significa?

Vamos dividir stale-while-revalidate em duas partes: a ideia de que uma resposta armazenada em cache pode estar desatualizada e o processo de revalidação.

Primeiro, como o navegador sabe se uma resposta em cache está "desatualizada"? Um cabeçalho de resposta Cache-Control que contém stale-while-revalidate também precisa conter max-age, e o número de segundos especificado por max-age é o que determina a desatualização. Qualquer resposta em cache mais recente que max-age é considerada atual, e as respostas em cache mais antigas são consideradas desatualizadas.

Se a resposta armazenada em cache localmente ainda for recente, ela poderá ser usada como está para atender à solicitação de um navegador. Do ponto de vista do stale-while-revalidate, não há nada a fazer nesse cenário.

No entanto, se a resposta em cache estiver desatualizada, outra verificação baseada em idade será realizada: a idade da resposta em cache está dentro do período extra fornecido pela configuração stale-while-revalidate?

Se a idade de uma resposta desatualizada estiver dentro dessa janela, ela será usada para atender à solicitação do navegador. Ao mesmo tempo, uma solicitação de "revalidação" será feita na rede de uma forma que não atrase o uso da resposta armazenada em cache. A resposta retornada pode conter as mesmas informações que a resposta armazenada em cache anteriormente ou pode ser diferente. De qualquer forma, a resposta da rede é armazenada localmente, substituindo o que estava em cache anteriormente e redefinindo o timer de "atualização" usado durante as comparações futuras de max-age.

No entanto, se a resposta em cache for antiga o suficiente para ficar fora da janela de tempo stale-while-revalidate, ela não vai atender à solicitação do navegador. Em vez disso, o navegador vai recuperar uma resposta da rede e usá-la para atender à solicitação inicial e preencher o cache local com uma resposta nova.

Exemplo ao vivo

Veja abaixo um exemplo simples de uma API HTTP para retornar o horário atual, mais especificamente, o número atual de minutos após a hora.

Nesse cenário, o servidor da Web usa este cabeçalho Cache-Control na resposta HTTP:

Cache-Control: max-age=1, stale-while-revalidate=59

Essa configuração significa que, se uma solicitação de horário for repetida no próximo segundo, o valor armazenado em cache anteriormente ainda será recente e usado como está, sem qualquer revalidação.

Se uma solicitação for repetida entre 1 e 60 segundos depois, o valor armazenado em cache será desatualizado, mas será usado para atender à solicitação de API. Ao mesmo tempo, "em segundo plano", uma solicitação de revalidação será feita para preencher o cache com um valor novo para uso futuro.

Se uma solicitação for repetida após mais de 60 segundos, a resposta desatualizada não será usada, e o atendimento da solicitação do navegador e a revalidação do cache vão depender de uma resposta da rede.

Confira um detalhamento desses três estados distintos, além do período em que cada um deles se aplica ao nosso exemplo:

Um diagrama que ilustra as informações da seção anterior.

Quais são os casos de uso comuns?

Embora o exemplo acima de um serviço de API de "minutos após a hora" seja artificial, ele ilustra o caso de uso esperado: serviços que fornecem informações que precisam ser atualizadas, mas em que algum grau de desatualização é aceitável.

Exemplos menos artificiais podem ser uma API para as condições climáticas atuais ou as principais manchetes de notícias escritas na última hora.

Em geral, qualquer resposta que seja atualizada em um intervalo conhecido, que provavelmente será solicitada várias vezes e que seja estática dentro desse intervalo é uma boa candidata para armazenamento em cache de curto prazo via max-age. O uso de stale-while-revalidate além de max-age aumenta a probabilidade de que as solicitações futuras sejam atendidas pelo cache com conteúdo mais recente, sem bloqueio em uma resposta de rede.

Como ele interage com service workers?

Se você já ouviu falar do stale-while-revalidate, é provável que tenha sido no contexto de receitas usadas em um service worker.

O uso de stale-while-revalidate por um cabeçalho Cache-Control tem algumas semelhanças com o uso em um service worker, e muitas das mesmas considerações sobre compensações de atualização e vida útil máxima se aplicam. No entanto, há algumas considerações que você precisa levar em conta ao decidir se vai implementar uma abordagem baseada em service worker ou apenas confiar na configuração do cabeçalho Cache-Control.

Use uma abordagem de service worker se…

  • Você já usa um service worker no seu app da Web.
  • Você precisa de um controle refinado sobre o conteúdo dos caches e quer implementar algo como uma política de expiração de uso mais recente. O módulo Expiração do cache do Workbox pode ajudar com isso.
  • Você quer receber uma notificação quando uma resposta desatualizada mudar em segundo plano durante a etapa de revalidação. O módulo Broadcast Cache Update do Workbox pode ajudar com isso.
  • Você precisa desse comportamento de stale-while-revalidate em todos os navegadores mais recentes.

Use uma abordagem de Cache-Control se…

  • Você prefere não lidar com a sobrecarga de implantar e manter um service worker para seu app da Web.
  • Você não se importa que o gerenciamento automático de cache do navegador impeça que os caches locais fiquem muito grandes.
  • Você não se importa com uma abordagem que não é compatível com todos os navegadores mais recentes (em julho de 2019, mas o suporte pode aumentar no futuro).

Se você estiver usando um service worker e também tiver o stale-while-revalidate ativado para algumas respostas por um cabeçalho Cache-Control, o service worker, em geral, terá a "primeira chance" de responder a uma solicitação. Se o service worker decidir não responder ou se, no processo de geração de uma resposta, ele fizer uma solicitação de rede usando fetch(), o comportamento configurado pelo cabeçalho Cache-Control vai entrar em vigor.

Saiba mais