Painel Performance do Chrome DevTools

TL;DR — O painel Performance é uma ferramenta integrada ao Chrome. Abra o DevTools, escolha Performance e grave o carregamento para ver cada script, solicitação de rede, etapa de layout e pintura. Ao contrário do PageSpeed Insights, ele não atribui uma nota: entrega o trace bruto para você descobrir por que a página está lenta. A gravação representa o seu navegador, não o Googlebot, e pode ser usada gratuitamente, sem conta.

O que é

O Chrome DevTools tem várias abas. O painel Performance serve para registrar como uma página carrega e funciona e, depois, investigar os detalhes. Ele organiza em uma linha do tempo o download de arquivos, a execução de JavaScript, o layout e a pintura, permitindo ampliar qualquer intervalo.

Pense assim: PageSpeed Insights e Lighthouse se parecem com um boletim — executam um teste e entregam uma nota e uma lista de ações. O painel Performance se parece com a gravação de uma câmera durante todo o carregamento. Ele não dá uma nota, mas permite voltar ao instante exato em que algo deu errado.

Como abrir e o que aparece primeiro

1. Abra o DevTools: clique com o botão direito na página e escolha Inspecionar, ou pressione Cmd+Option+I no Mac / Ctrl+Shift+I no Windows.
2. Selecione a aba Performance.

Assim que o painel abre, ele mostra o Largest Contentful Paint (LCP) e o Cumulative Layout Shift (CLS) locais. Depois que você interage com a página, ele também mede o Interaction to Next Paint (INP). Portanto, é possível obter uma fotografia local das Core Web Vitals sem iniciar uma gravação.

Como gravar o carregamento

Para acompanhar o carregamento inteiro, marque Screenshots e clique em Start profiling and reload page. O painel recarrega a página e registra tudo. O resultado reúne barras coloridas de scripting, renderização e pintura, uma tira de capturas de tela e uma cascata das solicitações de rede.

A visualização parece densa no começo. Para SEO, um dos usos mais valiosos é bem direto: encontrar o elemento exato que foi considerado o LCP — o maior conteúdo pintado — para saber o que otimizar. A lente Avançado mostra o procedimento.

O erro mais comum

O painel Performance mostra o que o seu Chrome faz, não o que o Googlebot faz. O Googlebot renderiza páginas com o Web Rendering Service, que não é idêntico ao navegador completo do seu computador. O painel é excelente para diagnosticar velocidade e entender renderização, mas não confirma o que o Google consegue rastrear ou indexar. Para isso, use a Inspeção de URL do Search Console.

Na lente Avançado, você encontra o passo a passo do flame chart, da barra lateral Insights, do elemento LCP, do throttling e da comparação com Lighthouse e WebPageTest.

TL;DR — O painel Performance é o profiler local integrado ao Chrome DevTools. A tela inicial mostra LCP e CLS locais em tempo real e, após uma interação, INP. Com Start profiling and reload page e Screenshots ativos, você grava o carregamento completo e analisa flame chart da main thread, FPS/CPU, cascata de rede, Bottom-up, Call Tree, Event Log e a barra Insights. Esta divide o LCP, destaca recursos que bloqueiam a renderização, forced reflow e custo de terceiros. O trace é evidência de lab do seu navegador, não uma gravação do Web Rendering Service do Googlebot. O painel pode sobrepor dados de campo CrUX de usuários reais, mas essa sobreposição não transforma o trace local na mesma medição. O antigo painel independente Performance Insights foi removido no Chrome 132; os recursos agora ficam na aba Insights do painel principal. Os multiplicadores de throttling são relativos à sua máquina, não um benchmark absoluto.

O que o painel Performance realmente é

A documentação do Google o define como a ferramenta para analisar o desempenho de um site e gravar perfis de CPU de aplicações web (documentação do Chrome DevTools). Em outras palavras, é um profiler: você grava um intervalo de atividade do navegador e explora o trace resultante.

Vale diferenciá-lo das ferramentas próximas:

