Limpar tudo ou limpeza seletiva
Limpar tudo esvazia a cache inteira de uma zona numa só chamada e é a escolha certa depois de um deploy que mexeu em muitos ficheiros. A limpeza seletiva esvazia apenas os URLs, hostnames, tags ou prefixos indicados, mantém o resto da cache quente e é a escolha certa para um ficheiro isolado.
Última atualização:
A Cloudflare tem cinco formas de invalidar conteúdo em cache. Desde 3 de abril de 2025 as cinco estão disponíveis em todos os planos, incluindo o gratuito. Antes dessa data três eram exclusivas do Enterprise, e é por isso que ainda há muito artigo por aí a dizer o contrário.
Os cinco métodos comparados
| Método | O que esvazia | Quando faz sentido | Planos |
|---|---|---|---|
| Limpar tudo | A cache inteira de uma zona | Um deploy que mexeu em muitos ficheiros, ou quando não sabe o que mudou | Todos |
| Por URL | Os URLs exatos que indicar | Um ficheiro que acabou de substituir | Todos |
| Por hostname | Tudo o que é servido a partir de um hostname | Um subdomínio que refez, por exemplo img.example.com | Todos |
| Por prefixo | Tudo o que está sob um caminho de URL | Uma secção inteira, por exemplo example.com/blog/ | Todos |
| Por tag | Tudo o que tem um cabeçalho Cache-Tag | Conteúdo agrupado por lógica de negócio em vez de por caminho | Todos |
Quando limpar tudo
Limpar tudo é uma chamada, não precisa de lista de ficheiros e não deixa nada de fora. É todo o seu atrativo, e é real: depois de regenerar um site estático em que mudou o hash de cada ficheiro, pôr-se a enumerar alterações é trabalho deitado fora.
O custo é que o rácio de acerto da cache dessa zona cai a zero. Cada visita depois da limpeza vai à sua origem até a cache voltar a encher. Num site pequeno nem se nota. Num site com tráfego a sério é um pico de carga na origem que provocou você, e se essa origem for um único servidor modesto, é precisamente esse pico que a deita abaixo.
Quando limpar de forma seletiva
A limpeza seletiva mantém quente o resto da cache. Mudou uma folha de estilos e não há motivo para que todas as fotografias de produto do site voltem a ser pedidas à origem.
Em troca tem de ser preciso. Uma limpeza por URL corresponde exatamente ao URL que lhe der, query string e protocolo incluídos. Estes três são três entradas de cache diferentes:
https://example.com/style.csshttps://example.com/style.css?v=2https://www.example.com/style.css
Limpar o primeiro não faz nada pelos outros dois. É de longe o motivo pelo qual se conclui que «a limpeza não funciona»: funcionou, num URL que ninguém pede.
Hostname, prefixo e tag
Entre «um URL exato» e «a zona inteira» há três opções intermédias, subaproveitadas porque durante anos custaram dinheiro de Enterprise:
- Hostname é a mais grosseira das três e não precisa de preparação. Refez tudo o que está sob
cdn.example.com? Uma chamada. - Prefixo trabalha sobre caminhos, por isso
example.com/blog/esvazia todos os artigos sem tocar na loja. - Tag é a mais poderosa e a única que exige preparação: a sua origem tem de emitir um cabeçalho
Cache-Tag. Feito isso, pode limpar «tudo o que diz respeito ao produto 4471» independentemente de quantos URLs isso abranja.
Uma decisão de cinco segundos
- Sabe exatamente que ficheiros mudaram e são menos de cem? Limpe por URL.
- Mudou um subdomínio ou uma secção inteira? Limpe por hostname ou por prefixo.
- A sua origem já emite
Cache-Tag? Limpe por tag. - Caso contrário, ou se tiver dúvidas e o site for pequeno? Limpe tudo.
Como o FlarePurge resolve isto
O FlarePurge cobre a limpeza total e a seletiva por URL e por hostname, que entre as três apanham a esmagadora maioria das limpezas reais. Cola os seus URLs e a aplicação divide-os em lotes sozinha, por isso uma lista de 90 URLs passa a três chamadas sem que tenha de pensar nisso.
Também faz limpezas em massa: todas as zonas favoritas de uma vez, ou todas as zonas de uma conta inteira com uma só confirmação, com a concorrência limitada para não esbarrar nos limites da Cloudflare. Esses limites estão documentados aqui.