Excesso de plugins: quando um build com IA o deixa com 40 plugins ativos

#Quando a lista de plugins é mais longa que o mapa do site

Se o build também incluiu PHP personalizado de um assistente de IA, combine esta auditoria com a auditoria de código de plugins WordPress gerado por IA. Quando excesso, código personalizado e perda de tráfego se somam, o trabalho encaixa na recuperação de sites feitos por IA.

#O caso anonimizado: 38 plugins, 1,47 s de TTFB

Um site de serviços B2B (formação e consultoria para indústrias reguladas no mercado português) chegou-nos depois de um stakeholder interno ter corrido Lighthouse e perguntado porque é que «o WordPress parecia lento». O site foi montado em cerca de três semanas com Cursor e ChatGPT: estrutura de páginas, rascunhos de copy, fluxos de formulários e escolhas típicas de «instala algo para isso» do diretório de plugins. Ninguém era dono da lista de plugins.

O alojamento não mudou: um VPS de 2 vCPU com um fornecedor ibérico, PHP 8.2, sem object cache na entrada. Adicionámos Redis após a passagem de plugins, o que cortou mais ~120 ms de TTFB, mas a maior parte do ganho veio de remover e fundir plugins, não de upgrades de infraestrutura.

A primeira reação do cliente foi previsível: «Só adicionámos o que precisávamos». É assim que o excesso se apresenta. Cada instalação individual tinha uma razão plausível. O custo era acumulativo.

#Como builds com IA chegam a 40 plugins mais depressa que os manuais

O excesso manual costuma crescer durante meses: um freelancer adiciona um slider, marketing um popup, alguém instala um segundo plugin SEO «só para experimentar». O excesso assistido por IA comprime o mesmo comportamento em dias porque o modelo optimiza conclusão plausível, não coerência da pilha.

Padrões recorrentes em intakes de recuperação:

1. Um prompt, um plugin. O assistente não diz «estende o teu plugin de formulários existente». Devolve um slug.
2. Sem memória de inventário. A sessão dois não sabe que a sessão um instalou Rank Math; a quatro recomenda Yoast para «melhor schema».
3. Empilhamento de tutoriais. Posts e transcrições de YouTube com que o modelo foi treinado recomendam listas de «melhores plugins para X». O build herda a lista inteira.
4. Código personalizado mais excesso comercial. O mesmo assistente que sugeriu doze plugins também gerou três plugins personalizados pequenos como «correcções rápidas», acrescentando PHP sem manutenção sobre dependências sem manutenção.
5. Plugins optimizadores como penso. Quando o TTFB sobe, o próximo prompt é «instala um plugin de cache», por vezes sem desactivar o primeiro plugin de cache.

Nada disto requer má fé nem incompetência. Requer uma lacuna de processo: ninguém com responsabilidade de arquitectura WordPress reviu a pilha antes do lançamento.

#Oito categorias que sobressaem em builds com IA

No site anonimizado, estes oito baldes representavam 31 dos 38 plugins. A sua lista será diferente, mas as categorias repetem-se em recuperações.

#1. Ferramentas SEO e schema duplicadas

Dois plugins SEO activos. Ambos emitiam schema. Ambos ligados a wp_head. Um ficou de uma migração do alojamento anterior, outro da semana do build com IA. Mantenha um. Funda definições manualmente; não confie cegamente em importadores automáticos.

#2. Vários construtores de formulários

Contact Form 7, um construtor drag-and-drop de um prompt e um plugin leve de formulário modal captavam leads em caixas distintas. A consolidação moveu três formulários para um único construtor e eliminou o resto.

#3. Plugins de cache e otimização em competição

Um plugin de cache ao nível do alojamento e um segundo «speed booster» minificavam scripts em simultâneo. Produziram JavaScript partido intermitente na página de preços. Nunca execute duas camadas completas de cache HTML. Escolha um sistema e configure-o.

#4. Excesso de analítica e píxeis

Conector GA, plugin de píxel Facebook, plugin de tag LinkedIn Insight, trial de heatmap e GTM inserido duas vezes (uma por plugin, outra por snippet no cabeçalho). A medição não melhorou. O peso dos pedidos sim.

