O que são dados em cache? O que significa limpar cache e o que isso faz?

Primeiro, o que é cache?

Em termos gerais, um cache (pronuncia-se "dinheiro") é um tipo de repositório. Você pode pensar em um repositório como um depósito de armazenamento. Nas forças armadas, isso seria para conter armas, alimentos e outros suprimentos necessários para levar avante uma missão.

Na ciência da computação, esses "suprimentos" são chamados de recursos, onde os recursos são scripts, código e conteúdo do documento. O último às vezes é mais especificamente referido como "ativos", como texto, dados estáticos, mídia e hiperlinks, mas aqui usarei apenas um termo recursos .

A distinção entre um cache e outros tipos de repositórios

O objetivo principal do cache é acelerar a recuperação de recursos da página da web, diminuindo o tempo de carregamento da página. Outro aspecto crítico de um cache é garantir que ele contenha dados relativamente novos.

Este artigo abordará dois métodos predominantes de cache: cache do navegador e Content Delivery Networks (CDNs).

Além dos caches, outros repositórios entram em jogo nas arquiteturas da web; muitas vezes, eles são projetados para conter uma grande quantidade de dados. Eles não são tão focados no desempenho de recuperação.

Por exemplo, o Amazon Glacier é um repositório de dados projetado para armazenar dados de maneira econômica, mas não recuperá-los rapidamente. Um banco de dados SQL, por outro lado, é projetado para ser flexível, atualizado e rápido, mas raramente é barato e geralmente não é tão rápido quanto um cache.

O Cache do navegador: um cache de memória

Um cache de memória armazena recursos localmente no computador onde o navegador está sendo executado. Enquanto o navegador estiver ativo, os recursos recuperados serão armazenados na memória física do computador (RAM) e, possivelmente, também no disco rígido.

Mais tarde, quando os exato mesmos recursos são necessários quando revisitar uma página web, o navegador vai puxar os do cache em vez do servidor remoto. Como o cache é armazenado localmente, na memória rápida, esses recursos são buscados mais rapidamente e a página carrega mais rápido.

A velocidade de recuperação de recursos é essencial, mas também a necessidade de os recursos serem atualizados. Um recurso obsoleto é aquele que está desatualizado e pode não ser mais válido.

Parte do trabalho do navegador é identificar quais recursos em cache estão obsoletos e buscar novamente os que estão. Como uma página da web normalmente tem muitos recursos, geralmente haverá uma mistura de versões antigas e novas no cache.

Como o navegador sabe o que está obsoleto no cache?

A resposta não é simples, mas existem duas abordagens principais: impedimento de cache e campos de cabeçalho HTTP.

quebra de cache

Italianos

O bloqueio de cache é uma técnica do lado do servidor que garante que o navegador busque apenas recursos novos. Ele faz isso indiretamente.

Embora o cachebuster possa parecer dramático, ele realmente não destrói nada, e nem mesmo altera o que já está armazenado em cache em um navegador. Tudo o que o cachebusting faz é alterar o URI do recurso original de uma forma que faça parecer ao navegador que o recurso é completamente novo. Como parece novo, não estará no cache do navegador. A versão antiga do recurso em cache ainda será armazenada em cache, mas eventualmente irá murchar e morrer, para nunca mais ser acessada.

Digamos que eu tenha uma página da web localizada na www.foobar.com/about.htmlqual diga tudo sobre foobar.com que você gostaria de saber. Depois de visitar essa página, ela e os recursos associados a ela são armazenados em cache pelo navegador.

Mais tarde, o foobar.com é comprado pela corporação Quxbaz, e o conteúdo da página sobre sofre mudanças significativas. O cache do navegador não terá esse novo conteúdo, mas ele ainda pode acreditar que o conteúdo que possui é atual e nunca tentará recuperá-lo.

O que você, o administrador da web do Quxbaz, faz para garantir que todo o novo conteúdo seja enviado para fora?

Como o navegador depende do URI para localizar itens no cache, se o URI de um recurso mudar, é como se o navegador nunca o tivesse visto antes de ir buscar esse recurso no servidor.

