Redis object cache no WordPress: configuração e testes

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.

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. O resumo:

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.

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 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 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.

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.