# Object cache no WordPress: Configure em 4 passos O object cache persistente guarda resultados de consultas ao banco na memoria e corta o trabalho repetido do PHP. Segundo o web.dev (2024), um TTFB bom fica abaixo de 800 ms, e o object cache ataca exatamente esse tempo. Em sites dinamicos pesados, Redis costuma reduzir as consultas em 40% ou mais. Configure, valide o hit rate e so depois confie no ganho. O object cache no WordPress é um armazenamento em memoria que guarda o resultado de consultas ao banco de dados para não repetir a mesma query a cada visita. Sem ele, o WordPress nativo descarta esse cache no fim de cada requisicao. Com um backend persistente como Redis ou Memcached, o resultado sobrevive entre requisicoes e alivia o servidor. Este tutorial mostra quando o object cache vale a pena, como configurar em 4 passos e como validar o hit rate antes de declarar vitoria. A base é a experiência de operar performance em escala na conteudos de performance WordPress da FULL. --- ## Primeiros passos: O que o object cache resolve O object cache resolve um gargalo especifico do WordPress, que é o volume de consultas repetidas ao banco de dados MySQL: em sites dinamicos como WooCommerce ou membership, a mesma query pode rodar dezenas de vezes por página e responder por boa parte dos 800 ms de TTFB que separam um site rápido de um lento. O object cache persistente entrega esse resultado direto da memoria em microssegundos, sem tocar o banco de novo. Nos tickets da FULL (150 mil sites gerenciados), a maioria dos casos de "wp-admin lento" tem origem no banco, não no disco. A tabela abaixo separa o que cada camada de cache faz, para você não aplicar a ferramenta errada ao gargalo errado.
Object cache versus outras camadas de cache no WordPress
Camada O que armazena Quando ajuda
Object cache Resultado de queries ao banco e objetos PHP Sites dinamicos, wp-admin, WooCommerce
Cache de página HTML pronto da página inteira Paginas estaticas e visitantes anonimos
OPcache Bytecode PHP compilado Qualquer site, no nível do PHP
Entender essa separacao evita o erro comum de esperar que o object cache acelere uma landing page estatica, onde o cache de página faz o trabalho pesado. --- ## Por que o object cache não acelera todo site da mesma forma O object cache só acelera de verdade quando o gargalo do site é o banco de dados, e por isso um blog estatico com cerca de 20 posts e visitantes anonimos ganha quase nada com ele, enquanto uma loja WooCommerce com 5.000 produtos e usuários logados pode cortar 30% ou mais do tempo de resposta. No primeiro caso, o cache de página ja serve o HTML sem tocar o PHP. No segundo, a loja executa centenas de queries por requisicao, e ai o object cache persistente tende a derrubar o TTFB de forma visivel. De acordo com a documentacao oficial em developer.WordPress.org, que define a API WP_Object_Cache, o cache nativo é não persistente por padrao: ele vive apenas durante uma requisicao. É essa limitacao que um backend como Redis remove. A gente vê no suporte da FULL que ativar object cache em site errado não quebra nada, mas também não entrega o ganho esperado. --- ## Object cache persistente: Redis versus Memcached Object cache persistente significa que os dados sobrevivem entre requisicoes em vez de morrer no fim de cada acesso, e as duas opcoes dominantes nesse cenario sao o Redis 7.x e o Memcached, que juntos respondem por quase 100% das instalacoes que passam pela base da FULL. O Redis 7.x suporta estruturas de dados ricas, persistencia em disco e replicacao, o que o torna o padrao em hospedagem gerenciada moderna. O Memcached é mais simples: chave-valor puro na memoria, sem persistencia, útil quando a meta é velocidade bruta e baixo consumo de recurso. Para WordPress, o plugin Redis Object Cache (do Till Kruss) é o mais adotado, e a versão premium Object Cache Pro adiciona compressao e telemetria de hit rate. Nos ambientes que passam pela FULL, o Redis cobre a quase totalidade dos casos porque o ecossistema de plugins é mais maduro. A escolha tende a depender mais do que o host oferece do que de uma vantagem teorica isolada. --- ## Passo a passo: Como ativar object cache no WordPress Ativar object cache no WordPress leva 4 passos e exige que o servidor ja tenha Redis ou Memcached instalado. Antes de comecar, confirme com seu host: tentar ativar o drop-in sem o servico rodando derruba o wp-admin com fatal error. Os passos abaixo usam Redis, o caminho mais comum em 2026.

Legenda: o painel confirma o object cache conectado e o hit rate em tempo real, o sinal de que a configuração funcionou.

