Painel Performance do Chrome DevTools

TL;DR — O painel Performance é uma ferramenta integrada ao Chrome (abra o DevTools e clique em Performance) que registra exatamente o que seu navegador faz enquanto uma página carrega — cada script, cada requisição de rede, cada pintura. Ao contrário do PageSpeed Insights, ele não fornece uma pontuação; entrega a imagem bruta para você descobrir por que uma página está lenta. Importante: ele mostra o que seu navegador faz, não o que o crawler do Google faz, e é gratuito, sem exigir conta.

O que é

O Chrome DevTools tem muitas abas. O painel Performance é o usado para registrar como uma página carrega e executa, e depois investigar os detalhes. Ele captura o trabalho do seu navegador ao longo do tempo — baixar arquivos, executar JavaScript, calcular layout e pintar a página — e organiza tudo como uma linha do tempo na qual você pode aplicar zoom.

Pense na diferença assim. PageSpeed Insights e Lighthouse são como um boletim: executam um teste e entregam uma pontuação com uma lista de tarefas. O painel Performance é como uma gravação de câmera de segurança de todo o carregamento — sem pontuação, mas com a possibilidade de voltar e ver o momento exato em que algo deu errado.

Como abri-lo e o que aparece primeiro

1. Abra o DevTools (clique com o botão direito na página → Inspect ou pressione Cmd+Option+I no Mac / Ctrl+Shift+I no Windows).
2. Clique na aba Performance no topo.

Assim que você o abre, o painel já mostra o Largest Contentful Paint (LCP) e o Cumulative Layout Shift (CLS) da página — duas das três Core Web Vitals — medidos ao vivo no seu próprio navegador. Interaja com a página e ele também captura o Interaction to Next Paint (INP). Você obtém um retrato das Core Web Vitals locais sem gravar nada.

Gravando o carregamento de uma página

Para ver a história completa de um carregamento, clique em Start profiling and reload page (ative primeiro a caixa Screenshots para obter também uma tira de imagens mostrando como a página parecia em cada momento). O painel recarrega a página e registra tudo. Quando para, você recebe uma linha do tempo densa: barras coloridas de scripting, rendering e painting; uma tira de capturas no topo; e uma seção de rede mostrando o que carregou e quando.

Na primeira vez, isso parece intimidador. A tarefa que leva a maioria dos profissionais de SEO ao painel é simples, e vou percorrê-la na aba Advanced: encontrar o elemento exato que foi seu LCP — a maior coisa que a página pintou — para saber o que otimizar.

O erro que as pessoas cometem

O painel Performance mostra o que seu navegador Chrome faz — não o que o Googlebot faz. O Googlebot renderiza páginas com seu próprio sistema (o Web Rendering Service), que não é idêntico ao navegador desktop completo. Portanto, o painel é excelente para diagnosticar velocidade e entender renderização, mas não é uma forma de confirmar o que o Google consegue rastrear e indexar. Para isso, use a ferramenta URL Inspection do Google Search Console.

Quer o passo a passo completo — leitura do flame chart, a barra lateral Insights, localização do elemento LCP, throttling para simular um celular lento e comparação com Lighthouse e WebPageTest? Mude para a aba Advanced.

TL;DR — O painel Performance é o profiler local integrado ao Chrome DevTools. Abra-o e ele mostrará LCP/CLS locais ao vivo (e INP depois que você interagir); clique em Start profiling and reload page (com Screenshots ativado) para registrar um carregamento completo. Você lê um flame chart do trabalho na main thread, uma linha do tempo de FPS/CPU, um waterfall de rede e abas de análise (Bottom-up, Call Tree, Event Log), além de uma barra lateral Insights que divide o LCP em suas quatro partes e sinaliza requisições que bloqueiam a renderização, forced reflow e custo de terceiros. É a forma integrada mais rápida de localizar seu elemento LCP exato. Três pontos para manter separados: ele faz o profiling do seu navegador, não do Web Rendering Service do Googlebot; o trace gravado é evidência de lab e, embora o painel possa mostrar opcionalmente dados de campo CrUX de usuários reais ao lado, essa sobreposição não é a mesma medição que seu trace local; e o antigo painel independente Performance Insights foi removido no Chrome 132 — esses recursos agora vivem na aba Insights deste painel. Os multiplicadores de throttling são relativos à sua máquina, não um benchmark absoluto.

O que o painel Performance realmente é