• Lighthouse / PageSpeed Insights executam uma auditoria automatizada e entregam nota e recomendações priorizadas; o PSI também inclui dados de campo CrUX. São automatizados e opinativos.
• WebPageTest testa a página remotamente em dispositivo real, guarda resultados compartilháveis e aceita roteiros com várias etapas.
• Painel Performance entrega um trace bruto e interativo do navegador local, sem nota, conta ou máquina remota. Ele é mais flexível, mas exige interpretação.

O trace gravado é evidência local de lab: uma amostra daquele navegador, dispositivo e rede naquele momento. O painel ao redor do trace, porém, pode mostrar métricas opcionais de campo CrUX ao lado do resultado local. Não confunda lab local, lab remoto e campo de usuários reais; essa distinção sustenta todo o grupo de ferramentas de desempenho web.

Breve história do painel

Elizabeth Sweeny e Paul Irish, da equipe do Chrome DevTools, contam que a ferramenta ajuda desenvolvedores a medir e otimizar desempenho de runtime há quase 15 anos. Ela começou como Timeline e evoluiu para o painel Performance atual (Performance tooling in 2024 and beyond). O Lighthouse surgiu em 2016 para facilitar a descoberta de oportunidades, e o Performance Insights experimental apareceu em 2022 para testar outra forma de apresentar diagnósticos.

Esse último detalhe importa hoje. O painel independente Performance Insights foi descontinuado e removido a partir do Chrome 132. O Google recomenda a aba Performance > Insights (aviso de descontinuação). Tutoriais que ainda mostram um painel separado são anteriores ao Chrome 132.

Abertura e métricas ao vivo

Abra o DevTools e selecione Performance. A tela captura imediatamente LCP e CLS locais e, quando você interage, também INP (visão geral). Rick Viscomi descreveu o redesign como uma página inicial totalmente refeita, com visualização ao vivo das Core Web Vitals locais (Monitor your local and real-user Core Web Vitals in DevTools).

Gravação de trace: runtime ou carregamento

Há dois tipos principais de gravação:

• Desempenho de runtime: a página já carregou e você quer registrar uma animação, interação lenta ou travamento na rolagem. A documentação diferencia explicitamente o funcionamento durante a execução do carregamento inicial (Analyze runtime performance).
• Desempenho de carregamento: você precisa acompanhar uma nova navegação desde o começo. Ative Screenshots e use Start profiling and reload page.

Para investigar LCP, mudanças de layout e scripts que bloqueiam a renderização, normalmente é melhor gravar o carregamento com as capturas de tela ativadas.

O trace contém apenas o que ocorreu dentro da janela gravada. Uma interação fora dela ou trabalho lazy-loaded posterior está sem observação, não comprovadamente ausente. Para repetir ou comparar a captura, anote versão e data do Chrome, throttling de CPU/rede, uso de screenshots e estado da instrumentação avançada de pintura, CSS e amostragem JavaScript. Essas opções aumentam detalhe e overhead; gravações feitas com configurações diferentes não são diretamente comparáveis.

Como ler o trace

Uma gravação apresenta várias trilhas empilhadas:

• Flame chart / Main: mostra a atividade da main thread ao longo do tempo. O eixo horizontal representa a duração; a pilha de barras representa a call stack. Quanto mais larga a barra, mais longa a tarefa. O aninhamento ajuda a formular uma hipótese, mas não prova sozinho que a tarefa-pai causou um problema maior (referência de recursos).
• FPS: uma barra vermelha indica que o frame rate caiu a ponto de provavelmente prejudicar a experiência (documentação de runtime).
• CPU: mostra quanto a main thread esteve ocupada.
• Network: exibe a cascata de todas as solicitações, inclusive recursos no caminho de renderização.
• Timings: expõe medições personalizadas de performance.mark().

Abaixo do flame chart, três abas analisam os mesmos dados por ângulos diferentes:

