O site que herdámos
Um site de comparação de seguros chegou a correr em WordPress com mais de 30 plugins ativos, uma base de dados de 705 MB e um Largest Contentful Paint de 7.7 segundos. Nada disto é exótico. É o padrão do excesso de plugins, um plugin instalado por problema até o stack colapsar sob o seu próprio peso, e é exatamente o que os projetos rápidos e assistidos por IA continuam a produzir. Este é um teardown do que estava realmente errado e do que o corrigiu.
O excesso de plugins raramente se anuncia. Nenhum plugin isolado é o vilão. O site funciona, lentamente, até alguém o medir e descobrir que o custo é cumulativo: cada plugin acrescenta consultas, scripts, estilos, uma obrigação de atualização e uma fatia de superfície de ataque, e trinta deles juntos transformam um simples site de conteúdo em algo que demora quase oito segundos a desenhar.
O pior culpado era um contador de visualizações
O maior problema isolado não era um page builder pesado nem uma imagem. Era um contador de visualizações. O site contava as visualizações dos artigos incrementando um valor em wp_postmeta a cada carregamento, de forma síncrona, dentro do pedido. wp_postmeta é uma tabela geral de chave-valor que o WordPress lê constantemente; não foi construída para uma escrita de alta frequência a cada visita. Deixado a correr, esse único mecanismo tinha feito crescer a wp_postmeta para 322 MB da base de dados de 705 MB.
O dano não é apenas no disco. Uma wp_postmeta inchada e quente abranda uma grande parte das consultas normais do WordPress, porque grande parte do sistema lê dela. Por isso, uma funcionalidade em que ninguém pensou, uma contagem de visualizações, sobrecarregava silenciosamente cada página. Remover a escrita síncrona e contar as visualizações corretamente devolveu a essa tabela um tamanho razoável e tirou carga de cada pedido.
O excesso também é uma história de segurança
O número de plugins não custou apenas velocidade. Alargou a superfície de ataque das formas previsíveis:
- Um endpoint
xmlrpc.phpaberto, um vetor clássico para brute-force e amplificação. - Erros PHP exibidos em produção, a revelar caminhos do servidor (divulgação de informação).
- Plugins com vulnerabilidades conhecidas, porque os plugins abandonados ou não atualizados deixam de ser corrigidos.
É por isso que cortar o número de plugins é uma medida de segurança, não apenas de desempenho. Cada plugin que remove é código no qual já não tem de confiar, vigiar e atualizar. É a mesma lógica que está por trás de uma auditoria de segurança WordPress bem feita: menos superfície, menos vias de entrada.
O que realmente o corrigiu
A correção foi pouco vistosa e eficaz:
- Auditar cada plugin face ao que realmente fazia, depois remover as sobreposições e os abandonados, e substituir pequenas tarefas de plugins por algumas linhas de código do tema.
- Reescrever o contador de visualizações para que deixasse de escrever em
wp_postmetaa cada pedido, o que permitiu à base de dados encolher de novo. - Mover mais de 1.5 GB de PDFs estáticos do servidor de aplicação para o armazenamento de objetos Cloudflare R2, para que o VPS não servisse ficheiros grandes que não lhe competia servir.
- Adicionar uma cache de objetos Redis para que as consultas repetidas atingissem a memória em vez da base de dados, aliviando o VPS de 3 vCPU.
- Fechar o
xmlrpc.php, desligar a exibição de erros em produção e atualizar os plugins restantes para versões corrigidas.
Nada disto é engenhoso. É disciplina aplicada a um stack que não tinha nenhuma, e é o grosso do que o verdadeiro trabalho de Core Web Vitals acaba por ser quando se olha para além da pontuação de laboratório.
Porque os projetos assistidos por IA continuam a recriar isto
O excesso de plugins é anterior à IA. Mas os assistentes de IA agravam-no de uma forma específica: quando a resposta a cada requisito é “instala um plugin para isso”, a dívida acumula-se mais depressa, porque sugerir um plugin é o caminho de menor resistência para um assistente tal como para uma pessoa com pressa. Acaba com o mesmo stack de 30 plugins, só que montado numa tarde. É por isso que este teardown se insere no nosso trabalho mais amplo de recuperação de sites feitos por IA: quer o excesso tenha vindo de uma pessoa ou de um prompt, a limpeza é idêntica, auditar, remover, substituir por código direcionado e medir.
Glossário
- wp_postmeta - uma tabela central do WordPress que armazena metadados de chave-valor para os artigos; lida com muita frequência, pelo que inchá-la abranda todo o site.
- Cache de objetos (Redis) - um armazenamento em memória que guarda os resultados de consultas repetidas à base de dados para que não atinjam a base de dados de cada vez.
- Armazenamento de objetos (Cloudflare R2) - armazenamento para ficheiros estáticos como PDFs e imagens, servidos de forma independente do servidor de aplicação.
- LCP (Largest Contentful Paint) - quanto tempo demora até o maior elemento visível ser desenhado; uma medida central da velocidade de carregamento percebida.
A conclusão
Se o seu site WordPress passou de uma dúzia ou duas de plugins, o custo quase nunca é um culpado óbvio. É a acumulação, mais um ou dois mecanismos silenciosos, um contador de visualizações, um log não indexado, uma chamada de API síncrona, a causar dano real em segundo plano. A correção é contar os plugins, encontrar o mecanismo que escreve a cada pedido e mover o peso estático pesado para fora do servidor de aplicação. Um site a 7.7 segundos não está perdido. Costuma ser um stack que ninguém auditou, o que é um problema muito diferente e muito mais barato do que parece.
