--- title: "Por que meu WordPress está lento? Como achar a causa" id: "595" type: "post" slug: "por-que-meu-wordpress-esta-lento" published_at: "2026-10-06T20:00:50+00:00" modified_at: "2026-10-06T20:22:47+00:00" url: "https://danielpazwp.com/pt/por-que-meu-wordpress-esta-lento/" markdown_url: "https://danielpazwp.com/pt/por-que-meu-wordpress-esta-lento.md" excerpt: "Um passo a passo de diagnóstico: confirme nos dados de campo, separe tempo de servidor e de navegador e ache o plugin, a query ou o script culpado." taxonomy_category: - "Performance" --- [Performance](https://danielpazwp.com/pt/category/performance-pt/) 8 min de leitura # Por que meu WordPress está lento? Como achar a causa Um passo a passo de diagnóstico: confirme nos dados de campo, separe tempo de servidor e de navegador e ache o plugin, a query ou o script culpado. Publicado **06/10/2026**8 min de leitura [Escrito porDaniel Paz](https://danielpazwp.com/pt/author/daniel-paz/) Se a pergunta é “por que meu WordPress está lento?”, a resposta está nos seus próprios dados, e dá para achar em mais ou menos uma hora. Primeiro confirme o problema com dados de campo de visitantes reais no Search Console ou no PageSpeed Insights. Depois separe tempo de servidor e tempo de navegador medindo o TTFB com e sem cache. Se o servidor está lento, use o Query Monitor e o banco para achar o plugin, a query ou a chamada remota que consome o tempo. Se o servidor está rápido, use o Chrome DevTools para achar a imagem, o script ou a tag de terceiro que atrasa a página. Corrija o maior primeiro. Este post é a metade do diagnóstico. No meu outro artigo, sobre [por que sites WordPress são lentos por motivos estruturais](https://danielpazwp.com/pt/por-que-seu-wordpress-e-lento-motivos-estruturais/) , explico as causas que encontro sempre: hospedagem, banco de dados, arquivos que bloqueiam a renderização e scripts de terceiros. Aqui a pergunta é mais estreita: no seu site, hoje, qual delas é? Quando você souber, o [guia de como acelerar o WordPress](https://danielpazwp.com/pt/como-acelerar-wordpress/) cobre as correções camada por camada. ## O site está lento para os visitantes ou só no teste? Confira isso antes de tudo, porque muita “lentidão” de WordPress é uma nota de laboratório numa única rodada. O PageSpeed Insights mostra duas coisas na mesma página: dados de campo do Chrome UX Report no topo e um teste de laboratório do Lighthouse embaixo. Os dados de campo são o que o Google usa para as Core Web Vitals: o percentil 75 dos carregamentos reais nos últimos 28 dias. - Se os dados de campo passam e só a nota de laboratório está baixa, não é uma emergência. É uma nota de laboratório. - Se os dados de campo reprovam, anote qual métrica reprova (LCP, INP ou CLS) e em quais grupos de URL. O relatório de Core Web Vitals do Search Console agrupa URLs parecidas, o que normalmente corresponde aos templates. - Se não há dados de campo, o site não tem tráfego suficiente do Chrome para entrar no CrUX. Use dados de laboratório e trate como aproximação. Por que os dois tipos de dado discordam é assunto para um artigo inteiro: [dados de campo vs dados de laboratório](https://danielpazwp.com/pt/core-web-vitals-dados-de-campo-vs-laboratorio/) . ## Por que meu WordPress está lento: servidor ou navegador? Todo carregamento de página se divide em duas metades: o tempo até o HTML chegar (TTFB) e tudo o que o navegador faz depois. Essa divisão diz onde procurar. | O que você vê | Camada provável | Onde olhar em seguida | | --- | --- | --- | | — | — | — | | TTFB alto em todas as páginas | Hospedagem, PHP, falta de cache de página | Testes de servidor abaixo, guia de TTFB | | TTFB rápido às vezes e lento em outras | Cache miss ou bypass | Cabeçalhos da resposta, cookies, query strings | | TTFB alto só em alguns templates | Um plugin, uma query ou uma chamada remota nesses templates | Query Monitor | | TTFB bom, LCP ruim | Imagens, CSS, fontes, scripts que bloqueiam | Painel Performance do DevTools, guia de LCP | | LCP bom, INP ruim | JavaScript e tags de terceiros | DevTools com throttling de CPU, guia de INP | | Admin lento, front-end bom | Heartbeat, admin-ajax, cron, telas pesadas de plugins | Query Monitor no wp-admin | O web.dev considera bom um TTFB de até 0,8 segundo. Se o seu está bem acima disso, comece pelo servidor mesmo que a reclamação tenha sido sobre imagens. ## Como saber se o problema é o servidor? Meça o TTFB direto, com e sem cache. No terminal: - `curl -o /dev/null -s -w "%{time_starttransfer}\n" https://example.com/` mostra o tempo até o primeiro byte - rode duas vezes na mesma URL; a segunda deve pegar o cache de página - rode de novo com uma query string como `?nocache=1` ou com um cookie de usuário logado para ver o tempo sem cache Depois leia os cabeçalhos da resposta com `curl -I`. A maioria dos caches de página adiciona um cabeçalho com HIT ou MISS, e a CDN adiciona o dela. Se as suas landing pages principais respondem MISS em requisições repetidas, o cache está sendo pulado. Os motivos comuns são cookies gravados para todo visitante, parâmetros de campanha e tempo de vida de cache curto. As três camadas de cache estão explicadas em [page cache, object cache, edge cache](https://danielpazwp.com/pt/page-cache-object-cache-edge-cache-qual-voce-precisa/) . Se o tempo sem cache é alto, o trabalho está no PHP e no banco. Aí você precisa de ferramentas que olham por dentro do WordPress. ## Como descobrir quais plugins estão deixando o WordPress lento? Com um profiler, e não desativando plugin por plugin em produção. A minha ordem: 1. Instale o [Query Monitor](https://wordpress.org/plugins/query-monitor/) numa cópia de homologação, ou em produção visível só para administradores. 2. Carregue o template lento logado e abra o painel Queries by Component. Ele agrupa as queries e o tempo delas por plugin e tema. 3. Abra o painel HTTP API Calls. Um plugin que chama uma API remota durante a geração da página é uma das coisas mais caras que encontro, e se esconde bem porque depende do servidor de outra empresa. 4. Confira o painel de Hooks e Actions atrás de callbacks que rodam em toda requisição mas só importam numa tela. 5. Se você tem WP-CLI, o pacote do comando profile (`wp profile stage` e `wp profile hook`) quebra a requisição em bootstrap, query principal e template, e depois em hooks individuais. 6. Se ainda precisar confirmar, desative plugins em homologação pela metade. Desligue metade, meça e vá estreitando na metade que mudou o número. Anote o tempo por plugin ou por hook. Isso transforma “o WordPress está lento” em “este plugin adiciona tanto tempo a este template”, um problema que dá para resolver ou levar ao fornecedor. ## Como saber se o problema é o banco de dados? Dois lugares cobrem a maioria dos casos. O primeiro são as opções com autoload: linhas da `wp_options` que o WordPress carrega em toda requisição. O Site Health avisa quando elas ficam grandes demais (desde o WordPress 6.6), e no WP-CLI o comando `wp option list --autoload=on --format=total_bytes` dá o tamanho total. Depois liste as maiores linhas e descubra qual plugin é dono de cada uma. O segundo são as queries lentas. O Query Monitor marca queries lentas e duplicadas em cada requisição. No servidor, o slow query log do MySQL ou do MariaDB mostra o que está lento em todo o tráfego, incluindo cron e tarefas em segundo plano que o Query Monitor nunca vê. Procure queries em `wp_postmeta` e `wp_options` sem índice utilizável, e a mesma query repetida dezenas de vezes numa página. A limpeza em si, e o que é seguro apagar, está em [otimização do banco de dados do WordPress](https://danielpazwp.com/pt/otimizacao-banco-de-dados-wordpress/) . ## Como descobrir o que deixa o front-end lento? Quando o TTFB está bom, o atraso está no navegador. O Chrome DevTools tem o que você precisa: - O painel Performance grava um carregamento e marca o LCP. Clique no marcador para ver o elemento e confira se ele teve lazy load, foi descoberto tarde ou ficou esperando CSS. - O painel Network, filtrado por domínio, mostra quantas requisições vêm de terceiros e quanto pesam. Ordene por tamanho e por horário de início. - O painel Coverage mostra quanto de cada arquivo CSS e JavaScript a página realmente usou. Em sites com builder a parte não usada costuma ser grande. - Para o INP, grave uma interação (abrir o menu, adicionar ao carrinho, fazer uma busca) com throttling de CPU ligado e procure tarefas longas. A aba Bottom-Up mostra qual script é dono do tempo. Os diagnósticos do PageSpeed Insights apontam para as mesmas coisas, mas o DevTools deixa você clicar até a causa. O post de [ferramentas de Core Web Vitals](https://danielpazwp.com/pt/ferramentas-core-web-vitals/) compara o que cada ferramenta mostra e quando usar. ## Por que só o admin do WordPress está lento? Um wp-admin lento com front-end rápido normalmente vem de coisas que o visitante nunca dispara: - a Heartbeat API consultando o `admin-ajax.php` enquanto os editores deixam abas abertas - o WP-Cron rodando tarefas pesadas nos carregamentos de página em vez de um cron de verdade no sistema - painéis e avisos de plugins que fazem chamadas remotas em toda tela do admin - telas de listagem que consultam tabelas de postmeta grandes, comum em lojas O Query Monitor também funciona no admin. No WooCommerce, as telas de pedidos e os relatórios merecem uma análise própria, que faço em [como resolver um admin do WooCommerce lento](https://danielpazwp.com/pt/admin-woocommerce-lento/) . ## O que fazer com o que você encontrou? Ordene. Para cada achado, anote a camada, os templates afetados, quanto tempo custa e quão difícil é corrigir. Problemas de servidor e cache afetam todas as páginas, então costumam ir para o topo mesmo quando o relatório do PageSpeed lista uma imagem primeiro. Depois corrija uma coisa de cada vez e meça de novo, para saber qual mudança ajudou. Para as correções mais comuns num formato de marcar, use o [checklist de velocidade do WordPress](https://danielpazwp.com/pt/checklist-velocidade-wordpress/) . Para entender o porquê da ordem de correção, volte ao [guia de engenharia para acelerar o WordPress](https://danielpazwp.com/pt/como-acelerar-wordpress/) . ## Quando pedir ajuda? Quando o diagnóstico aponta para algo que você não consegue mudar sozinho, ou quando as correções óbvias já foram feitas e os dados de campo continuam reprovando. É para isso que existe a minha [auditoria de performance WordPress](https://danielpazwp.com/pt/auditoria-performance-wordpress/) : passo por cada camada com os dados de campo como referência e entrego uma lista ordenada do que corrigir. Para trabalhos mais longos, veja como atuo como [especialista em performance WordPress](https://danielpazwp.com/pt/performance-wordpress/) . [Trabalhe com o Daniel](https://danielpazwp.com/pt/#book) [Mais em Performance](https://danielpazwp.com/pt/category/performance-pt/) [Sobre o autorPágina do autor](https://danielpazwp.com/pt/author/daniel-paz/) ## Artigos relacionados [Todos os artigos](https://danielpazwp.com/pt/artigos/) [Performance out 2026Page cache vs object cache vs edge cache: qual você precisa](https://danielpazwp.com/pt/page-cache-object-cache-edge-cache-qual-voce-precisa/) [Performance out 2026Core Web Vitals: dados de campo vs laboratório](https://danielpazwp.com/pt/core-web-vitals-dados-de-campo-vs-laboratorio/) [Performance out 2026WordPress lento: os motivos estruturais e a ordem para corrigir](https://danielpazwp.com/pt/por-que-seu-wordpress-e-lento-motivos-estruturais/)