Você está encontrando o aviso “Especificar um validador de cache” no Pingdom, GTmetrix ou Google PageSpeed Insights no seu site WordPress? Isso acontece quando existe uma ausência de cabeçalhos de armazenamento de cache HTTP, os quais devem ser incluídos em todas as respostas dadas pelo servidor de origem, já que validam e definem a extensão do cache. Se os cabeçalhos não forem encontrados, será constantemente feita uma nova solicitação a esse recurso, o que sobrecarregará o seu servidor. A utilização de cabeçalhos de armazenamento em cache garante que os pedidos seguintes não precisam de ser carregados a partir do servidor, poupando largura de banda e melhorando o desempenho do usuário.
O aviso do Pingdom afirma o seguinte:
Os seguintes recursos não têm um validador de cache. Recursos que não especificam um validador de cache não podem ser atualizados eficientemente. Especifique um cabeçalho Last-Modified ou ETag para ativar a validação de cache para os seguintes recursos.
Siga os passos abaixo para corrigir o aviso “Especificar validador de cache”.
Corrigir o Aviso “Especificar um Validador de Cache”
Em relação a esse aviso, a primeira informação importante é que você apenas poderá corrigir isso para solicitações que estão no seu servidor. Se você tem solicitações de terceiros, não há nada que possa fazer, já que não possui controle sobre os servidores web. Mas pode sempre compartilhar esse artigo com eles. E vale a pena lembrar que, com o Pingdom, você pode precisar executar o teste algumas vezes. Pode ser que o aviso apareça uma primeira vez e seja eliminado na segunda. Quando você executa a ferramenta pela primeira vez, ela prepara o cache dos ativos que são apresentados pelo servidor.
Existem quatro tipos de cabeçalhos que podem ser utilizados de diferentes formas para corrigir esse aviso. É aqui que a situação pode ficar um pouco mais confusa, mas tentaremos explicar isso da forma mais fácil possível.
Cabeçalhos que Validam o Cache
Os dois primeiros cabeçalhos são o last-modified e o ETag. Esses cabeçalhos ajudam o navegador a determinar se o arquivo foi alterado desde a última vez que foi solicitado. Ou, dito de outra forma, eles validam o cache.
1. Last-Modified
O cabeçalho last-modified é por norma enviado automaticamente a partir do servidor. É um cabeçalho que você geralmente não terá de adicionar manualmente. Ele é enviado para verificar se o arquivo no cache do navegador foi modificado desde a última vez em que foi solicitado. Você pode consultar a solicitação do cabeçalho no Pingdom ou usar o Chrome DevTools para ver o valor do cabeçalho na última modificação.
2. ETag
O cabeçalho ETag é também muito semelhante ao cabeçalho last-modified. É também utilizado para validar o cache de um arquivo. Se estiver correndo o Apache 2.4 ou uma versão acima, o cabeçalho ETag já será adicionado automaticamente com a diretiva FileETag. E, em relação ao NGINX, o cabeçalho ETag é desde 2016 ativado por padrão.
Você pode ativar o cabeçalho ETag manualmente no NGINX usando o seguinte código.
etag onCabeçalhos que Determinam o Tamanho do Cache
Os cabeçalhos seguintes são o Cache-Control e o Expires. Esses cabeçalhos ajudam a determinar quanto tempo o arquivo deve ser mantido no cache antes de procurar uma nova cópia no servidor. Você deve lembrar que, para corrigir os avisos que você vê no Pingdom ou GTmetrix, é necessário ter um cabeçalho que valida o cache, e outro que determina o tamanho do cache.
3. Cache-Control
O Cache-Control é um cabeçalho composto por diferentes diretivas que permitem definir o tamanho do cache. Eis algumas das diretivas mais comuns:
-
-
- max-age:Define a quantidade de tempo que um arquivo deve permanecer armazenado em cache.
- public:Permite que qualquer cache armazene a resposta publicamente.
- private:Só é armazenável em cache pelo navegador que acede ao o arquivo.
-
No exemplo supracitado, podemos observar que o recurso está usando a diretiva max-age. 604800 segundos seria igual a um cache de sete dias. Para configurar isso no Apache, só precisa de adicionar o seguinte código ao seu arquivo .htaccess.
<filesMatch ".(ico|pdf|flv|jpg|jpeg|png|gif|js|css|swf)$">
Header set Cache-Control "max-age=604800, public"
A fim de configurar isso no NGINX, só precisa de adicionar o seguinte código ao seu arquivo de configuração. Todos os arquivos de configuração do NGINX estão localizados no /etc/nginx/ O arquivo de configuração principal é /etc/nginx/nginx.conf.
location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ {
add_header Cache-Control "public";
}Para ficar sabendo mais sobre as diferentes diretrizes, veja esse artigo detalhado sobre Cache-Control .
4. Expires
Por último você tem o cabeçalho expires. De acordo com esse artigo da Google Developers, HTTP Caching: O cabeçalho Cache-Control foi definido como parte da especificação HTTP/1.1 e substitui os cabeçalhos anteriores (nesse caso, o cabeçalho Expires) usados para definir as políticas de cache de resposta. Todos os navegadores modernos suportam o Cache-Control, por isso ele é tudo o que você precisa. Contudo, ter os dois só será vantajoso, mas saiba que apenas um será usado. O cabeçalho Expires usa uma data real, enquanto o cabeçalho Cache-Control permite especificar um período de tempo antes que a expiração ocorra.
Para adicionar o cabeçalho Expires ao Apache, só precisa de adicionar o seguinte código ao seu arquivo .htaccess.
## EXPIRES HEADER CACHING ##
ExpiresActive On
ExpiresByType image/jpg "access 1 year"
ExpiresByType image/jpeg "access 1 year"
ExpiresByType image/gif "access 1 year"
ExpiresByType image/png "access 1 year"
ExpiresByType text/css "access 1 month"
ExpiresByType application/pdf "access 1 month"
ExpiresByType application/javascript "access 1 month"
ExpiresByType application/x-javascript "access 1 month"
ExpiresByType application/x-shockwave-flash "access 1 month"
ExpiresByType image/x-icon "access 1 year"
ExpiresDefault "access 7 days"
## EXPIRES HEADER CACHING ##Garanta que adiciona o bloco de cabeçalhos Expires abaixo de coisas como mod_rewrite, GZIP, etc. É mais seguro fazer isso na parte inferior do arquivo.
Para adicionar os cabeçalhos Expires no NGINX, só precisa de adicionar o seguinte código ao seu arquivo de configuração.
location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ {
expires 7d;
}Em muitas situações no NGINX, o cabeçalho Cache-Control e o cabeçalho Expires são usados em conjunto, mesmo que isso não seja tecnicamente necessário:
location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ {
expires 7d;
add_header Cache-Control "public";
}Todos os cabeçalhos que mencionámos são adicionados por padrão em todos os servidores Kinsta, então, se você for um cliente Kinsta, jamais encontrará aviso e não precisará de se preocupar. A maioria dos provedores de CDN de entidades externas, como o KeyCDN e o Cloudflare, também adiciona automaticamente esses cabeçalhos ao apresentar os seus ativos. Se você está vendo os avisos, pode ser que o seu host esteja correndo um software desatualizado ou então pode ter configurado incorretamente o servidor. Normalmente, vemos isso em hosts compartilhados. Ou talvez você esteja configurando seu próprio servidor e pode ser que alguns dos cabeçalhos acima talvez ainda não tenham sido adicionados.
E se tudo correr bem, e você não tiver solicitações de terceiros que não estejam usando o cabeçalho corretamente, notará uma melhoria na sua pontuação em sites de teste de velocidade, como o Pingdom (exemplo abaixo).