Portanto, ao alterar o URI do recurso de www.foobar.com/about.htmlpara www.foobar.com/about2.html(ou para www.quxbaz.com/about.html), o navegador não encontrará nenhum recurso de cache associado a esse URI e fará uma busca completa no servidor. O recurso pode ser substancialmente o mesmo que o original no URI antigo, mas o navegador não sabe disso.

Você não precisa alterar o nome da página, no entanto. Desde o URI também inclui uma cadeia de consulta, por definição, você pode adicionar um parâmetro versão para o URI: www.foobar.com/about.html?v=2hef9eb1.

Nesse caso, o parâmetro de versão v é definido como um novo valor hash gerado sempre que o conteúdo muda ou é disparado por algum outro processo, como a reinicialização do servidor. O navegador vê que a string de consulta mudou e, como as strings de consulta podem afetar o que será retornado, ele buscará um recurso atualizado do servidor.

Nenhuma dessas técnicas funcionará se o URI antigo for acessado diretamente de um marcador. A menos que o navegador tenha sido instruído a revalidar o URI na última solicitação em cache (ou o recurso em cache expirou), ele não fará uma busca completa para atualizar seu cache. Isso nos leva ao próximo tópico.

Campos de cabeçalho HTTP

Cada solicitação de recurso vem com alguma meta informação conhecida como cabeçalho. Por outro lado, cada resposta também possui informações de cabeçalho associadas a ela.

Em alguns casos, o navegador vê os valores do cabeçalho de resposta e altera os valores correspondentes nos cabeçalhos de solicitação subsequentes. Entre esses valores de cabeçalho estão aqueles que afetam como o cache de recursos é executado no navegador.

Solicitações HEAD e solicitações condicionais

Uma solicitação HEAD é como uma solicitação GET ou POST truncada. Em vez de solicitar o recurso completo, uma solicitação HEAD solicita apenas os campos de cabeçalho que, de outra forma, seriam retornados em uma solicitação completa.

O cabeçalho de um recurso geralmente será muito menor (em número de bytes totais) do que os dados do recurso associados a ele (o "corpo" da resposta). As informações do cabeçalho são suficientemente informativas para permitir que o navegador determine a atualização do recurso em seu cache.

As solicitações HEAD são freqüentemente usadas para verificar a validade de um recurso do servidor (ou seja, o recurso ainda existe e, em caso afirmativo, foi atualizado desde o último acesso do navegador?). O navegador usará o que está em seu cache se a solicitação HEAD indicar que o recurso é válido, caso contrário, ele executará uma solicitação GET ou POST completa e atualizará seu cache com o que for retornado.

Com uma solicitação condicional, o navegador envia campos no cabeçalho que descrevem a atualização de seu recurso armazenado em cache. Desta vez, o servidor determina se o cache do navegador ainda está atualizado.

Se for, o servidor retorna uma resposta 304 com apenas as informações do cabeçalho do recurso e nenhum corpo do recurso (os dados). Se o cache do navegador for determinado como desatualizado, o servidor retornará uma resposta 200 OK completa.

Esse mecanismo é mais rápido do que usar as solicitações HEAD, pois elimina a possibilidade de ter que emitir duas solicitações em vez de uma.

A descrição acima simplifica o que pode ser um processo bastante complicado. Há muitos ajustes finos envolvidos no cache, mas tudo é controlado por meio de campos de cabeçalho, o mais importante dos quais é o controle de cache.

Cache-Control

Ao responder a uma solicitação, o servidor enviará campos de cabeçalho ao navegador, indicando qual comportamento deve ser adaptado durante o armazenamento em cache. Se eu carregar a página em //en.wikipedia.org/wiki/Uniform_Resource_Identifier, a resposta conterá isso em seu registro de cabeçalho:

cache-control: private, s-maxage=0, max-age=0, must-revalidate 

privado significa que apenas o navegador deve armazenar em cache o conteúdo do documento.

s-maxage e max-age são definidos como 0 . O valor s-maxage é para servidores proxy com caches, enquanto max-age se destina ao navegador. O efeito de definir max-age sozinho é que o recurso em cache expira imediatamente, mas ainda pode ser usado (mesmo se desatualizado) durante o recarregamento da página na mesma sessão do navegador.

