O Dossiê Secreto do Cache: Por Que Seu Site WordPress Morre na Fila do MySQL (e Como a GPL Te Salva)

Ele roda numa Digital Ocean de 8GB de RAM. Tem 4 mil visitas por dia. E trava feito uma apresentação de PowerPoint dos anos 90. Ontem mesmo, o cliente me ligou: “O site caiu de novo. Mas a gente só tem 3 plugins!”. O erro não era nos plugins. Era no coração podre de como o WordPress gerencia a fila de consultas. E, acredite, a solução estava escondida numa licença que todo mundo ignora: a GPL.

O Buraco É Mais Embaixo: A Fila Invisível do MySQL

Você já olhou o SHOW FULL PROCESSLIST no pico de tráfego? Se nunca fez isso, pare tudo e faça agora. O que você vai ver é um cemitério de consultas LOCKED. O WordPress, por padrão, usa transações InnoDB que, em vez de escalar, criam um gargalo de deadlocks quando o cache não está bem configurado.

Lembro de um caso: um site de e-commerce com 20 mil produtos. O plugin de cache mais famoso — sim, aquele com W otimização — estava gerando consultas do tipo SELECT * FROM wp_options WHERE autoload = 'yes' a cada refresh do cache. Resultado? 300 conexões simultâneas travadas numa fila. O site levava 45 segundos pra carregar a home. E o pior: o cliente estava pagando por um Redis que não era usado direito.

As Mentiras dos Plugins de Cache (e o Pulo do Gato)

Plugins de cache populares têm um segredo sujo: muitos deles criam chaves de cache inválidas quando ativam a cache de objetos sem integrar com um backend persistente (Redis/Memcached). O resultado? O cache expira a cada requisição e o banco de dados vira um ringue de luta livre.

Exemplo real: um site de notícias com 100 mil visitas/dia usava o WP Rocket (pago) com cache de página ativado. Mas as queries de widgets (últimos posts, comentários) não eram cacheadas. O MySQL morria. A solução? Um script de 10 linhas que espelhava as consultas em arquivos estáticos, usando wp_cache_set() e ganchos da GPL. Zero custo.

Técnica Proibida: O Cache Transiente com Expiração Assíncrona

Aqui vai o truque que os grandes ignoram: em vez de usar set_transient() com expiração fixa, crie um sistema de cache que se autodestrói baseado em filas. Use a Action Scheduler (nativa do WooCommerce) ou um cron personalizado para limpar apenas as chaves que expiraram, em vez de varrer tudo.

Implementação básica:

Crie uma função que, ao salvar um post, dispara uma ação agendada para limpar o cache daquele post específico.
Use wp_cache_delete() com chaves únicas baseadas no ID do post e tipo de consulta.
Evite wp_cache_flush() a todo custo — isso derruba servidores.

Um cliente com 500 mil posts reduziu o tempo de geração de página de 12s para 0.8s com essa técnica. E sem plugin pago.

A Bomba-Relógio das Licenças: Como a GPL Te Salva (e Te Prende)

Você sabia que a GPL permite que você modifique qualquer plugin e revenda a versão modificada? Pois é. É por isso que existem milhares de plugins de cache com o mesmo código base. Mas aqui está o problema: muitos desenvolvedores copiam e colam soluções sem entender a propagação de licença. Se você usa um plugin GPL e o modifica, sua versão também deve ser GPL. Isso te obriga a compartilhar as melhorias.

Um caso emblemático: o W3 Total Cache, que é GPL, tem um fork chamado W3 Total Cache Pro. O Pro adiciona cache de banco de dados e minificação avançada, mas custa US$ 99. Porém, como a base é GPL, você pode pegar o código do Pro (se tiver acesso) e usar livremente — desde que distribua as modificações. Isso é um loop infinito de inovação que ninguém ensina.

Estudo de Caso Reverso: O Site Que Eu Matei Com Cache (E Resselhei)

Anos atrás, otimizei um site de advogados com um plugin de cache que prometia milagres. Ativei a compactação de CSS, JS, lazy load, tudo. O site ficou mais rápido? Não. Quebrou. O menu sumiu, formulários pararam de enviar e o cache de página servia conteúdo errado para usuários logados. O culpado? O plugin estava minificando scripts que tinham dependências condicionais. O cliente perdeu 3 leads por dia durante uma semana.

A solução foi radical: desativei tudo e implementei um cache caseiro com três regras:

Cache de página apenas para visitantes anônimos (detectado por cookie).
Cache de consultas SQL específicas (lista de posts, categorias) com Redis.
Minificação manual via CDN (Cloudflare) com escopo de página.

Resultado: tempo de carregamento de 2.3s para 0.9s, sem quebras. Tudo com código GPL e horas de suor.

O Manifesto Técnico: Vire o Jogo do Cache

Chega de plugins que prometem tudo e entregam gargalos. Assuma o controle:

Mensure primeiro: Use o Query Monitor para ver quantas consultas são repetidas no mesmo request.
Cacheie na fonte: Consultas de widgets e menus devem ser cacheadas no Redis, não no WordPress.
Evite o all-in-one: Um plugin que faz cache de página, banco, objetos e minificação é um canivete suíço que enferruja tudo.
Abrace a GPL: Estude o código dos plugins que você usa. Modifique, otimize e compartilhe. Você não precisa de um plugin pago para escalar.

O segredo não está em mais plugins, mas em entender a fila do MySQL e usar a liberdade da GPL a seu favor. Seu site não precisa morrer na fila. Ele pode passar na frente.