O enquadramento do Google é direto: “Use the Performance panel to analyze your website’s performance” e “The Performance panel lets you record CPU performance profiles of your web applications” (documentação do Chrome DevTools). É um profiler — você grava um trace de tudo que o navegador faz durante um intervalo, e depois explora esse trace.

Vale posicioná-lo diante dos seus equivalentes logo no início, porque as pessoas os confundem o tempo todo:

• Lighthouse / PageSpeed Insights executam uma auditoria automatizada e fornecem uma pontuação com recomendações priorizadas (o PSI também acrescenta dados de campo CrUX reais). São automatizados, pontuados e opinativos.
• WebPageTest executa sua página em um dispositivo real remoto, registra resultados históricos e compartilháveis e aceita scripts de várias etapas. É remoto, compartilhável e completo.
• O painel Performance fornece um trace bruto e interativo do seu próprio navegador local — sem pontuação, sem conta e sem máquina remota. É mais profundo e flexível, mas a interpretação fica por sua conta.

O trace gravado em si é evidência local de lab — um retrato do seu navegador, dispositivo e rede naquele momento. Mas o painel ao redor não é puramente uma ferramenta de lab: desde o redesign, ele também pode mostrar métricas de campo CrUX opcionais de usuários reais junto dos resultados locais. Mantenha os três conceitos separados — lab local, lab remoto e campo de usuários reais — porque essa distinção é a espinha dorsal de todo o cluster de ferramentas de performance web e é o que sustenta os mitos abaixo.

Uma breve história (para você saber qual painel está vendo)

O painel existe há muito tempo. Elizabeth Sweeny e Paul Irish, da equipe do Chrome DevTools, resumiram assim: “The Performance panel in Chrome DevTools has been helping developers measure and optimize their runtime performance in one form or another for the better part of 15 years,” e “Starting with a panel called ‘Timeline’, it evolved to the Performance panel you know today” (Performance tooling in 2024 and beyond). Ao longo do caminho, como eles observam, “Lighthouse was launched in 2016 to help spot optimization opportunities more easily,” e “The experimental Performance Insights panel was released in 2022 to test new ways of surfacing performance insights.”

Essa última informação importa para manter o conteúdo atual. O painel independente Performance Insights era um experimento e desapareceu: o aviso do próprio Google afirma que “The Performance insights panel is deprecated and removed from DevTools starting with Chrome version 132. We recommend you use the Performance > Insights tab instead” (aviso de descontinuação). Se um tutorial ou captura de tela mostra um painel separado chamado “Performance Insights”, ele é anterior ao Chrome 132 e está desatualizado — os insights agora ficam em uma barra lateral dentro do painel Performance comum.

Abrindo o painel e a tela de métricas ao vivo

Abra o DevTools e selecione Performance nas abas do topo. Como o Google descreve, “When you open the Performance panel, it immediately captures and shows you your local Largest Contentful Paint (LCP) and Cumulative Layout Shift (CLS) metrics,” e “If you interact with your page, the Performance panel also captures your local Interaction to Next Paint (INP)” (documentação de visão geral). Essa tela inicial faz parte do redesign que Rick Viscomi descreveu como “a completely redesigned Performance panel landing page featuring a live view of your local Core Web Vitals performance” (Monitor your local and real-user Core Web Vitals in DevTools). Portanto, antes de registrar qualquer coisa, você já tem o conjunto completo das Core Web Vitals locais.

Gravando um trace: runtime versus load

Há duas coisas que você pode registrar, e a distinção importa:

• Runtime performance — a página já está carregada e você quer fazer profiling enquanto ela executa (uma animação, uma interação lenta ou um scroll com jank). O Google define: “Runtime performance is how your page performs when it is running, as opposed to loading” (Analyze runtime performance).
• Load performance — você quer a história completa a partir de uma navegação nova. Clique em Start profiling and reload page. Ative Screenshots primeiro para obter uma tira de quadros visuais junto do trace.

Para trabalho de SEO — LCP, layout shift e scripts que bloqueiam a renderização — quase sempre você quer a gravação do carregamento com as capturas de tela ativadas.

Um trace contém apenas o que aconteceu dentro da sua janela de gravação — tudo que você não capturou (uma interação fora da janela ou trabalho lazy-loaded que dispara depois) fica simplesmente não observado, não ausente. Se quiser um trace que você ou outra pessoa possa reproduzir ou comparar mais tarde, anote: a versão do Chrome e a data (rótulos, atalhos e a mudança exata de interface variam a cada release), se as capturas de tela estavam ativadas, suas configurações de throttling de CPU/rede e se você deixou nos padrões as opções avançadas de instrumentação de paint/CSS e amostragem de JavaScript — cada uma acrescenta detalhe e sobrecarga, portanto um trace gravado com configurações diferentes não é diretamente comparável a outro gravado sem elas.