Um recurso obsoleto pode ser revalidado por meio de uma solicitação HEAD, que pode ser seguida por uma solicitação GET ou POST, dependendo da resposta. A diretiva must-revalidate comanda o navegador para revalidar o recurso armazenado em cache se ele estiver desatualizado.

Uma vez que max-age é definido como 0 neste caso, o recurso armazenado em cache fica imediatamente obsoleto assim que é recebido. A combinação das duas diretivas é equivalente à diretiva única no-cache .

As duas configurações garantem que o navegador sempre revalide o recurso armazenado em cache, esteja ou não na mesma sessão.

As diretivas de controle de cache são muito extensas e, às vezes, confusas - elas são um tópico por si só. Uma lista documentada completa de diretivas pode ser encontrada aqui.

E-tag

Este é um token que o servidor envia e o navegador retém até a próxima solicitação. Isso só é usado quando o navegador sabe que o tempo de vida do cache do recurso expirou.

E-tags são valores hash gerados pelo servidor, que geralmente usam o nome do arquivo físico do recurso e a data da última modificação no servidor como uma semente. Quando um arquivo de recurso é atualizado, a data de modificação muda e um novo valor de hash é gerado e enviado no cabeçalho de resposta à solicitação.

Outras tags de cabeçalho afetando o cache

As tags de cabeçalho expiram e foram modificadas pela última vez , mas estão obsoletas, mas ainda são enviadas pela maioria dos servidores para compatibilidade com navegadores mais antigos. Um exemplo:

expires: Thu, 01 Jan 1970 00:00:00 GMT last-modified: Sun, 01 Mar 2020 17:59:02 GMT 

Aqui, a expiração é definida como a data zero (historicamente, do sistema operacional UNIX). Isso indica que o recurso expira imediatamente, assim como max-age = 0 . Última modificação informa ao navegador quando a atualização mais recente foi feita no recurso, que ele pode usar para decidir se deve buscá-lo novamente em vez de usar o valor do cache.

Forçar uma atualização do cache do navegador

O que é um recarregamento difícil?

Um hard reload força a nova busca de todos os recursos em uma página, sejam eles conteúdo, scripts, folhas de estilo ou mídia. Quase tudo, certo?

Bem, alguns recursos podem não estar explicitamente incluídos em uma página. Em vez disso, eles podem ser buscados dinamicamente, geralmente depois que tudo explícito for carregado.

O navegador não sabe com antecedência que isso vai acontecer e, quando o fizer, as solicitações posteriores (iniciadas por scripts, geralmente) ainda usarão cópias em cache desses recursos, se disponíveis.

O que é limpar cache e hard reload?

Essa operação limpa todo o cache do navegador, o que tem o mesmo efeito de um recarregamento rígido, mas também faz com que os recursos carregados dinamicamente sejam buscados - afinal, não há nada no cache, então não há escolha!

Redes de distribuição de conteúdo: um cache geo-localizado

Um CDN é mais do que apenas um cache, mas o cache é uma de suas tarefas. Um CDN armazena dados em locais distribuídos geograficamente para que os tempos de ida e volta de e para um navegador geograficamente local sejam reduzidos.

As solicitações do navegador são roteadas para um CDN próximo, encurtando assim a distância física que os dados de resposta precisam percorrer. Os CDNs também são capazes de lidar com grandes volumes de tráfego e fornecer segurança contra alguns tipos de ataques.

Um CDN obtém seus recursos por meio de um Internet Exchange Point (IXP), nós que fazem parte do backbone da Internet (em maiúsculas). Há etapas a serem executadas para configurar o roteamento de solicitação para ir para um CDN em vez do servidor host. A próxima etapa é verificar se o CDN possui o conteúdo atual do seu site.

Antigamente, a maioria dos CDNs apoiava o método push: um site enviava novo conteúdo para um hub CDN, que era então distribuído para nós geograficamente dispersos.

Atualmente, a maioria dos CDNs usa os protocolos de cache descritos acima (ou semelhantes) para 1) baixar novos recursos e 2) atualizar os existentes. O navegador ainda tem seu cache e nada disso muda. Tudo o que um CDN faz é agilizar as transferências de novos recursos.