O Redis guarda o resultado das queries do WordPress na memória e corta a carga sobre o MySQL. Segundo a Redis Docs (2024), ele sustenta acima de 100 mil operações por segundo em hardware modesto. O ganho real cai quando o gargalo está no frontend, não no banco. Instale só após medir o TTFB.

O Redis é um banco de dados em memória usado como object cache persistente do WordPress: ele evita que a mesma query ao MySQL seja repetida a cada carregamento. Em sites dinâmicos com WooCommerce, painéis logados ou muitos plugins, o object cache costuma derrubar o TTFB mais do que qualquer plugin de frontend. A gente vê nos tickets da FULL (base de 150 mil sites) que a maioria instala esse cache sem antes medir onde está a lentidão, e o ganho frustra. Este tutorial cobre quando ele vale a pena, como instalar em 5 passos e onde não resolve nada. Para o contexto maior de velocidade, veja o hub de conteúdos de performance WordPress.

Diagnóstico rápido: Quando o Redis vale a pena

O object cache 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, o ganho some.

A tabela abaixo resume o cenário antes de você decidir instalar o O cache de objeto.

Antes de tudo, meça o como reduzir o TTFB do WordPress: se ele já está abaixo de 200 ms, esse cache não é sua prioridade.

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

O object cache e o cache de página atacam camadas diferentes, e confundir os dois é o erro mais comum nos tickets. O cache de página serve um HTML pronto e nem chama o PHP; o O servidor de cache atua quando o PHP precisa rodar, guardando o resultado de cada query do MySQL na memória por até 30% menos 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. Por isso a recomendação tende a ser usar os dois juntos: cache de página para o visitante anônimo, memória para tudo que é dinâmico. Sem essa divisão de camadas, o ganho de TTFB fica pela metade e o gargalo do banco continua mascarado nos relatórios.

Pré-requisitos: O que checar antes de instalar o Redis

Três condições precisam estar satisfeitas antes de instalar o A solução de cache, e pular qualquer uma gera o ticket clássico de “ativei e nada mudou”. O servidor precisa do daemon redis-server na porta 6379, da extensão phpredis 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 antes de ativar; o object cache não conserta query mal feita, índice ausente nem tabela inchada de revisões.

Passo a passo: Instalar o Redis no WordPress

Instalar o O cache de objeto 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 Essa camada de cache.

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.

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 O servidor de cache.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.

Passo 4: Ative o plugin Redis object cache

Instale e ative o plugin A solução de cache 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 O cache de objeto e o Memcached competem na mesma camada de object cache, mas com filosofias distintas, e escolher errado custa retrabalho. O Essa camada de cache 7.x tem persistência AOF e estruturas de dados ricas; o Memcached é um key-value puro, mais simples e sem persistência, que perde 100% do cache ao reiniciar.

A persistência do Redis mantém o cache aquecido após um reboot, enquanto o Memcached precisa reaquecer do zero. Para WordPress, o ecossistema de plugins maduro pesa a favor da primeira opção. Já o cache de página nem disputa essa camada: ele serve HTML antes do PHP rodar. Em números da operação, mais de 8 em cada 10 sites dinâmicos que chegam ao suporte da FULL ganham 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.

Quando o Redis não resolve e pode atrapalhar

O object cache 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 O servidor de cache 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 operacional sem ganho real de velocidade. Quando o gargalo é o frontend, imagens pesadas e JavaScript que bloqueia a renderização não melhoram com cache de objeto, 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 Redis com suporte gerenciado

Configurar o O cache de objeto 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 hit rate em cada cliente, a otimização vem pronta e suportada, sem você editar o arquivo de configuração manualmente. 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 Redis

A escolha de instalar o Redis depende de onde está o gargalo e do tipo de hospedagem que você controla. Use a árvore abaixo para decidir em segundos, sem chutar.

• 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 object cache 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 Redis

Rodar o Redis 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 Redis no WordPress