Lendo o trace

Uma gravação fornece várias trilhas empilhadas. As principais são:

• Flame chart / trilha Main. Este é o centro de tudo. O Google diz: “DevTools shows you a flame chart of activity on the main thread, over time. The x-axis represents the recording, over time,” e “Use the Main track to view activity that occurred on the page’s main thread” (referência de recursos). O tempo corre da esquerda para a direita; a pilha de barras sob cada momento é a call stack. Uma barra mais larga = uma tarefa mais longa — foi ali que seu tempo foi gasto. Esse aninhamento mostra a estrutura do trace — quem chamou quem e quando —, mas não prova por si só que uma tarefa-pai causou um problema mais amplo na experiência do usuário; trate-o como ponto de partida para uma hipótese e confirme depois.
• Gráfico de FPS. Uma leitura rápida de jank. O Google diz: “Whenever you see a red bar above FPS, it means that the framerate dropped so low that it’s probably harming the user experience” (documentação de runtime). O objetivo é obter 60 FPS estáveis; as barras vermelhas marcam os pontos problemáticos.
• Gráfico de CPU mostra quão ocupada ficou a main thread durante a gravação.
• Trilha Network é um waterfall de cada requisição — o que carregou, quando e em qual ordem (é ali que aparecem os recursos que bloqueiam a renderização).
• Trilha Timings mostra medições personalizadas de performance.mark() se seu aplicativo as emitir.

Abaixo do flame chart, três abas de análise mostram os mesmos dados de formas diferentes:

• Bottom-up — “Use the Bottom-up tab to view which activities directly took up the most time in aggregate.” É melhor para responder: “qual função sozinha está consumindo meu tempo?”
• Call tree — “Use the Call tree tab to view which root activities cause the most work.” É melhor para responder: “qual tarefa de nível superior iniciou tudo isso?”
• Event log — os mesmos eventos em ordem cronológica.

A barra lateral Insights

A adição mais útil do redesign para diagnóstico é a barra lateral Insights — sucessora do painel independente Performance Insights, que foi removido. Em vez de fazer você procurar pelo flame chart, ela apresenta problemas específicos e nomeados. Os mais importantes para SEO:

• LCP breakdown. O Google divide o LCP em quatro partes — tempo até o primeiro byte, atraso no carregamento do recurso, tempo de carregamento do recurso e atraso na renderização do elemento (insight de LCP breakdown). Isso informa por que seu LCP está lento (servidor? imagem carregada tarde? bloqueio de renderização?), e não apenas que está lento.
• Render-blocking requests — o CSS/JS que atrasou a primeira pintura (insight de render-blocking).
• Forced reflow — o ponto em que o navegador precisou pausar o script para recalcular o layout.
• Third-party cost — quanto seus embeds, tags e widgets estão custando.

Como esses itens são apresentados automaticamente, a barra lateral Insights é o mais próximo que o painel Performance chega da experiência “aqui está o que corrigir” do Lighthouse — embora ainda permita entrar no trace bruto por trás de cada insight.

Trate cada insight como uma hipótese orientada, não como prova. Ele identifica um possível problema e leva você ao contexto correspondente no trace, mas sinalizar um item não é o mesmo que provar que ele causou o resultado que você está investigando, ou que corrigi-lo vai resolver o resultado. Confirme com o próprio trace — e com uma nova gravação antes/depois — antes de dizer a um cliente ou colega que um insight é a causa.

Throttling de CPU e rede (e a ressalva que confunde as pessoas)

Sua máquina de desenvolvimento é muito mais rápida que um celular típico, então uma página que parece instantânea para você pode ser dolorosa para usuários reais. O throttling simula condições mais fracas: um multiplicador de redução da CPU e um perfil de rede (Slow 4G etc.).

A ressalva, diretamente do Google: “Throttling is relative to your computer’s capabilities. For example, the 2x slowdown option makes your CPU operate 2 times slower than its usual ability” (referência de recursos). Isso significa que uma “redução de 4x” não é um benchmark absoluto — 4x em um laptop rápido e 4x em um aparelho fraco não produzem o mesmo resultado. É um controle relativo, não um padrão comparável entre máquinas. Um segundo uso prático apontado pela DebugBear em seu passo a passo aprofundado de DevTools é simplesmente desacelerar a gravação para que aglomerados densos de eventos fiquem legíveis.

