Cache: como funciona e por que deixa seu site mais rapido?

Seu site pode estar perdendo visitantes simplesmente porque cada pagina e gerada do zero a cada visita. O cache e uma das estrategias mais eficazes para reduzir o tempo de carregamento, aliviar a carga do servidor e melhorar a experiencia do usuario. Neste artigo, vamos explorar em profundidade o que e cache, como ele funciona e como implementa-lo corretamente no seu site.

O que e cache?

Cache e um armazenamento temporario de dados frequentemente acessados. A ideia e simples: em vez de buscar ou gerar a mesma informacao repetidamente, voce a mantem proxima ao ponto de consumo para que o acesso seja quase instantaneo. Tecnicamente, cache e qualquer camada de armazenamento intermediario que reduz a latencia de acesso aos dados originais.

Analogia: a geladeira e a despensa

Pense na sua cozinha. A despensa (ou supermercado) e a origem dos alimentos — la tem de tudo, mas esta longe e demora para acessar. A geladeira e seu cache: guarda os itens que voce usa com frequencia (leite, ovos, queijo), permitindo acesso rapido sem precisar ir ao supermercado toda vez. Assim como a geladeira, o cache tem capacidade limitada e precisa ser atualizado (invalidation) quando os dados originais mudam.

Tipos de cache na web

O ecossistema web possui diversos niveis de cache, cada um atuando em uma camada diferente da arquitetura. Entender todos eles e fundamental para criar uma estrategia completa de otimizacao.

1. Cache do navegador (Browser Cache)

O navegador armazena arquivos estaticos (imagens, CSS, JavaScript, fontes) no disco rigido do usuario. Quando ele visita novamente a mesma pagina, o navegador recupera esses arquivos do disco local em vez de baixa-los novamente do servidor. Isso reduz drasticamente o tempo de carregamento em visitas subsequentes. E controlado por headers HTTP como Cache-Control e Expires.

2. Cache de servidor (Server Cache)

No lado do servidor, ferramentas como Varnish (reverse proxy cache), Redis (cache em memoria) e Nginx fastcgi_cache armazenam paginas HTML prontas ou resultados de consultas ao banco de dados. Em vez de executar PHP, consultar o MySQL e montar a pagina a cada request, o servidor entrega a versao em cache, reduzindo o TTFB de 500ms para 5ms.

3. Cache de CDN (Content Delivery Network)

CDNs como Cloudflare, Fastly, Akamai e BunnyCDN possuem servidores em centenas de locais ao redor do mundo (edge servers). Quando um usuario acessa seu site, o CDN entrega o conteudo estatico a partir do servidor mais proximo geograficamente. Isso reduz a latencia de rede e melhora o TTFB global. CDNs tambem podem armazenar paginas HTML completas em cache, funcionando como um cache de aplicacao distribuido.

4. Cache de banco de dados (Database Cache)

Bancos de dados tambem possuem seus proprios mecanismos de cache. O MySQL Query Cache (removido no MySQL 8.0, mas presente em versoes anteriores) armazenava o resultado textual de consultas SQL. Ferramentas como Redis e Memcached sao usadas para cachear resultados de consultas frequentes em memoria RAM, evitando que o banco processe a mesma query repetidamente. Isso e especialmente importante em sites com alto trafego e muitas consultas ao banco.

5. Cache de DNS

Quando voce digita um dominio no navegador, o sistema precisa converter esse nome em um endereco IP atraves de uma consulta DNS. Sem cache, cada visita exigiria uma nova consulta aos servidores DNS, o que pode levar de 20ms a 200ms. Dispositivos (sistema operacional), navegadores e ISPs (Provedores de Internet) armazenam em cache os resultados de consultas DNS recentes, tornando a resolucao praticamente instantanea em repeticoes.

Headers HTTP de cache

O controle de cache no nivel HTTP e feito atraves de headers que o servidor envia junto com cada recurso. Os principais sao:

Cache-Control

O header mais moderno e flexivel. Suas diretivas principais incluem:

• max-age=<segundos>: tempo maximo que o recurso pode ser mantido em cache (ex: max-age=31536000 para 1 ano)
• public: o recurso pode ser cacheado por qualquer intermediario (CDN, proxy, navegador)
• private: o recurso so pode ser cacheado pelo navegador do usuario, nao por proxies intermediarios
• no-cache: o recurso nao pode ser usado sem antes verificar com o servidor se houve modificacao (revalidacao)
• no-store: o recurso nao pode ser armazenado em cache de forma alguma (usado para dados sensiveis)
• must-revalidate: o cache deve revalidar o recurso com o servidor quando expirar
• immutable: indica que o recurso nunca muda (usado com max-age longo para arquivos com hash no nome)

ETag e Last-Modified

O ETag e um identificador unico (geralmente um hash do conteudo) que o servidor envia. Quando o navegador faz uma requisicao condicional com o header If-None-Match, o servidor compara o ETag e responde com 304 Not Modified (sem reenviar o recurso) se ele nao tiver mudado. O Last-Modified funciona de forma similar, mas usando uma data/hora em vez de um hash.

Cache busting: como forcar a atualizacao de recursos

Quando voce define max-age=31536000 para um arquivo CSS, o navegador vai mante-lo em cache por um ano. Mas quando voce atualiza o CSS, precisa garantir que os usuarios recebam a nova versao. A solucao e o cache busting, que funciona alterando a URL do recurso sempre que ele muda. As principais estrategias sao:

• Filename Hashing: adicionar um hash do conteudo ao nome do arquivo: style.abc123.css. Quando o conteudo muda, o hash muda e o navegador baixa o novo arquivo.
• Query String Versioning: adicionar um numero de versao na URL: style.css?v=2. Menos confiavel, pois alguns proxies ignoram query strings em caches.
• Content-based chunk naming: usado por bundlers como Webpack e Vite, que geram nomes de arquivo baseados no hash do conteudo automaticamente.

Cache no servidor: Varnish, Redis e Nginx

Varnish Cache

O Varnish e um reverse proxy HTTP que fica entre o cliente e o servidor web. Ele armazena em cache as paginas HTML geradas pelo servidor e as entrega em microssegundos. Sua linguagem de configuracao (VCL) permite regras complexas de cache, como definir quais URLs cachear por quanto tempo e como tratar cookies de sessao. Sites que usam Varnish relatam reducao de 90-99% no tempo de resposta e capacidade de servir milhares de requests por segundo com um unico servidor.

Redis

O Redis e um armazenamento de dados em memoria, geralmente usado como cache de banco de dados, sessoes de usuario e fragmentos de HTML. Diferente do Varnish, que cachea paginas HTTP completas, o Redis armazena dados estruturados: resultados de queries SQL, dados de API, objetos serializados. Ele e extremamente rapido (sub-milissegundo) e suporta estruturas como listas, sets, hashes e sorted sets.

Nginx fastcgi_cache

O Nginx possui um modulo de cache integrado chamado fastcgi_cache que armazena a saida de processos PHP-FPM em disco. Isso permite que o Nginx sirva paginas estaticas diretamente sem passar pelo PHP, reduzindo drasticamente o uso de CPU e o tempo de resposta. Ideal para sites WordPress com trafego moderado a alto.

Cache em WordPress

O WordPress, por padrao, gera cada pagina dinamicamente com PHP e MySQL a cada visita. Sem cache, um site WordPress pode facilmente levar 2-5 segundos para carregar. As principais estrategias de cache para WordPress incluem:

• Plugins de cache: WP Rocket, W3 Total Cache, WP Super Cache, Flying Press. Esses plugins geram arquivos HTML estaticos e os servem para usuarios anonimos, ignorando o processamento PHP.
• Cache de banco de dados: plugins como WP-Optimize e Redis Object Cache armazenam consultas SQL frequentes em memoria.
• CDN: Cloudflare com APO (Automatic Platform Optimization) cacheia paginas HTML completas nos edge servers.
• Server-level: configuracao de Nginx fastcgi_cache ou Varnish no servidor para cachear paginas mesmo sem plugin.

Cache com CDN

Uma CDN leva o cache para um nivel global. Cada edge server da CDN armazena copias dos seus arquivos estaticos (e, em alguns casos, do HTML). Quando um usuario no Japao acessa seu site hospedado no Brasil, a CDN entrega os arquivos a partir de um edge server em Tokyo. Os principais conceitos de cache em CDN incluem:

• Edge Cache TTL: tempo que o recurso fica armazenado no edge server (controlado pelo header s-maxage ou pelas regras de cache da CDN)
• Purge: processo de limpeza forcada do cache. CDNs como Cloudflare permitem purge por URL, por prefixo ou por tag.
• Cache Rules: regras que definem quais URLs cachear, por quanto tempo e com quais headers.
• Worker/Edge computing: CDNs modernas (Cloudflare Workers, Fastly Compute) permitem executar logica programavel no edge, incluindo controle de cache personalizado.

Cache invalidation (invalidação de cache)

Ta aqui um dos maiores desafios do cache: saber quando limpar. Invalidação de cache e o processo de remover ou atualizar dados em cache quando o conteudo original muda. Se voce nao invalidar o cache corretamente, usuarios podem ver conteudo desatualizado. As estrategias comuns incluem:

• TTL (Time To Live): o cache expira automaticamente apos um periodo definido
• Event-driven invalidation: quando um post e publicado, um hook dispara a limpeza do cache das URLs afetadas
• Purge manual: ferramentas de administracao permitem limpar o cache sob demanda
• Cache tags: CDNs como Cloudflare e Fastly suportam marcar URLs com tags e invalidar todas as URLs com uma tag especifica

Como configuramos cache na CloudBird

Em todos os sites que entregamos, implementamos uma estrategia de cache em tres camadas que garante performance maxima sem sacrificar a atualizacao do conteudo:

• CDN com Cloudflare: configuracao de cache rules para assets estaticos (max-age de 1 ano) e HTML (cache de 30 minutos com revalidacao)
• Browser caching via headers: enviamos Cache-Control: public, max-age=31536000, immutable para CSS, JS e imagens. Para paginas HTML, usamos no-cache com ETag para revalidacao eficiente.
• Cache de servidor Nginx: aplicamos fastcgi_cache em sites WordPress com regras que respeitam sessoes de login e cookies de administracao, garantindo que usuarios logados nunca vejam cache.
• Cache busting automatizado: todos os recursos estaticos recebem nomes com hash no build, garantindo que mudancas sejam propagadas instantaneamente sem necessidade de purge manual.

O resultado: sites que carregam em menos de 1 segundo mesmo em conexoes 3G, com TTFB tipicamente abaixo de 200ms para usuarios no Brasil e abaixo de 500ms para usuarios em qualquer lugar do mundo.