• Bottom-up: agrega o tempo gasto diretamente por atividade; é útil para saber qual função consumiu mais tempo.
• Call Tree: destaca as atividades-raiz que dispararam mais trabalho.
• Event Log: organiza os eventos em ordem cronológica.

A barra lateral Insights

A adição mais útil do redesign é a barra Insights, sucessora do Performance Insights independente. Em vez de obrigar você a caçar tudo no flame chart, ela apresenta problemas nomeados:

• Divisão do LCP: separa time to first byte, atraso para iniciar a carga do recurso, duração da carga e atraso de renderização do elemento (LCP breakdown).
• Solicitações que bloqueiam a renderização: CSS e JavaScript que atrasam a primeira pintura (render-blocking insight).
• Forced reflow: pontos em que o script força o navegador a recalcular o layout.
• Custo de terceiros: peso de embeds, tags e widgets.

É o recurso do painel que mais se aproxima da experiência “o que devo corrigir?” do Lighthouse, sem esconder o trace que sustenta cada insight. Ainda assim, trate cada indicação como hipótese guiada. Confirme-a no trace e em uma nova gravação antes/depois antes de atribuir causalidade.

Throttling de CPU e rede

Um computador de desenvolvimento costuma ser mais rápido que um celular comum. O throttling simula condições piores por meio de multiplicador de CPU e perfil de rede, como Slow 4G.

A ressalva do Google é que o throttling é relativo à capacidade do computador. A opção 2x faz aquela CPU funcionar duas vezes mais devagar que o normal (referência). Logo, 4x em um notebook rápido não equivale a 4x em uma máquina fraca. É um controle relativo, não um padrão entre dispositivos. O walkthrough da DebugBear também lembra que reduzir a velocidade pode tornar grupos densos de eventos mais legíveis.

Dados de lab versus dados de campo usados no ranking

As métricas ao vivo e as gravações do painel são dados de lab daquela máquina, rede e execução. O sinal de Core Web Vitals usado pelo Google vem de dados de campo CrUX, agregados de usuários reais numa janela móvel de 28 dias e apresentados no Search Console e no PageSpeed Insights. Uma gravação local perfeita não garante aprovação em campo.

O painel redesenhado pode sobrepor dados CrUX aos resultados locais. Quando houver dados, confira se a sobreposição está em nível de URL ou origem, mobile ou desktop, e qual período ela representa. Mesmo com essas dimensões alinhadas, presets inspirados no campo apenas aproximam um segmento: uma execução não recria a distribuição da população nem prevê ranking. Para aprofundar, consulte o hub de ferramentas de desempenho web, Core Web Vitals e CrUX.

Como uso o painel em SEO técnico

Uso o painel Performance quando uma nota não basta e preciso enxergar o mecanismo.

Encontrar o elemento LCP exato. Em minha apresentação Page Experience Update (TMC, junho de 2021), o procedimento é: abra Performance, marque Screenshots, clique em Start profiling and reload page, encontre o LCP no gráfico de timings e clique no nó. O DevTools revela o elemento sinalizado como Largest Contentful Paint. Richie Lauridsen, da Seer Interactive, descreve a mesma técnica ao explicar que passar o cursor sobre o marcador de LCP mostra o conteúdo identificado durante o carregamento (3 Ways to Use Chrome DevTools for SEO Troubleshooting).

Explicar renderização. No meu guia de JavaScript SEO, uso o gráfico de carregamento do painel para tornar visível a sequência de download, parsing de HTML, execução de JavaScript, layout e pintura. Isso ajuda a mostrar que a renderização do Googlebot não executa tudo o que um navegador completo pinta.

Encontrar terceiros bloqueantes e mudanças de layout. A trilha Network e a barra Insights conectam a anomalia visual às solicitações e ao trabalho da main thread. Uma conclusão confiável exige alinhar as trilhas e repetir o cenário.

O mito do Googlebot

A armadilha é concluir que, se a página parece boa no painel, o Googlebot também a vê corretamente. O painel registra o Chrome local completo; o Googlebot usa o Web Rendering Service, com ambiente e comportamento próprios. Use Performance para diagnosticar como o navegador trabalha e a Inspeção de URL para verificar o HTML renderizado e a indexabilidade do Google.