Dados de lab aqui versus dados de campo usados pelo Google no ranking

É aqui que profissionais de SEO se confundem. Os números do painel Performance — as métricas ao vivo e cada gravação — são dados de lab da sua máquina, na sua rede, naquele momento. O sinal real de Core Web Vitals usado pelo Google no ranking vem dos dados de campo CrUX de usuários reais (uma agregação de 28 dias de usuários reais do Chrome), que você vê no Search Console e no PageSpeed Insights. Uma gravação local perfeita não garante uma pontuação de campo aprovada — usuários reais têm dispositivos mais lentos, redes piores e muito mais variedade que o seu único teste.

O painel redesenhado faz justamente essa ponte: desde a atualização, ele pode mostrar seus dados de campo CrUX de usuários reais ao lado dos resultados locais, permitindo comparar “o que acabei de medir” com “o que usuários reais experimentam”. Quando essa sobreposição de campo está disponível, você pode alterná-la entre o nível da URL e da origem, entre mobile e desktop, e a interface informa o período de dados usado — portanto alinhe esses parâmetros ao trace que está comparando. Mesmo assim, configurações de ambiente informadas pelo campo (presets de throttling que o painel recomenda com base no CrUX) aproximam um segmento selecionado de usuários reais; uma única gravação local ainda não recria a distribuição da população subjacente nem prevê um resultado de ranking. Essa sobreposição é o lembrete integrado mais claro de que seu trace local e o sinal de ranking do Google são dois números diferentes. Para o tratamento completo de lab versus campo, consulte o hub de ferramentas de performance web e os explicadores irmãos de Core Web Vitals e CrUX.

Como uso o painel para SEO técnico

Uso o painel Performance há anos — não como um entregável isolado, mas como a ferramenta que procuro quando uma pontuação não basta e preciso enxergar a mecânica real. Alguns usos concretos:

Encontrar o elemento LCP exato. Este é o truque de SEO mais valioso do painel e é uma receita que ensino em palestras. No meu deck Page Experience Update (TMC, June 2021), os passos são: Performance > marque “Screenshots”, clique em “Start profiling and reload page”, encontre LCP no gráfico de timings e então clique no nó — este é o elemento do LCP. O DevTools informa precisamente qual elemento o Google contaria como seu Largest Contentful Paint, para você saber exatamente o que otimizar. Richie Lauridsen, da Seer Interactive, descreve a mesma técnica no Search Engine Journal: “In hovering over the flag for LCP, we can actually see the piece of content flagged to be the largest contentful paint during the page load” (3 Ways to Use Chrome DevTools for SEO Troubleshooting). O fato de duas fontes independentes chegarem à mesma receita mostra que este é um fluxo padrão, não um caso isolado.

Explicar renderização para outras pessoas. No meu guia de JavaScript SEO uso o painel para tornar visível o pipeline de renderização: “In Chrome Dev Tools, if you run a test on the ‘Performance’ tab, you get a loading chart.” Percorrer esse gráfico — download, parse de HTML, execução de JS, layout e pintura — é como explico a clientes e colegas que a renderização do Googlebot não faz tudo que uma pintura completa do navegador faz, o que é central para diagnosticar problemas de JS SEO.

Encontrar terceiros que bloqueiam a renderização e diagnosticar layout shift completam o quadro: o waterfall de rede mostra o que está segurando a primeira pintura, e o trace (junto com a métrica CLS) mostra o que mudou e quando.

O mito do Googlebot (o que você realmente precisa internalizar)

Esta é a armadilha: “if it looks fine in my Performance panel, Googlebot sees it fine too.” Não é assim. O painel faz profiling do seu Chrome local e completo. O Googlebot renderiza com o Web Rendering Service, uma build de Chromium recente, mas não idêntica, que não oferece tudo que um navegador completo oferece e se comporta de modo diferente (é stateless, nega prompts de permissão e assim por diante — consulte crawling and rendering). O painel Performance é excelente para entender e diagnosticar o comportamento de renderização; não substitui a confirmação do que é realmente rastreável e indexável. Para isso, use a ferramenta URL Inspection do Search Console ou uma requisição bruta.

Uma nota rápida para não confundir

Não confunda o painel Performance com o Performance monitor — um recurso separado e menor do DevTools que mostra uma faixa ao vivo de métricas em tempo real (uso de CPU, heap de JS e nós DOM), em vez de um trace gravado. Mesmo termo, ferramenta diferente.