### Passo 1: Confirme o backend no servidor Verifique se o Redis está instalado e rodando antes de tocar no WordPress. Em servidores com acesso SSH, o comando `redis-cli ping` deve responder `PONG`. Em hospedagem gerenciada, essa informação aparece no painel ou no suporte do host. Pular esse passo é a causa numero um de fatal error no wp-admin que chega aos tickets da FULL. ### Passo 2: Instale o plugin Redis object cache Instale o plugin Redis Object Cache pelo repositorio oficial do WordPress, em Plugins, Adicionar Novo. Ele cria o drop-in `wp-content/object-cache.php` automaticamente quando você ativa a conexão. Não edite esse arquivo na mao: o plugin gerencia o ciclo de vida dele. ### Passo 3: Ative a conexão e ajuste o wp-config Adicione as credenciais do Redis no `wp-config.php` quando o host exigir host, porta ou senha especificos. Depois, clique em "Enable Object Cache" no painel do plugin. O status deve mudar para "Connected". Em ambientes com Redis compartilhado, defina um prefixo de chave único para evitar colisao entre sites. ### Passo 4: Valide o hit rate Acompanhe o hit rate no painel do plugin ou via Query Monitor por 24 a 48 horas. Um hit rate saudavel em site dinamico fica acima de 90%; valores baixos indicam invalidacao excessiva ou TTL mal configurado. So considere a tarefa concluida depois de ver o numero estabilizar. --- ## Cache premium gerenciado no bundle da FULL Configurar object cache manualmente exige acesso ao servidor e familiaridade com SSH, e nem todo time tem esse perfil técnico, por isso muitos sites acabam rodando sem nenhuma camada persistente mesmo quando precisam dela para escalar. O plano PRO da FULL custa R$849,90 e inclui plugins de performance premium como WP-Optimize e Perfmatters ja licenciados e prontos para ativar com um clique, em qualquer hospedagem. Diluido pelos 10 sites do plano, isso dá R$85 por site, valor que cobre licencas que avulsas passariam de US$59 cada por ano. A FULL não hospeda seu site: a gente complementa o host que você ja tem com a camada de otimização gerenciada, sem trocar de provedor. Para comparar as opcoes, veja a página de planos da FULL e cruze o custo por site com a stack que você roda hoje. --- ## Erros comuns ao configurar object cache O erro mais frequente, presente em boa parte dos chamados de object cache que chegam ao suporte da FULL, é ativar o drop-in object-cache.php sem o servico Redis rodando no servidor, o que gera um fatal error e derruba o wp-admin inteiro em poucos segundos sem mensagem clara. A correcao é remover `wp-content/object-cache.php` via FTP e so reinstalar o plugin depois de confirmar o backend. Outro erro recorrente: em WooCommerce, object cache persistente sem invalidacao correta de grupos transient faz o site servir carrinho e estoque desatualizados ao cliente. Em multisite com Memcached compartilhado, a falta de prefixo de chave causa colisao, servindo conteudo de um site dentro de outro. Esses tres padroes aparecem com frequencia nos tickets da FULL, e todos tem causa de configuração, não do object cache em si. Se o site ficou lento depois de atualizar, vale checar se um drop-in orfao sobrou de uma instalação anterior. --- ## Object cache no ecossistema de performance Object cache, cache de página e OPcache competem por tres gargalos diferentes do WordPress e não se substituem entre si, e por isso o ganho máximo de performance vem de empilhar as tres camadas juntas, não de escolher apenas uma delas para o site. O object cache compete por aliviar o banco de dados MySQL em sites dinamicos; o cache de página compete por servir HTML pronto a visitantes anonimos; o OPcache compete por evitar a recompilacao do bytecode PHP a cada requisicao. Em VPS com menos de 1GB de RAM, ativar Redis com `maxmemory` mal configurado tende a competir por memoria com o próprio MySQL e degradar o site inteiro: nesses casos, a configuração recomendada é limitar o Redis a 256MB e medir antes de subir. Quem combina object cache com um bom plugin de cache de página cobre as duas frentes que mais pesam no Core Web Vitals. Para aprofundar o tema, o FULL Academy reune os tutoriais de performance em um so lugar.

Perguntas frequentes sobre object cache

Por que o object cache não acelera todo site da mesma forma?

Porque o object cache só ataca o gargalo do banco de dados. Um blog estatico com visitantes anonimos é servido pelo cache de página e quase não toca o banco, entao o ganho é mínimo. Ja uma loja WooCommerce com usuários logados roda centenas de queries por requisicao, e ai o object cache persistente reduz o TTFB de forma clara. O ganho depende do quanto o site consulta o banco.

E possível usar object cache sem instalar Redis no servidor?

Sim, mas com ressalva importante. O WordPress tem um object cache nativo que funciona sem Redis, porem ele é não persistente: o cache vive apenas durante uma requisicao e é descartado no fim. Para ganho real entre requisicoes, você precisa de um backend persistente como Redis ou Memcached instalado no servidor. Sem ele, ativar o drop-in object-cache.php so gera fatal error.

Qual a diferenca entre object cache e cache de página no WordPress?

O object cache guarda resultados de consultas ao banco e objetos PHP, agindo no nível do código; o cache de página guarda o HTML final pronto da página inteira. O cache de página é mais rápido para visitantes anonimos porque nem executa o PHP. O object cache é o que importa em areas dinamicas como wp-admin, carrinho e checkout, onde o cache de página não pode atuar. Os dois se complementam.

Quanto de RAM o object cache consome em um site WordPress?

Depende do volume de queries, mas um site WordPress tipico consome entre 50MB e 256MB de RAM no Redis. Lojas WooCommerce grandes podem passar de 512MB. O ponto critico é definir o `maxmemory` do Redis: em VPS com menos de 1GB de RAM, limite a 256MB para não competir com o MySQL. Medir o consumo real por 48 horas antes de fixar o limite evita travamentos em horario de pico.

O que o object cache armazena no WordPress na pratica?

O object cache armazena resultados de queries ao banco, transients, opcoes do site e qualquer objeto que o código registre via API WP_Object_Cache. Na pratica, isso inclui dados de menus, taxonomias, metadados de posts e resultados de plugins. Com backend persistente, esses objetos sobrevivem entre requisicoes em vez de serem recalculados a cada acesso, o que reduz a carga no MySQL e acelera o wp-admin.

--- ## Próximos passos para acelerar seu WordPress Object cache é uma camada poderosa, mas só entrega valor quando o gargalo realmente é o banco de dados. Comece confirmando que o servidor tem Redis ou Memcached, ative o plugin com cuidado para não criar um drop-in orfao e valide o hit rate por 48 horas antes de confiar no ganho. Combine object cache com cache de página e OPcache para cobrir as tres frentes de performance, e meça sempre o TTFB antes e depois de cada mudanca. Object cache mal configurado pesa mais do que ausente, entao trate a validacao como parte obrigatoria da tarefa, não como detalhe opcional.