Transient WordPress

Transient WordPress é um sistema de cache temporário embutido no core que permite armazenar qualquer tipo de dado com tempo de expiração definido pelo desenvolvedor. É ideal para guardar resultados de queries pesadas, respostas de APIs externas, contagens caras e qualquer dado que não precisa ser recalculado a cada requisição. Diferente do cache de página, que armazena HTML pronto, o transient guarda valores arbitrários acessíveis em qualquer ponto do código.

O que é a Transient API

A Transient API é a interface oficial do WordPress para cache de dados temporários. Foi introduzida na versão 2.8 e desde então é parte do toolkit padrão de quem desenvolve plugins ou temas que precisam economizar processamento.

A ideia central é simples. Você dá um nome para o dado, um valor e um tempo de expiração. O WordPress guarda. Em qualquer requisição posterior, dentro do prazo, você pede o dado pelo nome e recebe instantaneamente, sem reprocessar o que gerou aquele valor. Quando o prazo expira, o transient deixa de existir e a próxima chamada precisa regenerar.

Quem busca o que é transient costuma estar tentando otimizar plugin próprio, ou descobrindo essa API ao auditar código de outros. As funções principais são três: set_transient para gravar, get_transient para ler, delete_transient para apagar. A interface é deliberadamente simples.

O conceito se assemelha a transients da computação geral: dados que existem por curto período e são descartáveis. No WordPress, esse curto período costuma ser minutos ou horas, raramente dias. Para dados que precisam viver mais, outros mecanismos são mais apropriados.

Como funcionam transients

Por padrão, transients são armazenados na tabela wp_options junto com as outras opções do site. Cada transient gera duas linhas: uma com o valor (option_name começando com _transient_) e outra com o timestamp de expiração (_transient_timeout_).

Quando você chama get_transient, o WordPress consulta primeiro o timestamp. Se já passou, deleta as duas linhas e retorna false, sinalizando que o cache expirou. Se ainda está válido, retorna o valor armazenado. Tudo no nível do banco, sem necessidade de infra externa.

Esse modelo tem uma limitação importante: a wp_options não foi desenhada para alta rotatividade de dados. Sites que geram dezenas de transients por minuto podem inchar a tabela rapidamente, e transients expirados não são limpos automaticamente. Acumulam até alguém apagar manualmente ou rodar um job de limpeza.

Quando o site tem object cache externo configurado (Redis ou Memcached), o WordPress armazena transients em memória, não no banco. Operações ficam mais rápidas e não inflam a tabela wp_options. É a configuração ideal para sites com volume relevante.

Quando usar transients

O caso mais clássico é cachear respostas de APIs externas. Plugin que busca cotação de moeda, tempo, posts de redes sociais. Cada chamada a uma API costuma demorar 200 a 2000 ms, e a maioria dessas APIs tem rate limit. Transient com expiração de 15 a 60 minutos elimina chamadas redundantes e protege o site contra falha de upstream.

O segundo caso é resultado de queries SQL pesadas. Plugin que mostra os 10 produtos mais vendidos do mês, contagem de comentários por categoria, ranking de autores. Calcular cada vez é caro. Calcular uma vez por hora e cachear via transient é instantâneo nos próximos 3600 segundos.

O terceiro caso é dados de configuração que não mudam toda hora mas são consultados muito. Lista de países pegada de banco de dados externo, listagem de horários de atendimento, indicadores de feature flag. Em vez de ler do banco a cada requisição, lê uma vez, guarda transient com 6 ou 12 horas, e usa.

O exemplo de código é direto: set_transient(‘produtos_top’, $resultado, HOUR_IN_SECONDS) grava por uma hora. get_transient(‘produtos_top’) lê. Se retornar false, recalcula e regrava. Combine com WP-CLI para limpeza programada de transients expirados em produção.

Transients vs Object Cache

Os dois conceitos se sobrepõem mas operam em escopos diferentes. Transient API é a interface oficial: você usa as funções set_transient, get_transient, delete_transient e o WordPress decide onde armazenar. Object cache é a infra de armazenamento: Redis, Memcached, ou cache em memória da própria requisição.

Sem object cache externo configurado, os transients caem no banco. Cada operação é um INSERT, UPDATE ou SELECT no MySQL, com custo de I/O e travamento. Em sites de baixo tráfego, isso é invisível. Em sites grandes, vira gargalo.

Com Object Cache ativo, transients passam a viver em memória. Cada operação é resolvida em microssegundos. Não há crescimento da wp_options, não há manutenção necessária, não há risco de transients expirados ficarem acumulando. É a configuração que sites profissionais sempre rodam.

Em código, você não precisa mudar nada. As funções da Transient API continuam funcionando igual. O WordPress detecta automaticamente que existe um drop-in de object cache e roteia para lá. É uma das coisas bem desenhadas do core: a API pública é estável e a implementação por trás pode trocar sem quebrar nada. Combine com cache de página adequado para fechar o ciclo de performance.

Para times que rodam plugins customizados ou sites WooCommerce com transients pesados e precisam evitar inchaço da wp_options, a FULL Services entrega o WP Optimize já licenciado e configurado dentro da stack profissional, junto com Redis disponível na hospedagem parceira para que transients vivam em memória desde o primeiro deploy. Em vez de configurar object cache plugin a plugin, o site roda em uma camada validada em produção.