O cache de objeto Redis no WordPress guarda o resultado das queries do MySQL na memória e corta a carga do banco. Segundo o web.dev, do Google, o TTFB ideal fica em 0,8 segundo ou menos. O ganho cai quando o gargalo está no frontend. Meça o TTFB antes de instalar.

O cache de objeto Redis no WordPress é uma camada de memória que evita repetir a mesma query ao MySQL a cada carregamento de página. Em sites dinâmicos com WooCommerce, áreas logadas ou muitos plugins, esse cache costuma derrubar o TTFB mais do que qualquer otimização de frontend. A gente vê nos tickets da FULL, na base de 150 mil sites, que a maioria instala o cache antes de medir onde está a lentidão, e o ganho frustra. Este tutorial mostra quando o cache de objeto Redis vale a pena, como instalar em 5 passos e onde ele não resolve. Para o contexto maior de velocidade, veja o hub de conteúdos de performance WordPress.

Diagnóstico rápido: Quando o cache de objeto Redis no WordPress vale a pena

O cache de objeto Redis no WordPress entrega ganho real quando o banco é o gargalo: em sites com mais de 30 queries por página, ele tende a cortar o tempo de geração do HTML em 40% a 70% nos cenários testados. Em site estático já servido por cache de página, o ganho some quase por completo.

Por isso a primeira decisão não é técnica, é de diagnóstico. A tabela abaixo resume o cenário antes de você instalar qualquer coisa.

Antes de tudo, meça o tempo de resposta do servidor no WordPress: se o TTFB já está abaixo de 200 ms, esse cache não é a sua prioridade agora.

O que o cache de objeto resolve que o cache de página não alcança

O cache de objeto e o cache de página atacam camadas diferentes, e confundir os dois é o erro mais comum nos tickets de suporte da FULL. O cache de página serve um HTML pronto e nem chama o PHP; o cache de objeto Redis atua quando o PHP precisa rodar, guardando o resultado de cada query do MySQL na memória e poupando até 30% do tempo de processamento.

Em páginas logadas, de carrinho ou de busca, o cache de página é ignorado de propósito, e aí o plugin de cache do WordPress sozinho não basta. O object cache entra exatamente nesse vão, e a recomendação tende a ser usar os dois juntos: cache de página para o anônimo, memória para o dinâmico.

Pré-requisitos: O que checar antes de instalar o cache de objeto Redis no WordPress

Três condições precisam estar satisfeitas antes de instalar o cache de objeto Redis no WordPress, e pular qualquer uma gera o ticket clássico de “ativei e nada mudou”. O servidor precisa do daemon redis-server respondendo na porta 6379, da extensão phpredis ativa no PHP 8.2 e de um teto de memória definido antes do primeiro acesso.

Sem a extensão phpredis, o plugin cai para um modo lento que anula o ganho. Você também precisa de acesso por WP-CLI ou SSH para validar a conexão. E defina o teto: o object cache de um site WordPress típico ocupa entre 30 MB e 150 MB, e deixar o serviço sem limite é o que causa o travamento em VPS pequena. Confirme ainda que o banco de dados WordPress está saudável; o cache não conserta query mal feita nem tabela inchada de revisões.

Passo a passo: Instalar o cache de objeto Redis no WordPress

Instalar o cache de objeto Redis no WordPress leva 5 passos e cerca de 15 minutos quando o daemon já existe no servidor. A ordem importa: ativar o plugin antes de o serviço responder gera erro de conexão silencioso, sem mensagem visível no painel. Siga os passos abaixo na sequência, validando a cada etapa antes de avançar para a próxima.

Legenda: o status “Connected” confirma que o WordPress está falando com o daemon redis-server.

Passo 1: Confirme o daemon redis-server ativo

Verifique se o serviço responde antes de tocar no WordPress, rodando redis-cli ping via SSH: a resposta esperada é PONG. Em hospedagem gerenciada, o daemon já vem ativo; em VPS, instale o pacote redis-server pelo gerenciador da distribuição. Sem esse PONG, nenhum plugin conecta, por mais que o painel diga o contrário.

Passo 2: Instale a extensão phpredis no PHP

Confirme que o PHP 8.2 enxerga o serviço rodando php -m | grep redis no terminal. Se nada aparecer, instale a extensão phpredis e reinicie o PHP-FPM. Essa extensão é o que faz o object cache operar em modo rápido; sem ela, o plugin usa um fallback que reduz o ganho a quase nada.

Passo 3: Defina maxmemory e a política de despejo

Edite o arquivo Redis.conf e fixe maxmemory 256mb com maxmemory-policy allkeys-lru antes de qualquer tráfego real. Essa política descarta as chaves menos usadas quando a memória enche, em vez de travar gravações. Deixar em noeviction numa VPS pequena é a causa raiz do OOM kill que derruba o site com erro 500.

Passo 4: Ative o plugin Redis object cache

Instale e ative o plugin Redis Object Cache pelo painel, depois clique em “Enable Object Cache”. O plugin grava o arquivo object-cache.php em wp-content e o status deve virar “Connected”. Se ficar “Not connected”, o host está usando porta ou socket diferente do padrão 6379.

