O diagnóstico de performance métricas é o processo de medir os números que descrevem a velocidade do seu site e ler cada um deles para descobrir onde está o gargalo. Muita gente olha só a nota colorida do PageSpeed Insights e troca de plugin no escuro. O caminho certo é diferente: você isola a métrica que está pior, descobre se a causa é a hospedagem, o tema ou um plugin, e só então age. Neste guia, a gente usa as ferramentas reais que toda equipe técnica usa e mostra como interpretar LCP, INP, CLS e TTFB sem adivinhar. Para entender o conjunto antes de mergulhar, comece pelo nosso guia de Core Web Vitals no WordPress e pelos demais conteúdos de performance WordPress da FULL.

As 5 métricas do diagnóstico de performance métricas

O diagnóstico de performance métricas gira em torno de cinco números, e o LCP abaixo de 2,5 s é o primeiro deles. Segundo a web.dev, esses limites valem no percentil 75 dos carregamentos, medido separadamente em celular e desktop. Antes de abrir qualquer ferramenta, fixe na cabeça o que cada métrica responde, porque é isso que transforma uma nota vaga em uma acao concreta.

Cada linha aponta para uma causa diferente. Um TTFB de 900 ms grita “servidor”, enquanto um INP de 400 ms grita “JavaScript pesado”. Ler a tabela já filtra metade dos palpites errados que a gente vê no suporte da FULL, e é por isso que o diagnóstico de performance métricas começa pelos números, e não pela cor.

Por que a nota colorida engana no diagnóstico

A nota verde do PageSpeed Insights engana porque ela é só um resumo ponderado de vários números. Um site pode marcar 92 no laboratorio (Lighthouse) e ainda falhar no campo real, porque o teste sintetico roda em uma rede ideal que o usuário de celular 4G nunca tem. Um diagnóstico de performance métricas sério ignora a cor e olha o valor cru de cada item.

O PageSpeed Insights mostra dois blocos: “Dados de Campo” (do relatório CrUX, com usuários reais nos ultimos 28 dias) e “Diagnóstico” (do Lighthouse, simulado na hora). Um bom diagnóstico de performance métricas sempre confia no campo quando os dois discordam. Em testes de PageSpeed no WordPress, é comum o laboratorio premiar um site que, na mão do visitante, trava no INP. A cor te dá a sensacao de progresso; o número te dá a verdade.

Passo a passo: Como fazer o diagnóstico em 5 passos

O diagnóstico de performance métricas roda em cinco passos que levam de 20 a 40 minutos, do teste de campo até a causa raiz isolada. A ordem importa: você sempre vai do dado real do usuário para o dado interno do servidor, nunca o contrario. Pular a etapa de campo é o que faz tanta gente “otimizar” o que já estava bom e ignorar o gargalo verdadeiro.

Passo 1: Rode o PageSpeed insights na URL principal

Abra o PageSpeed Insights, cole a URL da página mais visitada e leia primeiro o bloco de campo. Anote LCP, INP e CLS de celular, porque mais de 60% do tráfego brasileiro é mobile. Se o bloco de campo nem aparecer, o site tem pouco tráfego e você vai depender do laboratorio com cautela. Guarde os três números antes de mexer em qualquer coisa.

Passo 2: Confirme o TTFB no GTmetrix

Rode a mesma URL no GTmetrix e va direto na aba “Waterfall” para ler o TTFB do primeiro request. Um TTFB acima de 600 ms aponta para a hospedagem ou a falta de cache de página, não para o front-end. O waterfall ainda mostra quais arquivos demoram mais a baixar, separando imagem pesada de script lento com clareza que a nota sozinha nunca dá.

Passo 3: Cace o plugin culpado com o query monitor

Instale o Query Monitor e abra uma página lenta logada como administrador para ver o tempo de cada query e de cada plugin. Ele lista as consultas mais demoradas ao banco e o tempo de PHP por componente, revelando o plugin que sozinho consome 800 ms. Esse é o passo que separa encontrar o plugin lento de chutar no escuro qual desativar primeiro.

Passo 4: Meta o INP real no chrome DevTools

Abra o Chrome DevTools, va na aba “Performance” e grave uma interacao tipica, como abrir o menu ou clicar em um botão. O painel mostra quanto tempo a thread principal ficou travada respondendo ao toque, que é exatamente o que o INP mede em campo. Tarefas longas acima de 50 ms, marcadas em vermelho, são o JavaScript que precisa de exclusão ou adiamento.

Passo 5: Cruze os números e nomeie a causa raiz

