Forçar o armazenamento em cache do Varnish no LWS

Procédure

Nesta documentação, explicaremos passo a passo como forçar o Varnish e os navegadores a manter seus recursos em cache, mesmo quando eles enviam solicitações Pragma: no-cache ou Cache-Control: no-cache.

1. Contexto e arquitetura do LWS

Os pacotes de hospedagem compartilhada e cPanel/VPS gerenciados do LWS são baseados na arquitetura :

Navegador ⇄ NGINX (SSL + HTTP/2) ⇄ Cache Varnish ⇄ Apache/PHP-FPM

• O NGINX gerencia o TLS e comprime o conteúdo.
• O Varnish (Fastest Cache) é usado como proxy reverso para armazenar respostas HTTP.
• O Apache ou o PHP-FPM geram a resposta final quando o Varnish não tem HIT.

Quando tudo está corretamente configurado, o Varnish pode ser até 1000 vezes mais rápido do que o acesso direto ao PHP, ao mesmo tempo que alivia o CPU do servidor.

2. Lembrete: como é que o Varnish decide fazer cache?

[Dicas]O Varnish ignora por defeito o Cache-Control: no-cache enviado pelo navegador para ficheiros estáticos, mas respeita a "lógica de revalidação" se o objeto já estiver armazenado em cache[/tips].

3. Controlar o tempo de vida através de .htaccess

Active o módulo mod_headers (é a predefinição no LWS) e coloque o seguinte snippet onde quiser:

  Header set Cache-Control "public, max-age=3600, s-maxage=3600, stale-while-revalidate=60, stale-if-error=86400" Header set Expires "Thu, 31 Dec 2037 23:55:55 GMT"

• max-age: duração (em segundos) no browser.
• s-maxage: duração específica para caches partilhadas (Varnish/CDN).
• stale-while-revalidate: permite que o Varnish sirva conteúdo obsoleto enquanto o actualiza em segundo plano.
• stale-if-error: serve a versão desactualizada se o backend responder com erro (à prova de falhas).

3.1 Direcionamento por pasta

Colocar o mesmo ficheiro .htaccess na pasta "/images/" aplica a regra apenas à pasta "images".

3.2 Direcionamento por extensão

  
    Conjunto de cabeçalhos Cache-Control "public, max-age=2592000, s-maxage=2592000, immutable".  

immutable: diz ao navegador que não é necessária qualquer revalidação até o objeto expirar; ideal para ficheiros com versões (style.483bf.css).

3.3 Cache curta para HTML

  Conjunto de cabeçalhos Cache-Control "public, max-age=300, s-maxage=600, must-revalidate".

Expira após 5 min do lado do cliente e 10 min do lado do Varnish, depois deve ser validado.

4. Cenários de utilização na vida real

5. Eliminar ou invalidar a cache

1. A partir do painel LWS: Otimização e Desempenho > Cache LWS > Esvaziar cache.
2. HTTP PURGE (se ativado):

   curl -X PURGE -H "Host: example.com" https://exemple.com/chemin/ressource.jpg

3. Banir por expressão (VCL avançada):

   ban req.http.host == "exemplo.com" && req.url ~ "/images/"

6. Teste e depuração

curl -I https://exemple.com/style.css

Veja :

• Idade: 356 → Varnish serviu uma resposta com 356 s.
• Cache-Control: public, max-age=2592000, s-maxage=2592000, immutable
• X-Cache: HIT (ou MISS).

Com o Chrome/Edge: DevTools > Rede > Desativar cache pode simular um primeiro visitante.

7. Armadilhas comuns

1. Cookies desnecessários: muitos temas do WordPress definem um cookie mesmo para páginas públicas. Elimine-os ou desactive-os através de functions.php.
2. Query strings: por defeito, ?v=123 cria uma nova entrada na cache. Em vez disso, coloque a versão no nome do ficheiro.
3. Conteúdo sensível: formulários, páginas da área de clientes ➡ no-store, private, max-age=0.
4. Compressão Brotli/Gzip: activá-las antes da camada Varnish para evitar a duplicação da cache.

8. Resumo das melhores práticas

• Use s-maxage ⩾ max-age para manter um cache proxy que seja mais longo que o cache do navegador.
• Coloque immutable em qualquer arquivo cujo nome contenha um hash.
• Não misture Obsolete Expires com max-age, exceto para navegadores mais antigos.
• Documente seus TTLs em um arquivo CACHE_POLICY.md para a equipe.

9. Recursos úteis

• LWS: Acelere seu site com o Fastest Cache
• Blog do LWS: Como obter um site com melhor desempenho com o Varnish Cache

A sua cache Varnish está agora sob controlo!