Quantos plugins no WordPress são demais? Não é o número, é o peso

Atualizado em 19/06/2026

"Quantos plugins no WordPress são demais?" é uma das perguntas que mais ouço, e a resposta honesta decepciona quem quer um número fechado: não existe limite mágico. Em mais de 12 anos atendendo sites como freelancer no Brasil, já vi sites rápidos e seguros com mais de 30 plugins leves e sites travados com menos de 10 plugins mal feitos. O que pesa não é a quantidade, é a qualidade e o peso somado de cada plugin. Neste artigo eu explico como avalio isso na prática, os sinais de "plugin bloat" que vigio e quando vale trocar um plugin por código sob medida.

Antes de tudo, deixo claro: plugins são uma das maiores forças do WordPress. Eles resolvem em minutos o que custaria dias de programação, e eu uso plugins o tempo todo nos meus clientes. O problema nunca foi "usar plugin" — foi usar sem critério. Esse mesmo deslize aparece na minha lista de erros comuns em sites WordPress, e quase sempre é manutenção, não tecnologia.

Por que "quantos plugins" é a pergunta errada

Quem foca no número parte de uma ideia equivocada: a de que cada plugin custa o mesmo. Não custa. Um plugin que só adiciona um campo no painel e não carrega nada no site visitado é praticamente de graça. Já um plugin de página inicial arrastada, que injeta meia dúzia de arquivos de CSS e JavaScript em todas as páginas e faz dezenas de consultas ao banco por requisição, pesa sozinho mais que dez plugins enxutos juntos.

É por isso que contar plugins não diz quase nada. O que diz é medir o consumo de cada um. Os três fatores que realmente importam são:

• Consultas ao banco de dados: quantas queries o plugin dispara por página. Plugins mal feitos consultam o banco dezenas de vezes onde uma ou duas bastariam.
• Scripts e estilos carregados: arquivos de CSS e JS injetados em toda página, inclusive onde o recurso nem é usado. É a causa número um de site inflado.
• Trabalho de PHP por requisição: processamento que roda a cada carregamento — loops pesados, chamadas externas, tarefas que deveriam estar em fila.

O que é "plugin bloat" e como ele aparece

"Plugin bloat" é o nome do inchaço que se acumula quando o site vai ganhando plugin sobre plugin sem ninguém revisar. Não acontece de uma vez — é gradual. Hoje instala um para um formulário, mês que vem outro para um slider, depois um para um pop-up, e em um ano o site carrega o triplo de arquivos sem que o dono perceba. Os sinais que eu reconheço de longe:

• O wp-admin demora a carregar — sinal de plugins pesados rodando no painel;
• O site melhora pouco mesmo com cache configurado;
• A página inicial carrega dezenas de arquivos de CSS/JS, muitos de plugins que você usa em uma página só;
• Dois ou três plugins fazendo a mesma coisa (dois de SEO, dois de cache, dois de formulário);
• Plugins instalados para um teste antigo e nunca removidos;
• Plugins sem atualização há mais de um ano, parados no painel.

O sintoma mais visível do bloat é lentidão, e ela bate direto nos Core Web Vitals — as métricas de experiência que o Google usa como sinal de ranking. Cada arquivo a mais para baixar e processar empurra o LCP para cima e piora a sensação de site travado. Quando alguém me chama por causa de velocidade, o excesso de scripts de plugin está quase sempre entre as primeiras causas. Detalho o diagnóstico completo em por que o WordPress está lento.

Como eu audito os plugins de um site, na prática

Quando faço uma auditoria, eu não conto plugins — eu meço. O processo que sigo é mais ou menos este:

1. Backup primeiro. Antes de desativar ou remover qualquer coisa, eu garanto um backup recente e testado. Nunca mexo na lista de plugins sem rede de segurança.
2. Mapear o que cada plugin faz. Listo todos e marco a função real de cada um. É aqui que aparecem os esquecidos: "para que serve esse mesmo?".
3. Medir consultas e tempo de PHP. Uso o Query Monitor para ver, página a página, quantas queries e quanto tempo cada plugin consome. O vilão costuma se revelar rápido.
4. Olhar o waterfall de carregamento. Com ferramentas de cascata (como o WebPageTest), vejo os arquivos de CSS e JS que cada plugin injeta e onde dá para cortar.
5. Caçar duplicações e abandonados. Plugins que fazem a mesma coisa viram um só; plugins sem manutenção ganham substituto mantido ou são removidos.
6. Remover de verdade o que sobra. Desativar não basta (já volto nisso). O que não é usado, eu desinstalo e apago.

Plugin desativado não é plugin removido

Esse ponto merece um aviso forte porque muita gente erra. Desativar um plugin faz ele parar de rodar, mas os arquivos continuam no servidor. E arquivo de plugin desatualizado pode ser explorado por um invasor mesmo estando inativo — a vulnerabilidade está no código, e o código segue lá. Manter dez plugins desativados "por via das dúvidas" não traz nenhum benefício e aumenta a superfície de ataque.

Como eu escolho um plugin (quando vale instalar)

Instalar um plugin é assumir uma dependência de longo prazo: alguém vai ter que mantê-lo atualizado e compatível por anos. Por isso eu escolho com critério. O que olho antes de instalar:

Repare que o preço não está na lista. Plugin pago não é automaticamente melhor — já vi premium pesado e gratuito impecável. O que conta é manutenção, código limpo e fazer uma coisa bem feita. Se você está montando um site do zero e pensando em orçamento de ferramentas, eu falo sobre os fatores de custo em quanto custa um site WordPress.

Quando eu troco um plugin por código sob medida

Nem tudo precisa de plugin. Em muitos casos, vinte ou trinta linhas no tema-filho resolvem o que um plugin inteiro fazia — sem o peso, sem a dependência e sem o risco de abandono. As situações em que eu prefiro código:

• Você usa 5% de um plugin gigante. Um plugin enorme instalado só para um ajuste pequeno é peso puro. O ajuste cabe em um snippet.
• Vários plugins resolvem uma coisa só. Dá para consolidar tudo em uma função sob medida e remover três dependências.
• O único plugin que faz aquilo está abandonado. Em vez de carregar um risco, eu reescrevo a funcionalidade de forma mantida.
• O plugin carrega scripts em toda página sem necessidade. Com código próprio, eu enfileiro o asset só onde ele é usado — explico essa técnica em enfileirar scripts e estilos.

Mas eu não trato isso como dogma. Plugin sério e ativamente mantido — um SEO consolidado, um cache, um WooCommerce — vale manter, porque reescrever do zero seria desperdício e mais propenso a erro. O bom senso é: código sob medida para o que é pequeno, específico ou abandonado; plugin para o que é grande, complexo e bem mantido. Esse equilíbrio é parte do meu trabalho de desenvolvimento sob medida.

Resumindo: foque no peso, não no número

Se você levar uma só ideia deste artigo, que seja esta: pare de contar plugins e comece a medir o peso deles. Um site enxuto não é o que tem poucos plugins — é o que tem plugins bem escolhidos, mantidos, que carregam só o necessário e não duplicam funções. Você pode ter 25 plugins e um site rápido e seguro, ou ter 8 e um site travado e vulnerável. O número, sozinho, não conta a história.

Minha recomendação honesta é a mesma de sempre: tenha alguém responsável por revisar essa lista de tempos em tempos, medindo de verdade e removendo o que não serve. Pode ser você, com método, ou pode ser um profissional. O que não funciona é deixar o plugin bloat crescer no escuro até virar lentidão e brecha de segurança ao mesmo tempo.