Transient API

Transient API WordPress é o sistema nativo de cache temporário com tempo de expiração definido, ideal para acelerar consultas pesadas ao banco e chamadas a APIs externas. Em vez de calcular o resultado a cada requisição, você armazena uma vez via set_transient(), recupera com get_transient() nas próximas, e o WordPress descarta automaticamente quando o tempo de vida expira. É a forma mais simples de aplicar cache pontual em código WordPress sem dependência externa.

O que é a Transient API

Transient API é um conjunto de funções nativas do WordPress, disponível desde a versão 2.8 (2009), criada para resolver um padrão recorrente: “preciso guardar este dado por um tempo curto e descartar depois”. Em vez de cada plugin inventar seu próprio cache, o WordPress padronizou o mecanismo em uma API estável que qualquer desenvolvedor pode usar.

A pergunta sobre o que é transient resume-se a isto: é um par chave-valor com tempo de vida (TTL). Você nomeia uma chave (“resultado_api_cep”), salva um valor (a resposta JSON), define um TTL (12 horas) e o WordPress se encarrega do resto. Antes do TTL, get_transient retorna o valor salvo; depois do TTL, retorna false e você sabe que precisa recalcular.

Internamente, transients são armazenados na tabela wp_options por padrão, com nomes prefixados _transient_ (valor) e _transient_timeout_ (timestamp de expiração). Quando um sistema de cache de objeto está ativo (Redis, Memcached), os transients passam a viver na memória, ganhando velocidade de leitura e parando de poluir o banco.

O ganho de performance é direto. Uma consulta complexa que demora 800 ms para rodar pode ser cacheada em transient. As próximas chamadas, em vez de levar 800 ms, levam 5 ms. Multiplicado por milhares de requisições por hora, vira diferença real de servidor saudável vs servidor sobrecarregado.

Como funciona o cache via Transients

O fluxo completo tem três funções principais. set_transient($key, $value, $expiration) guarda o valor com TTL. get_transient($key) recupera ou retorna false se expirou. delete_transient($key) remove explicitamente, útil para invalidação forçada.

O padrão de uso é quase sempre o mesmo: tenta pegar do cache, se não existir, calcula e guarda. Em código:

$dados = get_transient(‘chave_unica’);
if (false === $dados) {
  $dados = funcao_pesada_que_consulta_api();
  set_transient(‘chave_unica’, $dados, HOUR_IN_SECONDS);
}
return $dados;

Constantes de tempo predefinidas pelo WordPress facilitam a leitura. MINUTE_IN_SECONDS, HOUR_IN_SECONDS, DAY_IN_SECONDS, WEEK_IN_SECONDS, MONTH_IN_SECONDS evitam números mágicos no código. Use set_transient(‘chave’, $valor, 12 * HOUR_IN_SECONDS) em vez de 43200 — fica óbvio o que significa.

Existe ainda set_site_transient() e get_site_transient() para WordPress Multisite, que armazenam o transient no nível da rede inteira em vez do site individual. Útil quando o dado é compartilhado entre todos os sites da rede, como token de uma API externa que vale para a rede toda.

Casos de uso ideais

O caso mais clássico é cachear chamadas a APIs externas. Cada chamada via wp_remote_get gasta tempo de resposta da rede, e fazer 100 chamadas iguais em uma hora é desperdício. Cacheie o resultado por 1 hora, ou 6, ou 24 — o tempo apropriado depende de quão dinâmico é o dado. Endpoints de CEP (ViaCEP), cotação de moeda, lista de cidades brasileiras: todos beneficiam.

Consultas SQL pesadas são o segundo grande caso. Query de “top 10 produtos mais vendidos do mês” leva milissegundos em loja pequena, mas pode levar segundos em WooCommerce com 50 mil pedidos. Cachear por 1 hora reduz carga no banco em 99,9% sem prejuízo perceptível para o usuário.

Resultados de cálculos complexos seguem a mesma lógica. Se você gera um relatório que envolve várias queries, processamento e formatação, cache o resultado final por intervalo razoável. Dashboards administrativos, listas de mais vistos, recomendações computadas — todos cabem no padrão.

Para tarefas agendadas via WP-Cron que rodam periodicamente, transients servem como controle de execução. Marque um transient ao executar; ao tentar executar novamente antes do TTL, pule. Combinado com cache WordPress mais amplo, transients resolvem a camada de dados que cache de página inteira não cobre. Para casos críticos, vale considerar Object Cache dedicado.

Transients vs Object Cache vs Options

As três APIs são parecidas mas servem cenários diferentes. Options API armazena dados permanentes via get_option() e update_option() — sem expiração, sem TTL. Configurações do site, preferências de plugin, dados que devem persistir indefinidamente. Transients são para dados temporários com prazo de validade. Object Cache é a camada de cache de baixíssimo nível.

Quando Object Cache está ativo (via Redis ou Memcached), transients passam a usar o Object Cache como backend automaticamente. Em vez de gravar na tabela wp_options, os dados vão direto para a memória. Velocidade de leitura aumenta dramaticamente, e o banco para de receber writes desnecessários.

Sem Object Cache ativo, transients criam linhas na tabela wp_options. Em sites de alto tráfego que abusam de transients, isso pode acumular milhares de linhas órfãs (transients que expiraram mas nunca foram limpos automaticamente). Plugins como WP-Optimize têm rotinas específicas para limpar transients expirados periodicamente.

A regra prática: dado eterno, use Options API. Dado temporário com prazo, use Transient API. Dado de altíssima frequência de leitura em servidor com Redis, use o Object Cache diretamente via wp_cache_get() e wp_cache_set() — não passa pelo banco mesmo nos misses, e tem performance superior aos transients.

Em projetos que usam Options API e Transients juntos, vale revisar periodicamente quais options foram cadastradas como autoload (carregam em toda requisição) para evitar overhead. Options pesadas que mudam pouco merecem ser convertidas para transients com TTL longo.

Para sites WordPress que precisam de cache de banco de dados otimizado e gestão automática de transients órfãos, a FULL Services entrega o WP Optimize licenciado e configurado dentro do painel, junto com Redis Object Cache integrado em planos premium e tuning de banco de dados pronto. É a forma de manter Transient API funcionando em escala sem que o crescimento do site quebre a tabela wp_options.