Cache do site & cache interno do servidor: como funciona o cache do WordPress
Ao verificar o cache do site e o cache interno do servidor em um servidor com Nginx + Apache, as requisições de página do WordPress desceram na ordem navegador, CDN, cache de página, OPcache e Redis e pararam na camada que tinha uma cópia. As requisições de página que chegaram direto ao servidor de origem receberam do nginx, na hora, o arquivo HTML criado pelo WP Rocket, sem descer até o PHP e o banco de dados.
Ⅰ. Estrutura do cache do WordPress
Na computação, cache é uma técnica que armazena dados temporariamente para que possam ser acessados rápido; na web ele funciona pelo mesmo princípio e contribui muito para o desempenho.
Como o cache guarda os dados, o visitante que acessa um site não precisa pedir tudo de novo ao servidor a cada vez: os dados armazenados carregam rápido e o tempo de carregamento da página diminui. Isso reduz a carga do servidor e melhora a experiência do usuário.
Os caches usados nas requisições do WordPress se dividem em dois ramos: o cache do site e o cache interno do servidor. O padrão de cache HTTP, conforme descreve o MDN, chama de private cache o cache guardado só no navegador de um visitante e de shared cache os caches de CDN e proxy usados por muitos visitantes; neste post, os dois foram agrupados como cache do site.
O cache de página, o OPcache e o cache de objetos são caches ligados ao processo em que o WordPress é executado dentro do servidor. O padrão HTTP não tem uma categoria para eles, e a documentação oficial do WordPress os explica divididos em plugins de cache (cache de página), cache de objetos e cache do servidor (caches de opcode como o OPcache).
Todos os campos em que o cache é usado estão no post Cache: definição e todos os campos em que o cache é usado e as quatro vertentes da otimização de desempenho, incluindo o cache, no post Otimização de desempenho web: estrutura e definição dedicado ao assunto.
No simulador abaixo, escolha um cache na árvore à esquerda e clique em um botão para ver em qual camada a requisição para. A camada que quem administra um site WordPress liga primeiro com um plugin de cache é o cache de página.
| Camada | Onde fica | O que guarda | Exemplo com Nginx + Apache |
|---|---|---|---|
| Cache do navegador | Dispositivo do visitante | HTML · CSS · JS · imagens · fontes | CSS · imagens 7 dias |
| Cache de CDN · proxy | Na frente do servidor (borda · proxy reverso) | Cópias de páginas · arquivos estáticos | Bunny CDN |
| Cache de página | Disco · memória do servidor | HTML criado pelo PHP | WP Rocket + nginx |
| OPcache | Memória do servidor | Bytecode PHP | PHP 8.3, JIT desligado |
| Cache de objetos | Memória do servidor | Resultados de consultas · objetos | Redis |
Ⅱ. Cache do site
O cache do site é aquele em que o servidor informa, pelos cabeçalhos de resposta, como guardar o conteúdo, e o navegador do visitante e as CDNs ou proxies guardam uma cópia seguindo essa instrução. Os cabeçalhos típicos são [Cache-Control], [ETag] e [Expires]; quando o prazo de armazenamento acaba, uma requisição condicional ([304 Not Modified]) verifica se algo mudou.
1️⃣ Cache do navegador
O cache do navegador é o cache HTTP guardado no navegador do visitante: ele armazena HTML, CSS, JavaScript, imagens e fontes e, quando o mesmo recurso é pedido de novo, não vai até o servidor ou só verifica se houve mudança.
Quem define o prazo de armazenamento é o servidor, não o visitante. O servidor com Nginx + Apache abaixo indica 7 dias para CSS e imagens e responde às páginas HTML sem prazo, para que sejam verificadas a cada nova visita.
If-None-Match: "6ab12775-2ee8"cache-control: max-age=604800 expires: Sat, 17 Oct 2026 03:21:00 GMT etag: "6ab12775-2ee8"
etag: "6ac9298c-95575" last-modified: Fri, 09 Oct 2026 17:51:08 GMT
2️⃣ Cache de CDN · proxy
Os caches de CDN e proxy ficam entre os visitantes e o servidor de origem e são usados por muitos visitantes. O proxy direto fica na frente do lado do visitante, como numa rede corporativa, e o proxy reverso e a CDN, na frente do servidor; eles respondem com a cópia salva no lugar do servidor de origem.
Um proxy reverso típico é o Varnish Cache, e CDNs como Bunny CDN e Akamai seguem a mesma estrutura. Com DNS por região, os visitantes da região do servidor de origem se conectam direto a ele, e os de outras regiões recebem a resposta de um servidor de borda da CDN próximo (por exemplo, Bunny CDN), que guarda até o HTML.
A estrutura e as vantagens de uma CDN estão no post O que é CDN? Motivos para usar uma CDN e 5 vantagens dedicado ao assunto.
Ⅲ. Cache interno do servidor
O cache interno do servidor é o cache ligado ao processo em que o WordPress monta a página depois que a requisição chega ao servidor de origem. Um servidor com Nginx + Apache trata as requisições na ordem abaixo e, se uma etapa anterior encontra uma cópia, as etapas seguintes são puladas.
Na Cloudways e na ScalaHosting, dá para escolher Nginx + Apache como opção. Na Cloudways, você escolhe por aplicação entre a Hybrid stack (Nginx + Apache) e a Lightning stack (só Nginx); na ScalaHosting, você pode ativar no SPanel a configuração que coloca o Nginx na frente do Apache.
| Cache | O que guarda | Quando é gravado |
|---|---|---|
| 1️⃣ Cache de página | Página HTML pronta | 🅑 ⑤ Na resposta, o WP Rocket grava em arquivo |
| 2️⃣ OPcache | Código PHP compilado (bytecode) | 🅑 ② Quando um arquivo PHP roda pela primeira vez |
| 3️⃣ Cache de objetos | Pedaços de dados como resultados de consultas e opções | 🅑 ③ Quando o WordPress busca os dados pela primeira vez |
1️⃣ Cache de página
O cache de página também é chamado de cache de página inteira (full-page cache) e, como guarda HTML, às vezes é chamado de cache HTML. Ele grava como arquivo HTML estático a página web inteira criada pelo PHP e, para a mesma requisição de página, envia esse arquivo sem executar o PHP. É o caso 🅐 na ordem de processamento acima.
Ele fica na memória do servidor (RAM) ou em disco (HDD/SSD): a memória é rápida, mas cara e limitada em espaço, e o disco tem espaço de sobra, mas é relativamente lento.
| Variante | Exemplo | Como guarda e responde |
|---|---|---|
| Plugin de cache | WP Rocket · WP Super Cache · W3 Total Cache · Cache Enabler | O WordPress grava a página como arquivo HTML e o servidor web envia esse arquivo. |
| Cache do servidor web | Cache FastCGI do Nginx · LiteSpeed Cache | O próprio servidor web guarda a resposta do PHP e a envia na requisição seguinte. |
| Cache de proxy reverso | Varnish | Um servidor de cache colocado na frente do servidor web guarda a página e responde. |
Com Nginx + Apache, o nginx lê diretamente e envia o arquivo HTML criado pelo WP Rocket, e o cabeçalho de resposta recebe [x-rocket-nginx-serving-file: HIT]. Os passos para ativar e configurar o cache de página com o WP Rocket estão no post Guia de configuração do WP Rocket dedicado ao assunto.
2️⃣ OPcache
O OPcache guarda na memória o bytecode do código PHP já compilado, para que, ao executar o mesmo arquivo de novo, o parser do PHP seja pulado. Ele vem embutido desde o PHP 5.5; o APC e o XCache, usados no passado, não suportam o PHP 7 e já não são usados. É a etapa ② de 🅑 na ordem de processamento acima.
| Variante | Status | Descrição |
|---|---|---|
| Zend OPcache | Embutido desde o PHP 5.5 | É o cache de opcode padrão usado hoje, ativado com [opcache.enable=1]. |
| OPcache JIT | Incluído no OPcache desde o PHP 8 | Converte o bytecode mais uma vez em código de máquina para executá-lo; liga e desliga com [opcache.jit]. |
| APC | Desenvolvimento encerrado | Cache de opcode usado antes do OPcache; a função de cache de dados continuou no APCu. |
| XCache | Desenvolvimento encerrado | Não suporta o PHP 7. |
| WinCache | Para servidores Windows (IIS) | Cache de opcode que a documentação oficial do WordPress cita junto com o OPcache. |
O OPcache é ativado com a configuração do PHP [opcache.enable=1], e o JIT, que chegou com o PHP 8, pode ser desligado à parte com [opcache.jit=disable]. A instalação e a configuração estão no post Zend OPcache: conceito, instalação e configuração dedicado ao assunto.
3️⃣ Cache de objetos
O cache de objetos guarda resultados de consultas ao banco de dados ou objetos calculados em um armazenamento em memória como Redis ou Memcached. Por padrão, o WordPress lembra os objetos só dentro de uma única requisição; é preciso conectar um armazenamento como o Redis para que os resultados fiquem depois que a requisição termina. É a etapa ③ de 🅑 na ordem de processamento acima.
| Variante | Tipo | Fica depois da requisição? | Descrição |
|---|---|---|---|
| WP_Object_Cache | Padrão do WordPress | Não | Cache embutido que lembra só dentro de uma única requisição. |
| Redis | Cache de objetos | Sim | Armazenamento em memória separado, conectado pelo drop-in do plugin Redis Object Cache. |
| Memcached | Cache de objetos | Sim | Armazenamento em memória separado. |
| APCu | Cache de objetos | Sim (dentro do mesmo servidor) | Guarda na memória compartilhada usada pelo PHP. |
| Arquivo | Cache de objetos | Sim | Guarda como arquivos em disco. |
| Buffer pool do InnoDB | Cache próprio do banco de dados · não é cache de objetos | Sim | O MySQL e o MariaDB mantêm dados de tabelas e índices na memória. |
| Cache de consultas | Cache próprio do banco de dados · não é cache de objetos | — | Removido no MySQL 8.0; ainda existe no MariaDB, mas vem desligado por padrão. |
O WordPress se conecta ao Redis pelo arquivo drop-in ([object-cache.php]) que o plugin Redis Object Cache adiciona. O passo a passo da instalação está no post Instalação e configuração do Redis Cache no WordPress dedicado ao assunto.
🔢 FAQ & conteúdo recomendado
ℹ️ Aviso de afiliados
O conteúdo deste site contém links de afiliados. Quando um visitante compra um produto ou serviço por meio de um desses links, o site recebe uma comissão do vendedor. O valor que o comprador paga (em promoções, ele diminui ↓) não aumenta por causa disso. Preços, descontos e informações de estoque valem para o momento em que o texto foi escrito e podem ter mudado, por isso confirme com o vendedor antes de comprar. Os produtos são escolhidos e avaliados por critérios próprios, e o recebimento de comissão não influencia a ordem de apresentação nem o conteúdo das avaliações.