Não confunda com o Performance monitor

O Performance monitor é outro recurso do DevTools: uma faixa de métricas ao vivo, como uso de CPU, heap JavaScript, nós DOM, event listeners e layouts por segundo. Ele é útil para observar vazamentos, mas não grava flame chart, cascata ou timings de Core Web Vitals como o painel Performance.

Resumo de IA

• Definição: o painel Performance é um profiler local integrado ao Chrome DevTools. Ele grava o carregamento ou uma interação e mostra o trace bruto.
• Tela inicial: apresenta LCP e CLS locais e, depois de uma interação, INP.
• Leitura: use Main/flame chart, FPS, CPU, Network, Timings, Bottom-up, Call Tree, Event Log e Insights em conjunto.
• Diagnóstico de LCP: ative Screenshots, grave com reload, encontre o marcador LCP e clique no nó para identificar o elemento.
• Insights: divide o LCP e aponta recursos bloqueantes, forced reflow e custo de terceiros. É uma hipótese a confirmar, não prova automática de causa.
• Lab não é campo: o trace é uma execução local; o ranking usa dados CrUX de usuários reais. O painel pode mostrar uma sobreposição CrUX, mas as medições continuam distintas.
• Não é Googlebot: o trace representa o seu Chrome, não o Web Rendering Service.
• Atualidade: o Performance Insights independente foi removido no Chrome 132; seus recursos passaram para a aba Insights.
• Throttling: os multiplicadores dependem da máquina e não formam um benchmark absoluto entre computadores.

Documentação oficial

Fontes primárias da equipe do Chrome DevTools:

Chrome / Google

• Visão geral do painel Performance — abertura, métricas ao vivo e fluxo principal.
• Analisar desempenho de runtime — gravação, flame chart e FPS/CPU.
• Referência de recursos — trilhas, abas e controles.
• Insights de desempenho — diagnósticos incorporados ao painel.
• Aviso do antigo Performance Insights — descontinuação do painel separado no Chrome 132.
• Performance monitor — documentação do monitor de métricas ao vivo, que é um recurso diferente.
• Performance tooling in 2024 and beyond — história e direção do produto.
• Core Web Vitals locais e de usuários reais no DevTools — redesign e sobreposição CrUX.
• A 400% faster Performance panel — detalhes de engenharia e evolução ativa do painel.

Bing / Microsoft

• Ferramentas Performance no Microsoft Edge DevTools — fluxo equivalente no Edge baseado em Chromium.

Citações das fontes

As fontes registradas descrevem o painel como um profiler para analisar desempenho e gravar perfis de CPU. A documentação orienta usar a trilha Main para a atividade da thread principal e associa barras vermelhas de FPS a quedas capazes de prejudicar a experiência.

Elizabeth Sweeny e Paul Irish registram que o painel existe, em alguma forma, há quase 15 anos e evoluiu do antigo Timeline. O aviso oficial informa que o Performance Insights separado foi removido a partir do Chrome 132 e direciona para Performance > Insights. Rick Viscomi descreve a tela redesenhada como uma visão ao vivo das Core Web Vitals locais.

Na prática de SEO, Richie Lauridsen explica que o marcador LCP permite ver o conteúdo identificado como Largest Contentful Paint. Em meu guia de JavaScript SEO, uso o gráfico de carregamento da aba Performance para explicar a diferença entre a renderização do Googlebot e a pintura de um navegador completo.

Links para os trechos e registros originais:

• Definição e visão geral
• Flame chart, Main e FPS
• História do painel
• Aviso do Chrome 132
• Post de Rick Viscomi
• Técnica de LCP de Richie Lauridsen
• Meu guia de JavaScript SEO

Qual ferramenta de desempenho devo usar?

Você precisa de nota ou diagnóstico?

