| Cenário do site | Comportamento do cache | Decisão recomendada |
|---|---|---|
| WooCommerce com checkout dinâmico | Reduz queries repetidas de produto e carrinho | Instale o cache de objeto |
| Blog estático com cache de página | Ganho marginal, o HTML já vem do cache | Não prioritário |
| Hospedagem compartilhada sem daemon | Sem acesso ao processo redis-server | Use transients ou migre o host |
| VPS com menos de 1GB de RAM | Risco de OOM kill com a política noeviction | Limite maxmemory antes de ativar |
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.Porque o cache de objeto Redis no WordPress só ajuda quando o gargalo é o banco de dados. Ele guarda o resultado das queries do MySQL na memória, então sites com muitas consultas dinâmicas, como WooCommerce, ganham bastante. Um blog estático já servido por cache de página quase não muda, porque o HTML nem chega a chamar o PHP. O ganho real depende de onde está a lentidão, medida antes pelo TTFB.
Sim, o cache de objeto Redis no WordPress funciona sem root desde que a hospedagem já ofereça o daemon redis-server ativo e a extensão phpredis no PHP 8.2. Em planos gerenciados, você ativa o object cache só pelo plugin, sem tocar no terminal. O que não dá para fazer sem acesso é instalar o próprio daemon: em hospedagem compartilhada pura, sem redis-server, o plugin cai para transients no banco e o ganho de velocidade some.
O Redis 7.x oferece persistência AOF e estruturas de dados ricas, então o cache sobrevive a um reboot do servidor. O Memcached é um key-value puro, mais simples, porém perde todo o cache ao reiniciar e não guarda tipos complexos. Para WordPress, o ecossistema de plugins do Redis é mais maduro, o que costuma fazer dele a escolha padrão em sites dinâmicos de produção.
O cache de objeto Redis no WordPress consome entre 30 MB e 150 MB na maioria dos sites, dependendo do volume de objetos cacheados e do catálogo. Lojas WooCommerce grandes podem passar disso. A regra prática é fixar maxmemory em 256 MB com política allkeys-lru: assim o serviço descarta o que é menos usado em vez de travar gravações. Deixar sem limite numa VPS pequena é o que causa o OOM kill.
O cache de objeto Redis no WordPress acelera as páginas dinâmicas que o cache de página ignora de propósito, como carrinho, checkout, busca e áreas logadas. O cache de página serve um HTML pronto para visitantes anônimos e nem executa o PHP. O object cache entra quando o PHP precisa rodar, guardando o resultado das queries para não repetir a consulta ao MySQL. Por isso os dois trabalham juntos, em camadas diferentes do mesmo site.