{"id":835,"date":"2026-09-17T11:07:20","date_gmt":"2026-09-17T11:07:20","guid":{"rendered":"https:\/\/100porcentowp.com.br\/central-de-ajuda\/cms\/profiler-de-plugins-wordpress\/"},"modified":"2026-09-17T11:07:21","modified_gmt":"2026-09-17T11:07:21","slug":"profiler-de-plugins-wordpress","status":"publish","type":"post","link":"https:\/\/100porcentowp.com.br\/central-de-ajuda\/performance\/profiler-de-plugins-wordpress\/","title":{"rendered":"Profiler de plugins WordPress: achar o que pesa no site"},"content":{"rendered":"

O que \u00e9 um profiler de plugins WordPress e por que ele resolve o que a auditoria geral n\u00e3o resolve<\/h2>\n

Voc\u00ea abre o site do cliente e ele demora 4 segundos para renderizar. J\u00e1 passou pelo cache, j\u00e1 minificou CSS e JS, j\u00e1 otimizou imagens, e o tempo n\u00e3o caiu. A auditoria de performance WordPress olha o site inteiro, mas n\u00e3o responde \u00e0 pergunta que interessa: qual plugin est\u00e1 consumindo o tempo. Um profiler de plugins WordPress isola exatamente isso, mostrando quanto cada plugin gasta em queries, hooks e chamadas HTTP.<\/p>\n

Na pr\u00e1tica, a diferen\u00e7a \u00e9 entre saber que o site est\u00e1 lento e saber que o plugin de formul\u00e1rio adiciona 380 ms em cada carregamento por causa de uma consulta que roda no init<\/code>. O primeiro diagn\u00f3stico leva a chutes. O segundo leva a uma decis\u00e3o.<\/p>\n

Query Monitor: o profiler de plugins que voc\u00ea j\u00e1 pode instalar<\/h2>\n

O Query Monitor \u00e9 o profiler mais usado em WordPress. Ele \u00e9 gratuito, vive no reposit\u00f3rio oficial e adiciona uma barra de ferramentas no rodap\u00e9 do site quando voc\u00ea est\u00e1 logado. A documenta\u00e7\u00e3o oficial do plugin fica em wordpress.org\/plugins\/query-monitor<\/a>.<\/p>\n

O ponto que muita gente ignora: o Query Monitor n\u00e3o mede o tempo de carregamento total do site. Ele mede o que acontece do lado do PHP, dentro do WordPress. Ou seja, ele mostra o custo de cada plugin em processamento, n\u00e3o o tempo de download de imagens ou o TTFB do servidor. Para a segunda parte, use o teste de velocidade de carregamento WordPress<\/a> em paralelo.<\/p>\n

Como ler a aba Queries sem se perder<\/h3>\n

Ao abrir qualquer p\u00e1gina do site logado, clique em “Queries” na barra do Query Monitor. A tela mostra tr\u00eas coisas \u00fateis:<\/p>\n

    \n
  1. O tempo total gasto em queries MySQL naquela p\u00e1gina.<\/li>\n
  2. A lista de queries, ordenada por tempo, com o tempo de cada uma.<\/li>\n
  3. Quem chamou cada query: o nome do plugin ou do tema aparece como “Caller”.<\/li>\n<\/ol>\n

    Voc\u00ea procura por queries que aparecem v\u00e1rias vezes com o mesmo padr\u00e3o. Um plugin que roda a mesma consulta 40 vezes numa p\u00e1gina de arquivo costuma ter problema de cache interno. O tempo somado dessas repeti\u00e7\u00f5es \u00e9 o que voc\u00ea vai comparar depois.<\/p>\n

    A aba Hooks mostra o custo por componente<\/h3>\n

    A aba “Hooks & Actions” lista os hooks do WordPress e quanto cada callback gasta. \u00c9 aqui que voc\u00ea descobre, por exemplo, que um plugin registra uma fun\u00e7\u00e3o no wp_head<\/code> que leva 120 ms. A aba “HTTP API” mostra as chamadas externas feitas por plugins, com o tempo de resposta de cada uma. Um plugin de frete que consulta uma API externa a cada carregamento de p\u00e1gina aparece aqui, e o tempo dele n\u00e3o \u00e9 culpa do seu servidor.<\/p>\n

    Medir tempo de carregamento de plugins: o m\u00e9todo antes e depois<\/h2>\n

    O Query Monitor mostra o custo agregado, mas nem sempre separa um plugin espec\u00edfico. Para isolar, voc\u00ea precisa do m\u00e9todo antes e depois: medir, desativar um plugin, medir de novo, comparar. O problema \u00e9 fazer isso num site de cliente em produ\u00e7\u00e3o.<\/p>\n

    Regra n\u00famero um: nunca desative plugin em hor\u00e1rio de pico<\/h3>\n

    Desativar um plugin em produ\u00e7\u00e3o pode quebrar o layout, o checkout ou o formul\u00e1rio de contato. Se o site \u00e9 de e-commerce, o risco \u00e9 pedido perdido. Escolha uma janela de baixo tr\u00e1fego, avise o cliente e tenha o backup do dia em m\u00e3os. O artigo sobre falha de backup no WordPress<\/a> explica o que verificar antes de confiar no arquivo de restaura\u00e7\u00e3o.<\/p>\n

    Passo a passo do teste controlado<\/h3>\n
      \n
    1. Anote o tempo de refer\u00eancia: abra a home, uma p\u00e1gina interna e o checkout (se houver) com o Query Monitor ativo e registre o tempo total de queries e o n\u00famero de queries.<\/li>\n
    2. Desative um \u00fanico plugin em Plugins \u2192 Plugins instalados.<\/li>\n
    3. Limpe o cache de objeto e o cache de p\u00e1gina, se houver. Sem isso, a medi\u00e7\u00e3o mente.<\/li>\n
    4. Recarregue as mesmas tr\u00eas p\u00e1ginas e anote os mesmos n\u00fameros.<\/li>\n
    5. Reative o plugin e repita com o pr\u00f3ximo da lista.<\/li>\n<\/ol>\n

      Uma diferen\u00e7a de 20 ms pode ser ru\u00eddo do servidor. Diferen\u00e7as acima de 100 ms em queries s\u00e3o sinal claro. Repita a medi\u00e7\u00e3o duas vezes antes de concluir, porque varia\u00e7\u00e3o de rede e cache de opcode distorcem o resultado.<\/p>\n

      Quando o site n\u00e3o pode sair do ar nem por cinco minutos<\/h3>\n

      Se o cliente n\u00e3o autoriza janela de manuten\u00e7\u00e3o, clone o site para um ambiente de teste. A maioria dos pain\u00e9is de hospedagem oferece isso. No clone, voc\u00ea pode desativar plugins \u00e0 vontade, ativar WP_DEBUG<\/code> e SAVEQUERIES<\/code> sem medo. O comportamento de performance costuma ser pr\u00f3ximo o suficiente para decidir qual plugin pesa. A ressalva \u00e9 que o clone pode ter menos tr\u00e1fego e cache diferente, ent\u00e3o os tempos absolutos n\u00e3o batem, mas a propor\u00e7\u00e3o entre plugins se mant\u00e9m.<\/p>\n

      O que fazer com o plugin que voc\u00ea identificou como pesado<\/h2>\n

      Encontrar o culpado \u00e9 metade do trabalho. A outra metade \u00e9 decidir o que fazer. Existem tr\u00eas caminhos, e a escolha depende do custo de cada um.<\/p>\n\n\n\n\n\n\n\n
      Situa\u00e7\u00e3o<\/th>\nCaminho indicado<\/th>\nRisco<\/th>\n<\/tr>\n<\/thead>\n
      Plugin tem op\u00e7\u00e3o de desativar m\u00f3dulo ou carregar script s\u00f3 onde precisa<\/td>\nConfigurar<\/td>\nBaixo, mas exige testar cada tela<\/td>\n<\/tr>\n
      Plugin faz o mesmo que outro j\u00e1 instalado, com menos custo<\/td>\nSubstituir<\/td>\nM\u00e9dio, migra\u00e7\u00e3o de dados e ajuste de layout<\/td>\n<\/tr>\n
      Plugin \u00e9 essencial e n\u00e3o tem alternativa vi\u00e1vel<\/td>\nConvocar<\/td>\nBaixo, mas exige aceitar o custo<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

      Configurar antes de substituir<\/h3>\n

      Muitos plugins pesados t\u00eam configura\u00e7\u00e3o que reduz o custo. Plugins de formul\u00e1rio costumam carregar CSS e JS em todas as p\u00e1ginas, mesmo onde n\u00e3o h\u00e1 formul\u00e1rio. Plugins de slider fazem o mesmo. Verifique se existe op\u00e7\u00e3o de carregar assets apenas nas p\u00e1ginas onde o shortcode aparece. Isso costuma resolver mais do que trocar de plugin.<\/p>\n

      Substituir com cuidado<\/h3>\n

      Trocar plugin \u00e9 a decis\u00e3o mais arriscada. Antes de remover, confirme que os dados migram, que os shortcodes continuam funcionando e que o layout n\u00e3o quebra. Se o plugin em quest\u00e3o for de login, o artigo sobre trocar plugin de login WordPress sem perder acesso<\/a> mostra o procedimento seguro. Para outros tipos, a l\u00f3gica \u00e9 parecida: nunca desinstale antes de ter o substituto configurado e testado.<\/p>\n

      Convocar com o plugin pesado<\/h3>\n

      Alguns plugins s\u00e3o pesados por natureza e n\u00e3o t\u00eam alternativa. Um plugin de assinatura recorrente, por exemplo, faz valida\u00e7\u00f5es que custam tempo. Nesse caso, aceite o custo e compense em outro lugar: cache de p\u00e1gina mais agressivo, CDN, upgrade de servidor. O importante \u00e9 saber que o tempo gasto ali \u00e9 consciente, n\u00e3o um mist\u00e9rio.<\/p>\n

      Erros comuns ao usar profiler de plugins WordPress<\/h2>\n