Diagnostique a LCP com o painel de Performance do Chrome DevTools

Este guia faz parte do hub sobre Largest Contentful Paint (LCP). Ele aborda uma ferramenta: o painel Performance do Chrome DevTools. Você vai gravar um trace com limitação de desempenho, ler as quatro subpartes do LCP e sair sabendo qual consertar primeiro.

O DevTools vem por último, não primeiro

O painel Performance é uma ferramenta de laboratório. Ele mede o carregamento de uma página, em um dispositivo, em uma rede: a sua. Isso o torna o lugar errado para começar e o lugar certo para terminar.

Comece pelos field data. O CrUX diz se o LCP é de fato um problema. Dados de RUM mostram quais páginas e quais elementos são lentos para os seus usuários reais. Esse fluxo de trabalho é detalhado passo a passo em Corrigir e Identificar Problemas de LCP. O DevTools então responde à única pergunta que sobra: por quê.

Se você ignorar os field data, vai acabar otimizando a página que calhou de testar na conexão que calhou de ter. Esse é o padrão que vejo em quase toda auditoria: a máquina do desenvolvedor passa, o p75 do CrUX falha e todos ficam confusos. Você mediu um laptop rápido na fibra óptica. Seus usuários estão em um Android intermediário dentro de um trem.

A visualização de métricas ao vivo

Abra o DevTools (Ctrl+Shift+I no Windows e Linux, Cmd+Option+I no Mac) e vá para a aba Performance. O painel não abre mais vazio. Antes de gravar qualquer coisa, ele mostra uma visualização de métricas ao vivo com o LCP, CLS e INP da página em que você está, medidos localmente enquanto você navega.

Três coisas nesta visualização são úteis para o trabalho de LCP. Primeiro, ela nomeia o elemento de LCP e, ao passar o mouse sobre ele, destaca o elemento na página. Assim, não é preciso adivinhar qual imagem ou título o navegador escolheu. Você também pode habilitar os field data nesta visualização. O DevTools então puxa os números do CrUX para a URL e origem, exibindo-os ao lado dos seus valores locais. Se o seu LCP local marca 0,8 segundos e o p75 dos field data marca 3,1 segundos, essa diferença é a sua primeira descoberta: sua máquina não é representativa e usar limitação não é opcional.

Uma dica rápida: se quiser que o elemento do LCP seja destacado em qualquer página sem abrir o DevTools, use nossa extensão gratuita do Chrome, a Core Web Vitals Visualizer.

Configure a limitação antes de gravar

Um trace sem limitação em uma máquina de desenvolvedor é quase inútil. Os números serão ótimos e nenhum deles vai corresponder ao que os seus usuários vivenciam. Configure a limitação de CPU e rede no painel antes de gravar.

• Limitação de CPU: use o atraso de 4x como padrão para testes mobile. 20x se aproxima de um dispositivo de baixo desempenho. Versões recentes do Chrome também podem calibrar perfis para a sua máquina específica: a opção Calibrate gera perfis mobile básicos e intermediários com base na velocidade do seu próprio hardware. Isso importa porque 4x num desktop rápido é um dispositivo muito diferente de 4x num laptop antigo.
• Limitação de rede: use Slow 4G. Esse é o perfil que costumava se chamar Fast 3G antes do Chrome renomeá-lo, e é o que o Lighthouse simula para mobile. Fast 4G é a opção mais leve para testar conexões melhores.

Quando os field data estão ativados, o DevTools pode até recomendar um perfil de limitação que corresponda ao que os seus usuários reais vivenciam. Use-o. Para a lógica completa por trás dessas configurações, veja nosso guia sobre as melhores configurações de rede do DevTools para os Core Web Vitals.

Grave um carregamento de página

Clique no botão "Record and reload". O Chrome navega para uma página em branco, inicia o trace, carrega a sua página e interrompe a gravação por conta própria alguns segundos após o fim do carregamento. Para o LCP, você não precisa tocar em nada durante a gravação. Mantenha as mãos longe da página.

Uma dica rápida: grave numa janela anônima com as extensões desativadas. As extensões injetam scripts em todas as páginas, e esses scripts aparecem no seu trace como long tasks que não têm nada a ver com o seu site.

Leia o insight LCP breakdown

