--- title: "Redis object cache no WordPress: configuração e testes" id: "597" type: "post" slug: "redis-object-cache-wordpress" published_at: "2026-10-06T20:00:50+00:00" modified_at: "2026-10-06T20:22:47+00:00" url: "https://danielpazwp.com/pt/redis-object-cache-wordpress/" markdown_url: "https://danielpazwp.com/pt/redis-object-cache-wordpress.md" excerpt: "O que o Redis object cache faz no WordPress, quando ele ajuda, como configurar o wp-config e o redis.conf e como conferir se está funcionando." taxonomy_category: - "Performance" --- [Performance](https://danielpazwp.com/pt/category/performance-pt/) 9 min de leitura # Redis object cache no WordPress: configuração e testes O que o Redis object cache faz no WordPress, quando ele ajuda, como configurar o wp-config e o redis.conf e como conferir se está funcionando. Publicado **06/10/2026**9 min de leitura [Escrito porDaniel Paz](https://danielpazwp.com/pt/author/daniel-paz/) O Redis object cache no WordPress guarda na memória o resultado de consultas ao banco e de buscas caras entre uma requisição e outra, para o WordPress não refazer tudo a cada carregamento de página. Por padrão, o WordPress só mantém esse cache durante uma única requisição. Com o Redis e um drop-in `object-cache.php`, normalmente instalado pelo plugin Redis Object Cache, o cache passa a ser persistente. O ganho aparece onde o cache de página não chega: usuários logados, wp-admin, carrinho e checkout do WooCommerce, REST API e admin-ajax. Para visitante anônimo que já recebe HTML em cache, a diferença é pequena. Nas auditorias, vejo muito Redis tratado como botão de velocidade: instala, ativa e pronto. Às vezes ajuda bastante. Outras vezes a taxa de acerto é baixa, o Redis está cheio e recusando gravações, ou dois sites usam o mesmo banco e um apaga as chaves do outro. Este artigo explica o que o object cache faz de verdade, como configurar direito e como conferir se está funcionando. Ele faz parte do meu guia sobre [como acelerar o WordPress](https://danielpazwp.com/pt/como-acelerar-wordpress/) . ## O que o object cache do WordPress faz? O core do WordPress tem uma API de object cache: `wp_cache_get()`, `wp_cache_set()`, `wp_cache_delete()` e companhia. O core usa essa API para posts, post meta, termos, usuários, opções e resultados de consultas. Plugins bem escritos também usam. A implementação padrão, `WP_Object_Cache`, guarda tudo num array PHP que some quando a requisição termina. Dentro de um carregamento de página, pedir o mesmo post duas vezes não custa nada. No carregamento seguinte, o WordPress começa do zero. Quando existe um arquivo `object-cache.php` em `wp-content`, o WordPress carrega esse arquivo no lugar da implementação padrão. O drop-in manda as mesmas chamadas da API para o Redis ou o Memcached, e os dados sobrevivem entre requisições e entre workers do PHP. Os transients também mudam: com object cache persistente, `set_transient()` grava no cache e não na tabela `wp_options`, o que alivia o banco. Object cache e cache de página resolvem problemas diferentes, e a confusão entre os dois é constante. Escrevi um texto separado sobre [cache de página, object cache e edge cache, e qual deles você precisa](https://danielpazwp.com/pt/page-cache-object-cache-edge-cache-qual-voce-precisa/) . O resumo: | Tipo de requisição | Sai do cache de página? | O Redis ajuda? | | --- | --- | --- | | Visitante anônimo em página com cache | Sim | Quase nada, o PHP nem roda | | Visitante anônimo com cache miss | Não | Sim, menos consultas enquanto a página é montada | | Usuário logado, wp-admin | Não | Sim | | Carrinho, checkout e minha conta no WooCommerce | Não | Sim | | REST API, admin-ajax, cron | Normalmente não | Sim | ## Quando vale a pena usar Redis object cache? A Saúde do Site sugere um object cache persistente quando o site tem porte para se beneficiar, olhando por exemplo o número de posts, usuários ou opções. É um bom indicativo. Minha regra é mais simples: se uma parte relevante do tráfego não pode sair do cache de página, vale ter. Isso inclui lojas, sites de membros, plataformas de curso, fóruns, intranets e qualquer site em que a equipe passa horas no wp-admin. Um site institucional de cinco páginas com cache de página completo mal vai perceber. O Redis também não corrige um plugin que roda uma consulta lenta sem cache em toda requisição, nem um bloco de 3 MB de opções com autoload. Ele guarda o que o WordPress pede para guardar. Se o código passa por fora da API de cache, o Redis nem fica sabendo. Para o problema do autoload, veja [autoload do wp_options e otimização do banco de dados](https://danielpazwp.com/pt/otimizacao-banco-de-dados-wordpress/) . ## Como configurar o Redis object cache no WordPress? Em hospedagem gerenciada, olhe o painel primeiro. Muitas hospedagens oferecem Redis com um clique e já colocam o drop-in, então instalar outro só vai gerar conflito. Em servidor próprio, o caminho é este: 1. Instale o servidor Redis e um cliente PHP. A extensão PhpRedis é compilada em C e é a que uso quando controlo o servidor. O Predis é uma biblioteca em PHP puro e funciona sem extensão. 2. Confirme que o Redis responde com `redis-cli ping`. A resposta deve ser `PONG`. 3. Coloque as constantes de conexão no `wp-config.php`, acima da linha que pede para parar de editar. 4. Instale o plugin [Redis Object Cache](https://wordpress.org/plugins/redis-cache/) e ative o drop-in, pela tela do plugin ou pelo WP-CLI. 5. Confira o status e acompanhe a taxa de acerto por um dia antes de dar o trabalho por encerrado. Um bloco típico no `wp-config.php` fica assim. Host, porta e senha dependem do seu servidor, e também dá para usar socket Unix: ``` define( 'WP_REDIS_HOST', '127.0.0.1' ); define( 'WP_REDIS_PORT', 6379 ); // define( 'WP_REDIS_PASSWORD', 'defina-isso-no-servidor' ); define( 'WP_REDIS_DATABASE', 0 ); define( 'WP_REDIS_PREFIX', 'exemplo_com_br:' ); define( 'WP_REDIS_TIMEOUT', 1 ); define( 'WP_REDIS_READ_TIMEOUT', 1 ); ``` Depois, ative e confira: ``` wp plugin install redis-cache --activate wp redis enable wp redis status ``` O prefixo é a configuração que todo mundo pula e depois se arrepende. Se várias instalações de WordPress usam o mesmo Redis e nenhuma define prefixo ou banco separado, as chaves podem colidir. Dê a cada site o seu prefixo. A documentação do plugin lista as outras constantes, incluindo a que escolhe o cliente e as de TLS e cluster. ## Como configurar o próprio Redis? Duas diretivas do `redis.conf` pesam mais quando o Redis é cache: `maxmemory` e `maxmemory-policy`. A política padrão do Redis é `noeviction`: quando a memória enche, as gravações falham. Num object cache de WordPress, em que qualquer chave pode ser reconstruída a partir do banco, o certo é deixar o Redis descartar as chaves antigas. ``` # redis.conf maxmemory 256mb maxmemory-policy allkeys-lru ``` Os 256 MB ali são só um exemplo. O tamanho certo depende de quanto o seu site coloca em cache, e você descobre olhando o uso de memória depois de alguns dias de tráfego normal. Se o `used_memory` fica colado no limite e as remoções não param de subir, o cache está pequeno para o volume de dados. E mantenha o Redis restrito ao localhost ou a uma rede privada. Porta do Redis aberta na internet é incidente de segurança anunciado. ## Como saber se o object cache está funcionando? “Conectado” na tela do plugin só prova que o WordPress alcança o Redis. Não diz nada sobre o cache estar ajudando. Eu confiro três coisas: - Taxa de acerto. O Query Monitor mostra acertos e falhas do object cache em cada requisição. Com o cache aquecido, a maior parte das buscas deve ser acerto. No servidor, `redis-cli info stats` traz `keyspace_hits` e `keyspace_misses` da instância inteira. - Número de consultas. Compare a quantidade de consultas ao banco na mesma página logada, com o drop-in ativo e desativado. A queda tem que ser clara. - Remoções e memória. `redis-cli info memory` e o contador `evicted_keys` do `info stats` mostram se o cache tem tamanho suficiente. ``` redis-cli info stats | grep -E 'keyspace_(hits|misses)|evicted_keys' redis-cli info memory | grep -E 'used_memory_human|maxmemory_human' ``` Depois, meça o que o usuário sente. Nas páginas logadas e no checkout, compare o tempo de resposta do servidor antes e depois, nas mesmas URLs. Minhas notas sobre [como reduzir o TTFB no WordPress](https://danielpazwp.com/pt/ttfb-no-wordpress/) mostram como medir pela linha de comando e em dados de campo. ## O que costuma dar errado com Redis no WordPress? Estes são os problemas que mais encontro, mais ou menos nesta ordem: - Dois drop-ins brigando. Um plugin de cache, a hospedagem e o plugin do Redis querem ser donos do `object-cache.php`. Só pode existir um arquivo. Escolha um e desligue o object cache nos outros. - Redis cheio com `noeviction`. As gravações falham e, dependendo do cliente, aparecem erros ou o cache para de atualizar sem avisar. - Instância compartilhada sem prefixo. Homologação e produção no mesmo Redis, mesmo banco, sem prefixo. Um flush na homologação esvazia o cache da produção. - Plugins que limpam o cache inteiro. Alguns chamam `wp_cache_flush()` a cada salvamento ou a cada execução do cron, e a taxa de acerto nunca sobe. O Query Monitor ou uma busca por `wp_cache_flush` no código dos plugins acha os culpados. - Redis em outro servidor com latência alta. Cada busca vira uma ida e volta pela rede, e centenas delas por requisição somam. Deixe o Redis perto do PHP. - Dados velhos depois de edição direta no banco. Se você altera linhas por SQL, o cache continua com os valores antigos. Rode `wp cache flush` em seguida. ## Redis ou Memcached? Os dois funcionam como backend de object cache no WordPress com um drop-in. Nesse uso, a diferença entre eles pesa menos que a configuração em volta. O Redis tem tipos de dados mais ricos, persistência opcional em disco e boas ferramentas, e a maioria das hospedagens e plugins de WordPress dá suporte a ele, por isso é minha escolha padrão. O Memcached é mais simples e também resolve. Se a sua hospedagem já roda um dos dois bem, use esse. Em qualquer caso, ele precisa estar perto do PHP, ter tamanho adequado aos seus dados e descartar chaves em vez de falhar quando enche. No servidor, o object cache fica ao lado do próprio PHP. Se as páginas logadas continuam lentas mesmo com boa taxa de acerto, o próximo lugar para olhar é a camada do PHP: quantidade de workers e OPcache, assunto do artigo sobre [ajuste de PHP-FPM e OPcache no WordPress](https://danielpazwp.com/pt/php-fpm-opcache-wordpress-pt/) . ## Perguntas frequentes ### O Redis object cache substitui o plugin de cache de página? Não. O cache de página guarda o HTML pronto e pula o PHP inteiro. O object cache guarda pedaços de dados enquanto o PHP monta a página. A maioria dos sites com tráfego dinâmico precisa dos dois. ### Posso limpar o cache do Redis sem medo? Pode, tudo que está ali pode ser reconstruído a partir do banco. Por um tempo curto, as respostas ficam mais lentas enquanto o cache aquece de novo. Em instância compartilhada, garanta que o flush só atinja as chaves ou o banco do seu site. ### O Redis melhora as Core Web Vitals? Só pelo tempo de resposta do servidor, e só nas requisições que não saem do cache de página. Um TTFB menor deixa mais folga dentro dos 2,5 segundos de LCP para o resto da página. Se as suas páginas lentas já estão em cache, o problema está no front-end. Se a sua loja ou área de membros está lenta para quem está logado e você quer descobrir para onde vai o tempo, do object cache às consultas e aos workers do PHP, é isso que eu analiso na [auditoria de performance WordPress](https://danielpazwp.com/pt/auditoria-performance-wordpress/) . [Trabalhe com o Daniel](https://danielpazwp.com/pt/#book) [Mais em Performance](https://danielpazwp.com/pt/category/performance-pt/) [Sobre o autorPágina do autor](https://danielpazwp.com/pt/author/daniel-paz/) ## Artigos relacionados [Todos os artigos](https://danielpazwp.com/pt/artigos/) [Performance out 2026Page cache vs object cache vs edge cache: qual você precisa](https://danielpazwp.com/pt/page-cache-object-cache-edge-cache-qual-voce-precisa/) [Performance out 2026Core Web Vitals: dados de campo vs laboratório](https://danielpazwp.com/pt/core-web-vitals-dados-de-campo-vs-laboratorio/) [Performance out 2026WordPress lento: os motivos estruturais e a ordem para corrigir](https://danielpazwp.com/pt/por-que-seu-wordpress-e-lento-motivos-estruturais/)