Resumo de IA

Uma síntese da versão Advanced:

• O que é: o painel Performance do Chrome DevTools é um profiler local integrado. Abra DevTools → Performance. Ele registra como uma página carrega e executa; não produz uma pontuação. O trace gravado é evidência local de lab, embora o painel possa mostrar opcionalmente dados de campo CrUX ao lado.
• Posicionamento: Lighthouse/PageSpeed Insights = auditoria automatizada pontuada (+ dados de campo CrUX); WebPageTest = lab remoto em dispositivo real; painel Performance = trace bruto e interativo do seu próprio navegador.
• Métricas ao vivo: ao abrir, mostra LCP e CLS locais; interagir acrescenta INP local — Core Web Vitals locais completas sem gravar.
• Gravação: runtime (página já executando) versus load (Start profiling and reload page, com Screenshots ativado para uma tira de imagens).
• Leitura do trace: flame chart do trabalho na main thread (barra mais larga = tarefa mais longa), gráfico de FPS (vermelho = jank, alvo de 60 FPS), gráfico de CPU, waterfall de Network e Timings; além das abas de análise Bottom-up / Call Tree / Event Log.
• Barra lateral Insights (substituiu o painel independente Performance Insights, removido no Chrome 132): divisão do LCP em quatro partes, requisições que bloqueiam a renderização, forced reflow e custo de terceiros. Trate cada insight como uma hipótese orientada, não como prova da causa — confirme com o trace e com uma nova gravação antes/depois.
• Throttling é relativo à sua máquina, não um benchmark absoluto — “4x” em um laptop rápido ≠ “4x” em um fraco.
• Lab ≠ campo: o trace gravado é dado de lab; o Google ranqueia com dados de campo CrUX de usuários reais. O redesign pode mostrar CrUX ao lado dos resultados locais (alinhado por URL/origem, fator de forma e período) — uma aproximação de um segmento real, não uma recriação dele.
• Usos de SEO: localizar o elemento LCP exato (receita dos slides de Patrick, corroborada por Richie Lauridsen no SEJ), encontrar terceiros que bloqueiam a renderização, diagnosticar layout shift e explicar renderização.
• Mito a desfazer: ele mostra o seu navegador, não o Web Rendering Service do Googlebot — confirme a rastreabilidade com URL Inspection, não com o DevTools.

Documentação oficial

Documentação de fonte primária da equipe do Chrome DevTools.

Chrome / Google

• Performance panel overview — o que é, como abri-lo e as métricas LCP/CLS/INP locais ao vivo.
• Analyze runtime performance — gravação, flame chart, FPS/CPU e a distinção entre runtime e load.
• Performance features reference — definições das trilhas Main, Bottom-up, Call Tree, Event Log e de throttling.
• Performance insights (deprecation notice) — o painel independente foi removido no Chrome 132; use Performance > Insights.
• LCP breakdown insight — LCP dividido em TTFB, atraso do recurso, tempo de carregamento do recurso e atraso de renderização do elemento.
• Render-blocking requests insight — identificação do CSS/JS que atrasa a primeira pintura.
• Monitor your local and real-user Core Web Vitals in DevTools — Rick Viscomi sobre a tela inicial redesenhada e a sobreposição de dados de campo CrUX.
• Performance tooling in 2024 and beyond — Elizabeth Sweeny e Paul Irish sobre a história Timeline → Performance e o lugar de Lighthouse/Insights.
• A 400% faster Performance panel — aprofundamento de engenharia; evidência de que o painel continua recebendo investimento e muda a cada release.
• Performance monitor — a faixa separada de métricas em tempo real, não o painel Performance principal (nota de desambiguação).

Bing / Microsoft

• Não existe documentação específica do Bing sobre o painel Performance do Chrome/Edge DevTools — esta é uma ferramenta de navegador, não um produto de mecanismo de busca. O Edge baseado em Chromium oferece um DevTools quase idêntico, com o mesmo painel Performance, então tudo aqui também se aplica a ele.

Citações da fonte

Declarações registradas da equipe do Chrome DevTools e de profissionais do setor. Cada link do Chrome é um deep link que salta para o trecho citado.

Chrome DevTools — o que é o painel e como lê-lo

