O que é cache de objetos (object cache)? Redis e Memcached no WordPress explicados

Um cache de objetos (object cache, em inglês) guarda na memória os resultados das consultas ao banco de dados, para que o WordPress não tenha que consultar o banco de novo na próxima requisição. Parece pouca coisa. Em lojas virtuais, áreas de membros e qualquer site com muitos usuários logados, porém, muitas vezes é o que faz a maior diferença no tempo de carregamento. O WordPress até traz um cache de objetos próprio, só que ele esquece tudo depois de cada carregamento de página. Só com Redis ou Memcached por trás é que ele vira um cache de objetos persistente, que mantém os dados ao longo de muitas requisições. Neste artigo, você vai ver como isso funciona em detalhes, no que Redis e Memcached se diferenciam, quando o esforço compensa e quais erros evitar na configuração.

O que é cache de objetos no WordPress?

Toda vez que alguém abre uma página do seu site, o WordPress monta essa página a partir de um monte de peças. Ele carrega as configurações do site, os menus, os widgets, o próprio post, os dados do autor, categorias, tags e tudo o que os seus plugins precisam a mais. Quase tudo isso fica no banco de dados (MySQL ou MariaDB). Uma página comum soma facilmente de 50 a 150 consultas ao banco de dados, e com WooCommerce e alguns plugins maiores, bem mais do que isso. Muitas delas perguntam exatamente a mesma coisa a cada requisição: Como o site se chama? Quais plugins estão ativos? Como é o menu principal?

Um cache de objetos guarda as respostas para perguntas assim. O WordPress olha primeiro no cache, e só quando não encontra nada ali a consulta vai para o banco de dados. O resultado então fica salvo no cache e, na próxima vez, está pronto na hora. O nome vem do fato de que o WordPress não guarda ali páginas prontas, e sim objetos de dados individuais: um post, uma lista de opções, os metadados de um usuário.

Pense num bilhete colado ao lado do teclado. Em vez de revirar o armário de documentos toda vez, você olha o bilhete primeiro. Para uma pergunta só, isso quase não economiza tempo. Quando a mesma pergunta aparece mil vezes por dia, economiza muito.

Como funciona o cache de objetos do WordPress?

Há muitos anos o WordPress tem uma classe própria para o cache de objetos, a WP_Object_Cache. O núcleo do WordPress e muitos plugins conversam com ela por meio de funções como wp_cache_get() e wp_cache_set(). O problema: sem software adicional, esse cache só dura um único carregamento de página. Assim que a página é entregue, a memória fica vazia de novo, e o próximo visitante começa do zero.

Nem por isso esse cache temporário é inútil, porque ele evita consultas duplicadas dentro de uma mesma requisição. A coisa só fica interessante de verdade com um cache de objetos persistente. Para isso, existe um arquivo chamado object-cache.php na pasta wp-content. O WordPress o reconhece automaticamente ao iniciar e passa a usar um serviço externo como Redis ou Memcached no lugar do próprio armazenamento temporário. Os dados ficam lá ao longo de muitos carregamentos de página, até expirarem, mudarem ou a memória encher. Você não precisa escrever esse arquivo. Plugins como o Redis Object Cache já trazem o arquivo e o colocam no lugar certo na ativação.

Um efeito colateral que pouca gente conhece envolve os chamados transients. São valores em cache com data de validade, que os plugins adoram usar, por exemplo para guardar respostas de APIs externas. Sem cache de objetos persistente, os transients vão parar na tabela wp_options e, com o tempo, deixam a tabela inchada. Com Redis ou Memcached, eles passam para a memória, e o banco de dados fica mais enxuto.

Cache de objetos, cache de página e OPcache: qual é a diferença?

Quando o assunto é WordPress e cache, logo aparecem três termos que muita gente confunde. Eles atuam em níveis diferentes e se complementam, em vez de um substituir o outro.

• Cache de página: salva a página inteira, já pronta, como HTML e a entrega sem nem iniciar o WordPress. É assim que funcionam, por exemplo, o WP Rocket, o LiteSpeed Cache e o WP Super Cache. Nada é mais rápido, mas só enquanto todos os visitantes veem a mesma página.
• Cache de objetos: salva resultados individuais do banco de dados. O WordPress continua rodando a cada requisição, mas precisa consultar o banco de dados com muito menos frequência.
• OPcache: não tem nada a ver com os seus dados. Ele garante que o PHP não precise ler e compilar os arquivos do WordPress de novo a cada requisição. Em quase todo plano de hospedagem, ele já vem ativo hoje em dia.

