A regra popular "não use mais de 20 plugins" é mito na forma e verdade no espírito: não é a quantidade, é o peso e onde ele carrega. Um plugin de SEO bem feito carrega quase nada na página; um plugin de estatísticas mal feito carrega queries e scripts em cada visita. O que segue é o mapa de como um plugin pesa: e o método para encontrar os culpados.
Os 3 mecanismos pelos quais um plugin pesa
- Queries no banco: cada plugin que salva opções, lê tabelas próprias ou faz lookup por página soma queries no banco. Query Monitor mostra exatamente quantas cada plugin dispara: e as lentas aparecem em vermelho.
- Assets em toda página: o pior mecanismo: o plugin enfileira CSS e JS
globalmente(em toda página), mesmo quando só é usado em uma (o plugin de formulário carregando o JS dele na home, no blog, no checkout). Cada asset é um request: e em mobile, cada request custa. - Conflitos e processamento PHP: plugins que rodam código pesado em cada request (agendamentos mal feitos, chamadas externas síncronas) e conflitos entre plugins que duplicam bibliotecas (dois carregando jQuery de versões diferentes).
O método de auditoria (uma tarde, culpado encontrado)
- Instale o Query Monitor: o plugin de diagnóstico padrão do mercado: mostra queries por componente, tempo de execução e os scripts/styles carregados por página.
- Meça a página mais importante: a home, a página de venda, o artigo de maior tráfego: onde a performance mais custa.
- Desative um plugin por vez: meça a velocidade antes/depois (PageSpeed Insights ou teste no DevTools). Anote. Reative se não mudou nada.
- Classifique: os que pesam em toda página sem uso visível: substituir por código enxuto ou remover. Os essenciais e pesados: procurar alternativa leve ou configurar para carregar só onde é usado (muitos têm opção de "load only on...").
Plugin essencial pesado > plugin leve desnecessário: mas plugin desnecessário ativo é peso puro. A régua prática: cada plugin precisa justificar sua existência com uma função que o site usa e um peso aceitável na página. Plugin instalado há 2 anos que ninguém sabe o que faz é o candidato número 1 de remoção.
Os suspeitos clássicos (onde o peso se esconde)
- Page builders: carregam o framework inteiro em toda página; se o site usa um builder em tudo, o peso é o preço: se usa em uma página só, vale limitar o carregamento.
- Plugins de estatística/redirecionamento: queries por visita; os bem configurados guardam em cache, os mal feitos consultam o banco a cada request.
- Construtores de formulário: o JS/CSS carregando globalmente quando só 1 página tem formulário (quase todos têm opção de restringir: ative).
- Plugins de compartilhamento social: scripts de terceiros em toda página para um botão que uma função nativa faz.
Prevenção: o protocolo de instalação
Antes de instalar o próximo plugin, três perguntas: existe alternativa nativa (o Gutenberg resolve formulários simples, o GA4 nativo resolve estatística básica)? Quem mantém (atualização recente, compatibilidade declarada)? Como carrega (global ou só onde usado)? E a rotina que sustenta: revisão trimestral da lista de plugins com a mesma régua da auditoria: o guia de manutenção cobre a cadência completa. E o plugin que você mantém mas que carrega pesado em página errada: o guia técnico mostra o diagnóstico da fundação.
A leitura final: a performance do WordPress é a soma dos plugins que você deixou ativos: e a auditoria de uma tarde costuma devolver metade da velocidade perdida. Para o caso específico da loja, o guia de aceleração do WooCommerce; para o teto de infraestrutura, o guia de hospedagem compartilhada.