• “Use the Performance panel to analyze your website’s performance.” / “The Performance panel lets you record CPU performance profiles of your web applications.” — documentação do Chrome DevTools. Ir para a citação
• “When you open the Performance panel, it immediately captures and shows you your local Largest Contentful Paint (LCP) and Cumulative Layout Shift (CLS) metrics.” / “If you interact with your page, the Performance panel also captures your local Interaction to Next Paint (INP).” Ir para a citação
• “Runtime performance is how your page performs when it is running, as opposed to loading.” / “DevTools shows you a flame chart of activity on the main thread, over time. The x-axis represents the recording, over time.” Ir para a citação
• “Whenever you see a red bar above FPS, it means that the framerate dropped so low that it’s probably harming the user experience.” Ir para a citação
• “Use the Main track to view activity that occurred on the page’s main thread.” / “Use the Bottom-up tab to view which activities directly took up the most time in aggregate.” / “Use the Call tree tab to view which root activities cause the most work.” Ir para a citação
• “Throttling is relative to your computer’s capabilities. For example, the 2x slowdown option makes your CPU operate 2 times slower than its usual ability.” Ir para a citação

Chrome DevTools — história e nota de atualização

• “The Performance panel in Chrome DevTools has been helping developers measure and optimize their runtime performance in one form or another for the better part of 15 years.” / “Starting with a panel called ‘Timeline’, it evolved to the Performance panel you know today.” — Elizabeth Sweeny e Paul Irish, equipe do Chrome DevTools. Ir para a citação
• “The Performance insights panel is deprecated and removed from DevTools starting with Chrome version 132. We recommend you use the Performance > Insights tab instead.” Ir para a citação
• “a completely redesigned Performance panel landing page featuring a live view of your local Core Web Vitals performance.” — Rick Viscomi, equipe do Chrome. Ler a publicação

Setor — o fluxo de trabalho de SEO

• “In hovering over the flag for LCP, we can actually see the piece of content flagged to be the largest contentful paint during the page load.” — Richie Lauridsen (Seer Interactive), Search Engine Journal. Ler o artigo

Patrick Stox — usando o painel

• “In Chrome Dev Tools, if you run a test on the ‘Performance’ tab, you get a loading chart.” — usado no meu guia de JavaScript SEO da Ahrefs para explicar como a renderização do Googlebot difere de uma pintura completa do navegador.

Qual ferramenta de performance devo escolher?

O painel é uma opção entre várias, e escolher a ferramenta errada desperdiça tempo. Uma forma rápida de decidir:

Você precisa de uma pontuação ou de um diagnóstico?

• Uma pontuação / veredito de aprovação-reprovação para ranking → você quer dados de campo: PageSpeed Insights ou o relatório Core Web Vitals do Search Console (CrUX). O painel Performance não fornece isso.
• Um diagnóstico de por que uma página está lenta → continue.

A página pode ser acessada publicamente?

• Não (atrás de login, staging ou localhost) → o painel Performance (ou Lighthouse no DevTools) é sua ferramenta — ele executa o que estiver no seu navegador. PSI e WebPageTest precisam de uma URL pública.
• Sim → tanto o painel Performance quanto uma ferramenta remota funcionam; continue.

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

• Sim (relatório para cliente, hardware real, tendência histórica) → WebPageTest.
• Não — você só precisa ver a mecânica agora → o painel Performance.

O que exatamente você está tentando encontrar?

• “Qual elemento é meu LCP?” → painel Performance: ative Screenshots → Start profiling and reload → clique no nó LCP no gráfico de timings.
• “O que está bloqueando minha primeira pintura / consumindo tempo de terceiros?” → painel Performance → barra lateral Insights (requisições que bloqueiam a renderização, custo de terceiros).
• “Uma lista priorizada de correções?” → Lighthouse / PageSpeed Insights.
• “O que o Googlebot realmente consegue rastrear/renderizar?” → não é este painel — use a ferramenta URL Inspection do Search Console.

Regra prática: as ferramentas de campo informam se você tem um problema e se ele afeta o ranking; o painel Performance informa por quê — até a função, requisição e elemento exatos.

Folha de consulta rápida do painel Performance

Como entrar

Lendo um trace

Encontre seu elemento LCP (a receita de SEO)

1. Ative Screenshots.
2. Clique em Start profiling and reload page.
3. Encontre LCP marcado no gráfico de timings.
4. Clique no nó — o DevTools mostra o elemento LCP exato.

Fatos rápidos / não caia nessas armadilhas