#5. Page builder e pacotes de addons

Elementor mais pacote comercial de addons mais slider legacy deixado «por precaução». A home usava o builder; páginas internas não. Exportámos secções estáticas onde foi possível e removemos o slider por completo.

#6. Duplicados de segurança e manutenção

Dois limitadores de login, um plugin gestor de ficheiros (removido de imediato) e um «limpador de base de dados» que corria em cada carregamento do admin. A segurança pertence a uma pilha deliberada, não a três plugins sobrepostos.

#7. Ferramentas de conteúdo e imagem com IA

Um plugin escritor com IA e uma ferramenta de alt automático acrescentavam cron jobs no admin e chamadas API externas. Os fluxos editoriais passaram para o processo de redacção; os plugins saíram.

#8. mu-plugins personalizados de IA

Três ficheiros em mu-plugins/ de PHP colado: um manipulador de redireccionamentos, um «fix» de permissões REST e um ajuste de coluna no admin. Um plugin de redireccionamento duplicava regras de .htaccess. Um tweak REST desactivou uma integração que marketing usava diariamente. Após a revisão de segurança, mantivemos o ajuste de coluna como código verificado num único ficheiro mantido e eliminámos os outros dois.

#Autodiagnóstico: sinais de que está muito fundo em plugins

Execute isto antes de instalar outro optimizador.

Instale Query Monitor em staging (não em produção se a política o proibir), carregue a home sem sessão e capture o stack de consultas. Essa única vista muitas vezes envergonha o suficiente para alguém assumir responsabilidade pela pilha.

#Triagem: manter, fundir, substituir, remover

Usamos um registo de quatro colunas em cada recuperação por excesso. Cada plugin activo recebe exactamente uma etiqueta.

Manter - único dono de uma função, mantido, sem sobreposição. Exemplo: o único plugin SEO após fundir definições.

Fundir - dois plugins com trabalhos adjacentes que uma ferramenta mantida pode cobrir. Exemplo: três plugins de formulários num só.

Substituir - o trabalho do plugin é válido mas a implementação é pesada; substituir por algumas linhas em child theme ou um padrão de bloco. Exemplo: um plugin de posts relacionados com WP_Query em cada vista substituído por um bloco curado.

Remover - abandonado, duplicado, perigoso ou sem uso. Plugins gestor de ficheiros, testes SEO hello-world e ferramentas de debug «temporárias» vão aqui.

Trabalhe em lotes de cinco a oito plugins no máximo. Desactive, teste checkout e formulários, meça TTFB, depois apague. Apagamentos em massa são como a produção parte numa sexta-feira.

No site anonimizado a divisão foi assim:

• Manter: 21 plugins após consolidar (um SEO, formulários, uma cache, uma suite de segurança)
• Fundir: 9 plugins absorvidos por ferramentas mantidas
• Substituir: 4 trabalhos de plugin movidos para código de tema ou blocos
• Remover: 8 plugins apagados (incluindo 2 abandonados, 1 gestor de ficheiros, 1 cache duplicada)

#Plugins personalizados de IA continuam a ser plugins

As equipas contam frequentemente só plugins do diretório e esquecem mu-plugins ou plugins de «code snippets» que injectam PHP. Assistentes de IA adoram gerá-los porque parece mais rápido do que ensinar estrutura correcta de plugin.

Trate cada ficheiro personalizado como código de terceiros:

• Procure guards ABSPATH, nonces e $wpdb->prepare()
• Verifique se a funcionalidade duplica um plugin existente
• Mova código que sobrevive para controlo de versões, não para uma caixa de colar no wp-admin

Se encontrar nonces em falta e SQL concatenado, pare de desinstalar plugins comerciais até o código personalizado estar delimitado. PHP personalizado mau mais uma pilha comercial a encolher pode expor endpoints que ninguém recordava.

#Fluxo de consolidação em staging