• Para uma nota ou veredito de aprovação com impacto de ranking, use dados de campo: PageSpeed Insights ou o relatório Core Web Vitals do Search Console.
• Para entender por que a página está lenta, continue com o painel Performance.

A página está acessível publicamente?

• Se estiver atrás de login, em staging ou localhost, use Performance ou Lighthouse no DevTools; PSI e WebPageTest exigem URL pública.
• Se estiver pública, tanto o painel quanto uma ferramenta remota podem ajudar.

Você precisa de resultado compartilhável, repetível e em dispositivo real?

• Sim: use WebPageTest.
• Não, preciso ver o mecanismo agora: use o painel Performance.

O que você procura?

• Elemento LCP: Screenshots → Start profiling and reload page → marcador LCP → nó.
• Recurso que bloqueia a pintura ou terceiro caro: Performance → Insights e Network.
• Lista priorizada de correções: Lighthouse ou PageSpeed Insights.
• O que o Googlebot rastreia/renderiza: use Inspeção de URL, não este painel.

Regra prática: ferramentas de campo dizem se há um problema e quão disseminado ele é; o painel Performance ajuda a explicar por que, até a função, solicitação ou elemento responsável.

Folha de consulta do painel Performance

Receita do elemento LCP: ative Screenshots, grave com reload, encontre LCP no gráfico de timings e clique no nó.

Não se engane: o trace é local e de lab; pode haver CrUX ao lado, mas o ranking usa campo. O painel representa seu navegador, não o Googlebot. Performance Insights separado acabou no Chrome 132. Throttling é relativo à máquina. O recurso é grátis, não exige conta e também existe no Edge Chromium. Performance monitor é outra ferramenta.

Checklist de uma análise no painel Performance

• Teste em janela anônima e sem extensões para reduzir ruído na main thread.
• Ative Screenshots antes de gravar o carregamento.
• Registre versão/data do Chrome, throttling e instrumentação avançada para tornar as execuções comparáveis.
• Para desempenho de carga, use Start profiling and reload page.
• Aplique throttling de CPU e rede quando fizer sentido, lembrando que o multiplicador de CPU depende da máquina.
• Faça várias gravações; uma execução local é apenas uma amostra.
• Leia primeiro a divisão do LCP na barra Insights.
• Clique no nó de LCP para confirmar o elemento exato.
• Verifique CSS/JS bloqueante e terceiros pesados em Network.
• Compare o diagnóstico com dados de campo do PSI ou Search Console.
• Para rastreamento e indexação, mude para a Inspeção de URL.

O painel Performance e as ferramentas ao redor

• Chrome DevTools Performance: trace local e bruto; ideal para explicar a lentidão e localizar o elemento LCP.
• Lighthouse: auditoria automatizada e pontuada, também disponível no DevTools.
• PageSpeed Insights: dados CrUX de campo e auditoria Lighthouse de lab para URLs públicas.
• Chrome UX Report (CrUX): conjunto de dados de usuários reais usado pelo Google; pode aparecer sobreposto no painel.
• WebPageTest: testes remotos em dispositivos reais, resultados compartilháveis e scripts.
• Search Console — Core Web Vitals: grupos de páginas com falha em escala.
• Search Console — Inspeção de URL: ferramenta correta para verificar o que o Googlebot rastreia e renderiza.
• Microsoft Edge DevTools: painel Chromium equivalente para fluxos no Edge.

Veja o conjunto completo no hub de ferramentas de desempenho web. Para entender por que essa ferramenta não substitui o diagnóstico de rastreamento, consulte também o guia de rastreamento.

Erros que desperdiçam uma gravação

Tratar um trace como verdade de campo

Uma gravação representa um navegador, dispositivo, perfil de rede, estado de cache e jornada. Use-a para explicar o gargalo e CrUX ou RUM para medir sua frequência.

Gravar sem interação reproduzível

Um trace aberto acumula atividade sem relação com o problema. Defina a carga ou interação, comece sempre do mesmo estado e grave apenas a janela necessária.

Ler o flame chart sem Network e Frames

