Aproveitar armazenamento em cache do navegador

Esta regra é acionada quando o PageSpeed Insights detecta que a resposta do servidor não inclui cabeçalhos explícitos de armazenamento em cache ou se os recursos são especificados para ser armazenados em cache somente por um curto período de tempo.

Visão geral

O armazenamento em cache do navegador para recursos estáticos pode poupar tempo ao usuário que visitar seu site mais de uma vez. Os cabeçalhos de armazenamento em cache devem ser aplicados a todos os recursos estáticos armazenáveis, e não somente a um pequeno subconjunto (como imagens). Os recursos armazenáveis incluem arquivos JS e CSS, arquivos de imagem e outros arquivos de objetos binários (arquivos de mídia, PDFs etc.). Em geral, o HTML não é estático e não deve ser considerado armazenável por padrão. Considere qual política de armazenamento em cache funcionará adequadamente para o HTML do seu site.

Recomendações

Habilite o armazenamento em cache do navegador em seu servidor. Os recursos estáticos terão um tempo de uso no cache de pelo menos uma semana. Para recursos de terceiros, como anúncios ou widgets, eles terão um tempo de uso no cache de pelo menos um dia. Para todos os recursos armazenáveis, recomendamos as seguintes configurações:

  • Defina Expires (Validades) para pelo menos uma semana e, de preferência, até um ano no futuro. Preferimos Expires em relação a Cache-Control: max-age (Controle de cache: idade máxima) porque ele conta com um suporte mais amplo. Não o defina para além de um ano no futuro, pois isso viola as diretrizes da RFC.
  • Se você souber exatamente quando um recurso será alterado, é permitido estabelecer uma validade mais curta. No entanto, se você acha que ele "poderá mudar em breve", mas não sabe quando, defina uma validade mais longínqua e use o reconhecimento impressão digital de URL (descrito abaixo).

Cabeçalhos "Expires" e "Cache-Control: max-age"

Estes recursos especificam o período de tempo no qual o navegador pode usar o recurso em cache sem verificar se uma nova versão está disponível no servidor da Web. Eles são "cabeçalhos fortes de armazenamento em cache" que se aplicam incondicionalmente. Assim que eles estiverem definidos, e o download do recurso for feito, o navegador não emitirá solicitações GET para o recurso até a data de vencimento ou até que a idade máxima seja atingida, ou o cache seja apagado pelo usuário.

Cabeçalhos "Last-Modifed" e "ETag"

Estes recursos especificam como o navegador deve determinar se os arquivos são os mesmos para fins de armazenamento em cache. No cabeçalho Last-Modified (Última modificação), trata-se de uma data. No cabeçalho ETag, pode ser qualquer valor que identifique um recurso (normalmente versões de arquivo ou hashes de conteúdo). Last-Modified é um cabeçalho "fraco" de armazenamento em cache porque o navegador aplica uma heurística para determinar se deve buscar, ou não, o item no cache.

Estes cabeçalhos permitem que o navegador atualize de forma eficiente seus recursos em cache por meio da emissão de solicitações GET condicionais quando o usuário recarrega explicitamente a página. GETs condicionais não retornam a resposta completa, exceto se o recurso for alterado no servidor e, portanto, tiver menor latência do que GETs inteiros.

Que cabeçalhos de armazenamento em cache devo usar?

É importante especificar um cabeçalho de Expires ou Cache-Control max-age e um de Last-Modified ou ETag para todos os recursos armazenáveis. Fica redundante especificar Expires e Cache-Control: max-age, ou ainda Last-Modified e ETag.

Utilização do reconhecimento de URL

No caso de recursos que mudam ocasionalmente, podemos fazer com que o navegador armazene o recurso em cache até que ele seja alterado no servidor, altura em que o servidor informa ao navegador que uma nova versão está disponível. Podemos fazer isso dando a cada versão do recurso um URL único. Por exemplo, digamos que tinha um recurso chamado "my_stylesheet.css". Podemos renomear o arquivo para “my_stylesheet_fingerprint.css”. Quando o recurso muda, o mesmo acontece com sua impressão digital, e também o URL é alterado. Assim que o URL muda, o navegador é forçado a buscar novamente o recurso. O reconhecimento nos permite definir datas de vencimento mais distantes no futuro, até mesmo para recursos que mudam com frequência.

Uma maneira comum de aplicar o reconhecimento de impressão digital é usar um número hexadecimal de 128 bits que codifica a hash do conteúdo do arquivo.

Outra estratégia é criar um novo diretório para cada nova versão do aplicativo e inserir todos os recursos de cada versão no diretório associado. Essa opção apresenta uma desvantagem: mesmo que um recurso não mude de uma versão para a outra, o URL será alterado e forçará um novo download. O uso de hashes de conteúdo não enfrenta esse problema, mas é um pouco mais complexo.