• O trace gravado é dado local de lab — não são os dados de campo CrUX nos quais o Google baseia o ranking, embora o painel possa mostrar dados de campo ao lado.
• Ele faz profiling do seu navegador — não do Web Rendering Service do Googlebot.
• O painel independente Performance Insights foi removido no Chrome 132; os insights agora vivem na aba Insights deste painel.
• Os multiplicadores de throttling são relativos à sua máquina, não um benchmark absoluto.
• Gratuito, integrado e sem conta — e o mesmo painel existe no Chromium Edge.
• O Performance monitor é um recurso diferente (faixa de métricas ao vivo), não este painel.

Uma rodada de profiling do painel Performance

Como obter uma gravação limpa e útil:

• Teste em uma janela Incognito com as extensões desativadas (extensões poluem o trace da main thread).
• Ative Screenshots antes de gravar um carregamento, para obter uma tira de imagens.
• Anote a versão do Chrome, a data, as configurações de throttling e se a instrumentação avançada de paint/CSS/amostragem está ativa — assim a gravação fica reproduzível e comparável com uma posterior.
• Use Start profiling and reload page para uma história de carregamento completo (não apenas Record em uma página já carregada) ao diagnosticar performance de load.
• Aplique CPU throttling (comumente 4x) e network throttling para aproximar um celular intermediário — lembrando que o multiplicador é relativo à sua máquina.
• Grave algumas vezes; gravações locais variam, então trate uma execução como amostra, não como verdade absoluta.
• Abra a barra lateral Insights e leia primeiro o LCP breakdown — ele aponta para causas de servidor, carregamento do recurso ou atraso de renderização.
• Use a receita para clicar no nó LCP e confirmar o elemento LCP real.
• Verifique a trilha Network em busca de CSS/JS que bloqueiam a renderização e requisições pesadas de terceiros.
• Compare o que encontrou com dados de campo (PageSpeed Insights / Search Console CrUX) — um bom trace local não garante uma pontuação de campo aprovada.
• Para dúvidas de rastreabilidade/indexabilidade, mude para URL Inspection — o painel Performance não responde “o que o Googlebot vê”.

O painel Performance e as ferramentas ao redor dele

O painel é o diagnóstico local de lab. Veja onde ele fica em relação ao restante:

• Painel Performance do Chrome DevTools — esta ferramenta. Trace local, bruto e de lab; melhor para descobrir por que uma página está lenta e localizar o elemento LCP.
• Lighthouse — também executa dentro do DevTools; auditoria automatizada pontuada com lista priorizada de correções.
• PageSpeed Insights — dados de campo CrUX no topo e uma execução de lab do Lighthouse abaixo; somente URLs públicas, funciona em concorrentes.
• Chrome UX Report (CrUX) — o conjunto de dados de campo de usuários reais que o Google realmente usa no ranking; o painel agora pode sobrepô-lo aos resultados locais.
• WebPageTest — teste remoto em dispositivo real, resultados compartilháveis e scripts de várias etapas.
• Relatório Core Web Vitals do Google Search Console — grupos de páginas com falha em escala (dados de campo).
• Search Console — URL Inspection — a ferramenta certa (não o painel Performance) para saber “o que o Googlebot consegue rastrear e renderizar”.
• Microsoft Edge DevTools — o mesmo painel Performance de Chromium, para fluxos focados em Edge/Bing.

Para entender como tudo isso se encaixa — lab versus campo e qual deles o Google usa no ranking — comece pelo hub de ferramentas de performance web.

Erros do painel Performance que desperdiçam um trace

Tratar uma única gravação como verdade de campo

O painel Performance registra um navegador local, dispositivo, perfil de rede, estado de cache e jornada. Use-o para explicar um gargalo; depois use CrUX ou RUM para avaliar quão comum esse gargalo é.

Gravar sem uma interação reproduzível

Um trace aberto demais se enche de atividade sem relação. Defina o carregamento ou a interação, comece no mesmo estado e grave apenas o tempo necessário para capturá-la.

Ler o flame chart sem as trilhas de rede e de quadros

Uma tarefa longa pode ser consequência, e não a primeira causa. Alinhe o trabalho da main thread com requisições, interações, capturas de tela e pinturas antes de atribuir responsabilidade.

Aplicar throttling pesado e chamar o número de benchmark

O throttling ajuda a expor gargalos, mas seu resultado é um cenário de lab. Mantenha as configurações idênticas nas comparações antes/depois e identifique-as ao compartilhar os resultados.

Corrija problemas comuns do painel Performance

O trace está barulhento demais para ler

Causa provável: extensões, abas em segundo plano ou uma gravação longa demais acrescentam trabalho sem relação. Correção: use um perfil limpo, feche a atividade em segundo plano e capture uma jornada definida. Confirmação: a interação ou o carregamento relevante ocupa uma parte curta e reconhecível do trace.

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

