O object cache persistente guarda resultados de consultas ao banco na memória 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 memória 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 conteúdos de performance WordPress da FULL.

Primeiros passos: O que o object cache resolve

O object cache resolve um gargalo específico 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 memória 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.

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 já 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 documentação oficial em developer.WordPress.org, que define a API WP_Object_Cache, o cache nativo é não persistente por padrão: 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 opções dominantes nesse cenario são 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 padrão em hospedagem gerenciada moderna. O Memcached é mais simples: chave-valor puro na memória, 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 já tenha Redis ou Memcached instalado. Antes de comecar, confirme com seu host: tentar ativar o drop-in sem o serviço 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 número 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 número 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 já 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ê já tem com a camada de otimização gerenciada, sem trocar de provedor. Para comparar as opções, 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 serviço Redis rodando no servidor, o que gera um fatal error e derruba o wp-admin inteiro em poucos segundos sem mensagem clara.

A correção é 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 conteúdo de um site dentro de outro. Esses três 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 três gargalos diferentes do WordPress e não se substituem entre si, e por isso o ganho máximo de performance vem de empilhar as três 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 memória 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

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 três 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 validação como parte obrigatoria da tarefa, não como detalhe opcional.