Passo 5: Valide o hit rate via WP-CLI

Rode wp redis status pelo WP-CLI e confira o hit ratio depois de uns minutos de navegação. Um object cache saudável passa de 90% de acerto; abaixo de 70% indica que muitos objetos estão sendo despejados e o maxmemory está apertado demais para o catálogo do site.

Redis, Memcached e cache de página: Quem faz o quê

O Redis e o Memcached competem na mesma camada de object cache, mas com filosofias distintas, e escolher errado custa retrabalho. O Redis 7.x tem persistência AOF e estruturas de dados ricas; o Memcached é um key-value puro e sem persistência, que perde 100% do cache ao reiniciar e força um reaquecimento do zero.

A persistência do Redis mantém o cache de objeto Redis no WordPress aquecido após um reboot, enquanto o Memcached gera um pico de queries ao MySQL nesse meio-tempo. Para WordPress, o ecossistema de plugins maduro pesa a favor do Redis. Já o cache de página nem disputa essa camada: ele serve HTML antes do PHP rodar. Na prática do suporte, a maioria dos sites dinâmicos ganha mais com object cache do que trocando de plugin de frontend. Para o quadro completo de métricas, confira o guia de Core Web Vitals no WordPress.

Por que o ganho do cache de objeto varia tanto entre sites

Dois sites com o mesmo plugin Redis colhem ganhos bem diferentes, e o motivo está em detalhes de configuração que poucos tutoriais conectam. O hit ratio é o primeiro: abaixo de 70% de acerto, o cache despeja objetos antes de reusá-los e o banco volta a ser chamado. A persistência da conexão phpredis é o segundo, porque abrir socket a cada requisição come o tempo que você economizou.

Na prática do suporte da FULL, a gente vê três fatores que mudam o resultado: o catálogo do site, que define quanta memória os objetos ocupam; a política maxmemory, que decide o que sobrevive quando a RAM enche; e a saúde do banco, já que o Redis cacheia até query lenta e mascara o sintoma. Ajustar esses três antes de medir o TTFB de novo separa o ganho real do stack de performance e cache do WordPress da impressão de que “instalei e nada mudou”.

Quando o cache de objeto Redis não resolve e pode atrapalhar

O cache de objeto Redis no WordPress não é remédio universal, e em três cenários ele atrapalha mais do que ajuda: hospedagem compartilhada sem daemon, gargalo no frontend e banco de dados sujo. Nesses casos, instalar o Redis adiciona uma camada que mascara o problema real em vez de resolvê-lo.

Em hospedagem compartilhada sem redis-server, o plugin cai para transients no banco e você ganha complexidade sem ganho de velocidade. Quando o gargalo é o frontend, imagens pesadas e JavaScript que bloqueia a renderização não melhoram com o cache de objeto Redis no WordPress, por mais memória que você reserve. E quando o banco está sujo, vale primeiro otimizar o banco de dados WordPress, porque o Redis cacheia até query lenta e esconde o sintoma. Nos sites de e-commerce, o clássico é o WooCommerce lento ser de hospedagem, não de cache.

Quanto custa rodar o cache de objeto Redis com suporte gerenciado

Configurar o cache de objeto Redis no WordPress manualmente em cada site consome tempo de servidor e gera ticket recorrente quando algo quebra. No bundle da FULL, o plano PRO sai por R$849 e inclui até 10 sites com cache e otimização premium gerenciados, o que dá R$85 por site, em qualquer hospedagem.

Em vez de manter o daemon, ajustar maxmemory e monitorar o hit rate em cada cliente, a otimização vem pronta e suportada, sem você editar o arquivo de configuração na mão. Conheça os planos da FULL para comparar o custo por site com o tempo gasto em configuração avulsa.

Decisão rápida: Instalar ou não o cache de objeto Redis

A escolha de instalar o cache de objeto Redis no WordPress depende de onde está o gargalo e do tipo de hospedagem que você controla. Use a árvore abaixo para decidir em segundos, sem chutar e sem instalar mais um plugin por impulso.

• Se o TTFB já está abaixo de 200 ms com cache de página → não instale o object cache agora, ataque o frontend.
• Se o site tem WooCommerce ou muitas páginas logadas → instale o cache de objeto com Redis.
• Se você está em hospedagem compartilhada sem daemon → evite essa rota, use transients ou migre o host.
• Se a VPS tem menos de 1GB de RAM → fixe maxmemory e allkeys-lru antes de ativar.

Próximos passos para acelerar o WordPress com cache de objeto

Rodar o cache de objeto Redis no WordPress bem feito começa pela medição e termina no monitoramento do hit rate, nunca no impulso de instalar mais um plugin. Confirme o gargalo, ajuste maxmemory conforme o catálogo do site e só então ative o object cache, validando a conexão por WP-CLI. Se o ganho não aparecer, o problema provavelmente está no frontend ou na hospedagem, não no cache. Para continuar aprendendo, o guia para acelerar o WordPress da FULL reúne os tutoriais de performance em sequência, e o FULL Academy organiza todo o material em um só lugar.

Perguntas frequentes sobre cache de objeto Redis no WordPress