Causa provável: a gravação não incluiu a janela completa entre input e pintura, ou a trilha errada está expandida. Correção: grave novamente o clique, toque ou interação de teclado exatos e inspecione Interactions junto do trabalho da main thread. Confirmação: o evento selecionado expõe o atraso de input, o processamento e o trabalho de apresentação.

O resultado muda muito entre as execuções

Causa provável: o estado do cache, a variação da rede, o trabalho em segundo plano ou a configuração do teste mudou. Correção: padronize o modo de recarregamento, o throttling, a viewport e a jornada; depois execute várias vezes. Confirmação: o mesmo gargalo aparece mesmo quando a duração total varia.

O painel mostra boas métricas de lab, mas o Search Console está ruim

Causa provável: o trace local não representa usuários reais ou jornadas mais 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 contradizer a agregação de campo.

Prove que uma correção orientada pelo trace funcionou

Teste de jornada repetida

Teste a executar: registre o mesmo carregamento ou interação com cache, viewport e configurações de throttling idênticos antes e depois da mudança. Resultado esperado: a requisição, tarefa ou fase de renderização alvo diminui de forma consistente. Interpretação da falha: a variação entre execuções ou outro gargalo explica o resultado. Janela de monitoramento: imediatamente, em várias gravações. Gatilho de rollback: aparecem erros, trabalho ausente ou comportamento visual pior.

Teste da main thread

Teste a executar: compare a tarefa selecionada da main thread e seus filhos nos dois traces. Resultado esperado: o trabalho removido ou adiado desaparece do intervalo crítico, em vez de apenas ser renomeado ou movido para antes. Interpretação da falha: a implementação deslocou o mesmo custo para outro lugar. Janela de monitoramento: imediatamente. Gatilho de rollback: o bloqueio total em torno da ação do usuário aumenta.

Teste de passagem para dados de campo

Teste a executar: monitore o template ou a interação alterada em RUM depois do ganho de lab. Resultado esperado: a métrica de campo afetada e sua atribuição melhoram para o segmento pretendido. Interpretação da falha: o cenário local não era representativo. Janela de monitoramento: RUM conforme o tráfego chega; CrUX durante sua janela de campo móvel. Gatilho de rollback: a performance de campo ou a conclusão da tarefa piora de forma consistente.

Teste seus conhecimentos: painel Performance do Chrome DevTools

Cinco perguntas rápidas sobre o que é o painel Performance, como lê-lo e o que ele não é. Escolha uma resposta para cada uma e confira depois.

Recursos que valem seu tempo

Meus textos

• JavaScript SEO: What You Need to Know — onde uso o gráfico de carregamento da aba Performance para explicar como a renderização do Googlebot difere de uma pintura completa do navegador.
• Google PageSpeed Insights for SEOs & Developers — a ferramenta pontuada, com campo e lab, que complementa o trace bruto obtido no DevTools.
• The Beginner’s Guide to Technical SEO — onde performance e renderização se encaixam no quadro maior.

Minhas palestras

• Page Experience Update (TMC, June 2021) (SlideShare) — inclui a receita passo a passo “How to see the LCP element in DevTools”.
• What’s Next for Page Experience (SMX Next 2021) (SlideShare) — minha palestra sobre page experience da mesma época.

Do setor

• Performance panel overview (Chrome for Developers) — o ponto de partida canônico: o que é, como abrir e métricas ao vivo.
• Analyze runtime performance (Chrome for Developers) — o flame chart, FPS/CPU e o passo a passo de gravação.
• Monitor your local and real-user Core Web Vitals in DevTools (Rick Viscomi, Chrome) — a tela inicial redesenhada e a sobreposição de dados de campo CrUX.
• Performance tooling in 2024 and beyond (Sweeny e Irish, Chrome) — a história Timeline → Performance e a relação com Lighthouse/Insights.
• 3 Ways to Use Chrome DevTools for SEO Troubleshooting (Richie Lauridsen, Search Engine Journal) — o tratamento de SEO mais próximo, incluindo a técnica de encontrar o LCP.
• Profile Site Speed With The DevTools Performance Tab (DebugBear) — o aprofundamento técnico não-SEO mais completo: diagnóstico de forced reflow, análise de camadas e throttling para enxergar melhor.
• Chrome DevTools for Debugging Web Performance (Web Performance Calendar, 2025) — uma perspectiva comunitária atual, pós-redesign, sobre o fluxo do painel.

Registro de alterações