1. Congele novas instalações. Nenhuma resposta de plugin até existir o registo.
2. Exporte a lista activa para uma folha: slug, versão, data da última actualização, trabalho declarado, trabalho real.
3. Assinale sobreposições em SEO, cache, formulários, analítica e segurança primeiro.
4. Desactive duplicados em staging, limpe todas as caches, teste caminhos de conversão principais.
5. Meça TTFB e contagem de consultas na home, landing mais pesada e página de agradecimento de checkout/contacto.
6. Apague em lotes pequenos, meça de novo após cada lote.
7. Documente a pilha final no README do projeto ou na entrega ao cliente, para que a próxima sessão de IA tenha um inventário para consultar.

O preço do trabalho de recuperação é sempre individual porque a contagem de plugins é apenas uma variável. O inchaço da base de dados, o código personalizado de IA e o nível de tráfego pesam tanto como o número no wp-admin.

#O que não fazer

• Não instale um plugin «gestor de plugins» para corrigir o excesso. Está a adicionar outro plugin.
• Não active duas caches de página completa «por segurança».
• Não deixe um assistente de IA gerar um script de limpeza que apague linhas em massa em wp_options sem cópia de segurança e revisão diff.
• Não assuma que plugins desactivados são inofensivos. Alguns continuam a carregar código em init em estados estranhos; apague após verificação.
• Não omita testes de formulários e checkout porque «é só um blog». No caso anonimizado, o JavaScript partido estava na página de preços, não no índice do blog.

#Quando escalar para recuperação

A limpeza incremental funciona quando as sobreposições são óbvias, o código personalizado é mínimo e alguém técnico controla staging. Escale para uma recuperação de sites feitos por IA formal quando:

• Os plugins activos se mantêm acima da meia-treintena após um primeiro passe
• Vários plugins personalizados de IA tocam autenticação, uploads ou SQL
• O TTFB sem cache permanece acima de ~1 s após remover cache e SEO duplicados
• O negócio não se pode permitir um formulário ou fluxo de pagamento partido durante apagamentos sem orientação
• Scans de segurança mostram CVE conhecidos em plugins abandonados que ninguém actualizará

Recuperação não é um eufemismo de reconstrução. No caso acima, 17 plugins abandonaram a pilha e o site manteve o mesmo tema e tier de alojamento. A entrega é um registo medido, não um pitch de venda para uma plataforma nova.

#Medir sucesso para além da contagem de plugins

A contagem de plugins é um proxy. Acompanhe métricas que reflectem a experiência do utilizador:

Após consolidar, defina um orçamento de plugins: para esta classe de site, nenhum plugin novo sem retirar ou fundir um existente. Escreva essa regra no ficheiro de instruções do projeto para assistentes de IA e o próximo pedido não desfará a recuperação numa tarde.

#Glossário

• Plugin sprawl / excesso de plugins - acumulação de plugins activos com trabalhos sobrepostos até degradarem desempenho, segurança e manutenibilidade.
• TTFB (Time to First Byte) - tempo de resposta do servidor antes do browser renderizar conteúdo; sensível à contagem de hooks PHP e consultas à base.
• mu-plugin - plugin must-use carregado em cada pedido a partir de wp-content/mu-plugins/; frequentemente usado para «correcções rápidas» geradas por IA.
• Opções autoload - opções WordPress carregadas em cada pedido; inchadas por plugins que guardam arrays grandes com autoload=yes.
• Excesso de consultas - consultas excessivas à base por vista de página, habitual quando muitos plugins obtêm metadados de forma independente.

#Conclusão

Quarenta plugins de profundidade não é uma falha moral. É o que acontece quando a montagem rápida assistida por IA ultrapassa a revisão de arquitectura. O site anonimizado deste guia passou de 38 para 21 plugins activos, mediana de TTFB sem cache de 1,47 s para 0,68 s, e consultas na home de 187 para 94 sem mudar de alojamento nem reconstruir o tema. O trabalho foi tedioso, mensurável e na maior parte desinstalações.

Comece pelo registo, elimine camadas duplicadas de SEO e cache, audite ficheiros personalizados de IA antes de celebrar apagar plugins comerciais, e meça após cada lote. Se a pilha continuar a resistir, é para isso que serve a recuperação de sites feitos por IA: uma divisão manter-reescrever-remover com números anexos, não outra recomendação de plugin.