Feche o diagnóstico de performance métricas juntando os quatro números e escrevendo, em uma frase, qual é o gargalo dominante antes de tocar em config. TTFB alto com LCP alto é hospedagem; INP alto com TTFB bom é JavaScript; CLS alto isolado é imagem ou fonte sem reserva de espaco. Nomear a causa em uma frase impede a tentacao de instalar cinco plugins de cache de uma vez.

Como interpretar cada métrica do diagnóstico de performance

Interpretar o diagnóstico de performance métricas é ligar cada número a uma causa fisica, e não a um sentimento de “está lento”. Um LCP de 4 s não significa “site ruim”; significa que o maior elemento (quase sempre a imagem hero ou um bloco de texto acima da dobra) demorou demais por causa de servidor, imagem ou render-blocking. Cada métrica tem um vocabulario próprio de causas.

O TTFB acima de 600 ms em servidor compartilhado sem cache de página, somado a um WordPress com muitos plugins, estoura o LCP mesmo com imagens otimizadas, porque o relogio começa antes da imagem carregar. Já um plugin de terceiros injetando JavaScript no head, combinado com tema pesado, costuma jogar o INP acima de 200 ms em celular intermediario. Para o lado do TTFB no WordPress, o gargalo quase sempre mora na hospedagem, não no tema.

As 4 ferramentas que sustentam o diagnóstico

O diagnóstico de performance métricas confiável se apoia em quatro ferramentas que se complementam, cada uma cobrindo um angulo que as outras não alcancam. Usar as quatro em ordem reduz o tempo de diagnóstico de horas para minutos, porque nenhuma sozinha conta a historia toda do site.

O PageSpeed Insights compete por dado de campo real, vindo do CrUX com usuários de verdade dos ultimos 28 dias. O GTmetrix compete por waterfall detalhado, mostrando cada request em milissegundos e o tamanho exato de cada arquivo. O Query Monitor compete por diagnóstico interno, lendo queries e tempo de PHP que ferramenta de campo nenhuma enxerga. O Lighthouse, embutido no Chrome, fecha o conjunto com a auditoria sintetica que aponta render-blocking e imagens sem compressao. A regra é cruzar pelo menos duas dessas fontes antes de concluir qualquer coisa. Veja a lista completa em nosso comparativo de ferramentas para testar desempenho.

Diagnóstico de performance métricas em WooCommerce e casos densos

Em lojas WooCommerce, o diagnóstico de performance métricas precisa olhar o admin e o banco, não só a home. Em sites com mais de 1.000 produtos rodando em VPS abaixo de 2GB de RAM, a nota do PageSpeed cai por causa de queries lentas no admin-ajax, e não do front-end. É um padrão recorrente nos diagnósticos do suporte da FULL.

O Query Monitor revela essa query escondida que o PageSpeed nunca veria, porque ela roda no carrinho ou no checkout, fora da página testada. Nesses cenarios, a melhora real vem de cache de objeto com Redis e de limpar o banco de transients antigos, não de minificar CSS. Carrinhos e contas de usuário não podem ser cacheados como HTML estático, o que limita o ganho do cache de página em até 40% nessas rotas. Quem está com WordPress lento de forma geral ganha mais isolando o gargalo do banco do que trocando o plugin de cache pela quinta vez.

Aja sobre o diagnóstico com a stack certa da FULL

Depois que o diagnóstico de performance métricas aponta o gargalo, a correção costuma exigir uma combinacao de plugins premium afinados. No plano PRO da FULL, por R$849 ao ano, você ativa WP Rocket, Perfmatters e os demais com um clique, o que dá cerca de R$85 por site quando o bundle é distribuido entre os dez sites do plano. A gente vê no suporte da FULL que a maior parte da lentidao se resolve com cache de página e exclusão de JavaScript bem configurados, e não com mais plugins soltos. Conheca a stack completa em FULL.services/planos e pare de comprar licença avulsa cara para cada site.

Perguntas frequentes sobre diagnóstico de performance

Próximos passos para acelerar o seu site

Com o diagnóstico de performance métricas em mãos, você sai do palpite e entra na acao dirigida: cada número ruim aponta uma correção específica, e não mais um plugin aleatorio. Resuma o gargalo em uma frase, ataque a métrica pior primeiro e meça de novo para confirmar o ganho. O ciclo medir, agir e medir de novo é o que separa quem acelera de verdade de quem só troca de plugin. Para continuar aprendendo, o FULL Academy reune os tutoriais de performance em um só lugar, e o guia Acelere o WordPress conecta cada métrica deste diagnóstico a um plano de correção completo.

Legenda: o bloco de dados de campo do PageSpeed prova que o número real do usuário difere da nota de laboratorio.