Após a conclusão do trace, a barra lateral Insights à esquerda lista o que o DevTools encontrou. O que você procura é o LCP breakdown (versões mais antigas do Chrome o chamam de LCP by phase). Ele divide o tempo do LCP em quatro subpartes:

Para um LCP de texto sem webfont não há nada para baixar, então as duas subpartes de recurso são zero e a história toda é o TTFB mais o atraso na renderização.

Passe o mouse sobre uma subparte no insight e o DevTools destaca essa janela exata na timeline. Clique nela e a timeline amplia, para você poder ver quais requisições e tarefas caem dentro dessa janela. E se você ativou os field data, o insight mostra o valor do p75 do CrUX ao lado de cada subparte local (quando o CrUX tem dados de LCP de imagem do seu site). Essa comparação é o recurso mais subestimado do painel. Ela diz se o trace que você está olhando se parece com o que seus usuários realmente experimentam, antes de você passar uma tarde consertando.

Como um detalhamento saudável deve se parecer? A orientação do Google é que as duas subpartes de atraso devem ficar próximas de zero (menos de 10% do LCP cada), com quase todo o tempo indo para o TTFB e o download real. Nossa própria pesquisa sobre os Core Web Vitals cobrindo milhões de carregamentos de página mostra quão longe a realidade está disso: o TTFB consome 48%, o atraso no carregamento 24%, a duração do carregamento apenas 10% e o atraso na renderização 17%. Leia isso de novo: no site mediano, as duas fases de espera juntas desperdiçam quatro vezes mais tempo do que o download em si. Não há nada sendo baixado durante essas fases. Nada sendo renderizado também. O navegador está aguardando por um trabalho que poderia ter começado mais cedo, e é por isso que essas duas subpartes são o primeiro lugar para buscar melhorias.

O insight LCP request discovery

Quando o LCP é uma imagem, há um segundo insight que vale a pena abrir: LCP request discovery. Ele roda três verificações na requisição do LCP:

• O fetchpriority="high" está aplicado na imagem (ou no seu preload)?
• A requisição é descobrível no documento HTML inicial?
• O lazy loading foi corretamente não aplicado a ela?

Qualquer verificação que falhar aponta para um problema de descoberta. O insight também anota na timeline o momento em que a imagem poderia ter começado a baixar e uma estimativa do tempo que você está perdendo. Cada uma dessas três falhas tem um conserto direto, e todas são cobertas no guia de Atraso no Carregamento do Recurso.

Lendo a timeline você mesmo

Os insights cobrem os casos comuns. Para todo o resto, você lê o trace diretamente. Três trilhas importam para o LCP.

A trilha Timings mostra os marcadores do FCP, LCP, DCL e o evento load. O marcador do LCP é o momento em que o elemento foi pintado. Tudo que você está diagnosticando acontece à esquerda dele.

A trilha Network mostra cada requisição. Encontre o recurso do LCP e repare quando ele começa, não apenas quanto tempo ele leva. Uma requisição que começa aos 2,5 segundos em um LCP de 3 segundos é um problema de descoberta, e nenhuma quantidade de compressão de imagem vai salvá-la. Se você tivesse deixado essa imagem descobrível a partir dos primeiros bytes do HTML, o download teria começado enquanto o navegador ainda analisava o head.

A trilha Main mostra o trabalho da main thread. As long tasks são marcadas com um triângulo vermelho no canto. O padrão a procurar: o recurso do LCP terminou de baixar, mas o marcador do LCP fica centenas de milissegundos mais à direita. Esse espaço é o atraso na renderização do elemento, e uma dessas tarefas marcadas geralmente é a responsável. Passe o mouse sobre a tarefa para ver qual script está causando isso. Na minha experiência, é muito mais frequente ser um gerenciador de tags ou script de consentimento do que o seu próprio código.

Conserte o que você encontrou

A maior subparte no detalhamento decide para onde você vai a seguir: TTFB, Atraso no Carregamento do Recurso, Duração do Carregamento do Recurso ou Atraso na Renderização do Elemento. Se o elemento do LCP for uma imagem, o guia de Otimizar a Imagem do LCP cobre todos os quatro.

Uma nota final: uma página pré-renderizada exibe todas as quatro subpartes quase em zero, porque o navegador fez todo o trabalho antes de o usuário clicar. Se o seu problema de LCP for em navegações dentro do seu site em vez de páginas de destino, as regras de especulação podem te poupar o diagnóstico inteiro.