O ponto mais importante: um cache de página só ajuda em páginas que são iguais para todo mundo. Assim que alguém está logado, coloca algo no carrinho ou trabalha no backend, a requisição passa direto por ele. É exatamente aí que entra o cache de objetos. Para um blog com leitores quase sempre anônimos, um bom cache de página rende mais. Já em uma loja, uma plataforma de cursos ou um fórum, o cache de objetos costuma trazer o ganho maior.

Redis vs. Memcached: qual cache de objetos usar no WordPress?

Os dois sistemas mantêm os dados na memória e os armazenam como pares simples de chave e valor. Como cache de objetos, ambos são rápidos o suficiente. As diferenças estão nos detalhes.

Redis é a escolha mais comum para WordPress hoje. Ele armazena mais do que só chaves e valores, por exemplo listas, hashes e sets, e, se você quiser, grava o conteúdo em disco para que o cache sobreviva a uma reinicialização. Além disso, oferece replicação, um controle de acesso mais refinado e um grande ecossistema. Para WordPress existe ainda o Redis Object Cache, um plugin muito usado e bem mantido. Depois de uma mudança de licença do Redis em 2024, surgiu também o Valkey, um fork livre abrigado pela Linux Foundation e que muitas hospedagens já usam. No WordPress, ele se comporta exatamente como o Redis, e em geral você nem percebe a diferença.

Memcached é mais antigo e propositalmente simples. Ele só conhece chaves e valores, não armazena nada de forma permanente e perde todo o conteúdo a cada reinicialização. Em compensação, usa vários núcleos de processador ao mesmo tempo e é muito fácil de distribuir entre vários servidores. Um limite que às vezes aparece no WordPress: por padrão, uma única entrada pode ter no máximo 1 MB. Com opções muito grandes, como as configurações infladas de alguns page builders, isso pode dar problema.

Nossa recomendação: se a sua hospedagem oferece os dois, fique com o Redis. Se só o Memcached estiver disponível, não precisa se preocupar, como cache de objetos ele dá conta tranquilamente. Muito mais importante do que escolher entre os dois é ter um cache de objetos persistente rodando e configurado com bom senso. Aliás, existe um terceiro candidato: o APCu, um cache embutido no próprio PHP. Ele dispensa um serviço separado, mas só funciona em um único servidor e tem um papel menor na prática.

Quando vale a pena usar um cache de objetos persistente?

Um cache de objetos não faz milagre. O quanto ele ajuda depende de quantas requisições escapam do cache de página e chegam direto ao WordPress, e de quanto trabalho o banco de dados tem com elas. O efeito é especialmente perceptível em:

• Lojas WooCommerce, porque carrinho, checkout e conta do cliente nunca saem do cache de página.
• Áreas de membros, plataformas de cursos e fóruns com muitos usuários logados.
• Equipes editoriais em que várias pessoas trabalham no backend ao mesmo tempo.
• Sites com muitos plugins que guardam seus dados em opções e transients.
• Sites grandes com milhares de posts, termos ou usuários.

O próprio WordPress dá uma dica. Desde a versão 6.1, a tela Saúde do site, em Ferramentas, recomenda um cache de objetos persistente quando o seu site passa de certos tamanhos, por exemplo mais de 1.000 posts, comentários ou usuários.

Por outro lado, um cache de objetos ajuda pouco em um site institucional pequeno, de dez páginas, com visitantes quase sempre anônimos e que já usa um bom cache de página. Ali, o cache de página já responde a quase todas as requisições antes mesmo de o WordPress iniciar.

Como configurar o cache de objetos com Redis no WordPress?

O caminho exato depende da sua hospedagem. Muitas hospedagens gerenciadas já têm o Redis disponível e permitem ligar o recurso com um botão no painel de controle, e algumas até deixam tudo configurado para você. Na dúvida, mande uma pergunta rápida ao suporte antes de instalar qualquer coisa por conta própria. Em um servidor próprio, o processo costuma ser assim:

1. Instale e inicie o Redis, no Debian ou Ubuntu, por exemplo, com o pacote redis-server.
2. Instale a extensão phpredis para PHP (pacote php-redis) para que o PHP consiga se comunicar com o Redis. O plugin também traz o Predis, uma variante que dispensa qualquer extensão, só que ela é bem mais lenta.
3. Adicione os dados de conexão ao wp-config.php, acima da linha que marca o fim da edição.
4. Instale o plugin Redis Object Cache e ative o cache de objetos nas configurações dele. Isso cria o arquivo object-cache.php.