Uma long task pode ser consequência, não a causa inicial. Alinhe trabalho da main thread a solicitações, interações, screenshots e pinturas antes de atribuir origem.

Chamar throttling pesado de benchmark

O throttling expõe gargalos, mas produz um cenário de lab. Mantenha as configurações idênticas no antes/depois e identifique-as ao compartilhar o resultado.

Como corrigir problemas comuns do painel

O trace tem ruído demais

Causa provável: extensões, abas em segundo plano ou gravação longa adicionam trabalho irrelevante. Correção: use um perfil limpo, feche a atividade paralela e capture uma jornada definida. Confirmação: a carga ou interação relevante ocupa um intervalo curto e reconhecível.

A interação parece lenta, mas nenhum evento é óbvio

Causa provável: a gravação não incluiu toda a janela entre input e pintura, ou a trilha errada está expandida. Correção: repita exatamente o clique, toque ou tecla e inspecione Interactions e a main thread. Confirmação: o evento revela input delay, processamento e apresentação.

O resultado varia muito entre execuções

Causa provável: cache, rede, trabalho em segundo plano ou configuração mudaram. Correção: padronize reload, throttling, viewport e jornada e execute várias vezes. Confirmação: o mesmo gargalo aparece mesmo quando a duração total varia.

O lab está bom, mas o Search Console está ruim

Causa provável: o trace local não representa os usuários ou jornadas longas. Correção: segmente CrUX ou RUM, reproduza o dispositivo e a interação afetados e use o painel para diagnosticar. Confirmação: o trace explica o segmento lento, em vez de tentar invalidar o agregado de campo.

Como provar que uma correção baseada no trace funcionou

Teste de jornada repetida

Teste: grave a mesma carga ou interação com cache, viewport e throttling idênticos antes e depois. Esperado: a solicitação, tarefa ou fase de renderização alvo diminui de forma consistente. Falha: a variação ou outro gargalo explica o resultado. Janela: imediatamente, em várias gravações. Rollback: erros, trabalho ausente ou piora visual.

Teste de main thread

Teste: compare a tarefa selecionada e seus filhos nos dois traces. Esperado: o trabalho removido ou adiado sai do intervalo crítico, em vez de apenas mudar de nome ou posição. Falha: o mesmo custo foi deslocado. Janela: imediata. Rollback: aumento do bloqueio total em torno da ação.

Repasse para dados de campo

Teste: monitore o template ou a interação em RUM depois da melhora de lab. Esperado: métrica e atribuição melhoram no segmento pretendido. Falha: o cenário local não era representativo. Janela: RUM conforme o tráfego chega; CrUX ao longo da janela móvel. Rollback: piora consistente do desempenho ou da conclusão da tarefa em campo.

Teste seus conhecimentos: painel Performance do Chrome DevTools

Recursos recomendados

Meus textos

• JavaScript SEO: o que você precisa saber — usa o gráfico da aba Performance para explicar a renderização do Googlebot.
• Google PageSpeed Insights para SEOs e desenvolvedores — complemento pontuado, com campo e lab, para o trace bruto.
• Guia de SEO técnico para iniciantes — contexto de desempenho e renderização.

Minhas apresentações

• Page Experience Update (TMC, junho de 2021) — procedimento para ver o elemento LCP no DevTools.
• What’s Next for Page Experience (SMX Next 2021) — apresentação sobre experiência de página.

Fontes da indústria

• Visão geral do painel Performance — ponto de partida oficial.
• Analisar desempenho de runtime — gravação, flame chart e FPS/CPU.
• Core Web Vitals locais e reais no DevTools — redesign e CrUX.
• Performance tooling in 2024 and beyond — história e relação com Lighthouse/Insights.
• 3 Ways to Use Chrome DevTools for SEO Troubleshooting — aplicação em SEO e técnica do LCP.
• Profile Site Speed With The DevTools Performance Tab — análise técnica de forced reflow, layers e throttling.
• Chrome DevTools for Debugging Web Performance — fluxo atualizado após o redesign.

Registro de alterações