define( 'WP_REDIS_HOST', '127.0.0.1' );
define( 'WP_REDIS_PORT', 6379 );
define( 'WP_REDIS_DATABASE', 0 );
define( 'WP_REDIS_PREFIX', 'mysite_' );
define( 'WP_REDIS_MAXTTL', 86400 );

Sempre defina o prefixo quando vários sites compartilharem a mesma instância do Redis. Sem ele, duas instalações podem sobrescrever os dados uma da outra, e isso gera erros bem estranhos. Se você prefere a linha de comando, o último passo se resolve com wp plugin install redis-cache --activate seguido de wp redis enable. Para lojas grandes, existe ainda a solução paga Object Cache Pro.

Quais são os erros mais comuns com cache de objetos?

Um cache de objetos se configura rápido, mas algumas armadilhas aparecem sempre.

• Sem limite de memória: sem maxmemory, o Redis cresce até o servidor ficar sem memória. Com limite, mas com a política padrão noeviction, o Redis recusa novas entradas quando a memória enche, e o WordPress de repente começa a dar erro. Para um cache, a escolha certa é allkeys-lru: aí o Redis simplesmente descarta as entradas que estão há mais tempo sem uso.
• Redis aberto para a internet: o Redis só deve ficar acessível em 127.0.0.1 ou em uma rede privada, e precisa ter senha. Instâncias abertas na porta 6379 são procuradas ativamente e exploradas por atacantes.
• Dados desatualizados após alterações diretas: quem altera dados direto no banco de dados, por exemplo pelo phpMyAdmin ou durante uma importação, passa por fora do cache. O WordPress continua mostrando os valores antigos. Depois disso, limpe o cache, nas configurações do plugin ou com wp cache flush.
• object-cache.php esquecido após uma migração: se você muda para um servidor sem Redis, às vezes o arquivo fica para trás na pasta wp-content. No caso mais leve, aparece só um aviso no painel administrativo. No pior caso, o WordPress para com um erro fatal. Aí basta excluir o arquivo via FTP.
• Redis em um servidor remoto: cada acesso ao cache passa a custar uma viagem pela rede. Com centenas de acessos por carregamento de página, a latência come parte da vantagem. O ideal é o Redis ficar no mesmo servidor ou, pelo menos, no mesmo data center.

maxmemory 256mb
maxmemory-policy allkeys-lru

Essas duas linhas no redis.conf bastam para a maioria dos sites. Quanta memória você precisa depende do tamanho do site. Para uma loja típica, 256 MB é um bom ponto de partida.

Como saber se o cache de objetos está funcionando?

Dá para conferir de várias formas se o cache está mesmo fazendo o trabalho dele:

• No plugin: o Redis Object Cache mostra nas configurações se existe conexão e traz uma pequena estatística de acertos e falhas.
• Na linha de comando: wp cache type informa qual cache de objetos está ativo. Se aparecer Default, nenhum cache persistente está rodando.
• Com o Query Monitor: o plugin gratuito mostra, a cada carregamento de página, a taxa de acerto do cache de objetos e o número de consultas ao banco de dados. Compare os valores com e sem o cache uma vez. A diferença costuma ser maior do que você imagina.
• Direto no Redis: redis-cli info stats retorna, entre outras coisas, keyspace_hits e keyspace_misses. Se a taxa de acerto continuar baixa mesmo depois de algumas horas de uso, geralmente há algo errado na configuração, por exemplo um limite de memória pequeno demais.

Como o InspectWP ajuda a avaliar o cache do seu site

O cache de objetos trabalha no servidor e não fica visível de fora. O efeito dele, sim. O relatório do InspectWP mede, entre outras coisas, o Time to First Byte, ou seja, quanto tempo o servidor leva até o primeiro byte da página chegar. O InspectWP marca valores acima de 800 milissegundos como aviso, e é exatamente aí que um cache de objetos ajuda quando a página não vem do cache de página. O InspectWP também detecta quais plugins são usados para cache, incluindo o Redis Object Cache, pelo breve comentário que o plugin deixa por padrão no HTML da página. Junto com os dados sobre provedor de hospedagem, servidor e versão do PHP, você logo percebe se ainda dá para tirar mais desempenho do cache de um site.