Diagnostique o LCP com o painel de performance do Chrome DevTools

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

O DevTools vem por último, não primeiro

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

Comece com field data. O CrUX diz se o LCP é mesmo um problema. O RUM diz quais páginas e quais elementos são lentos para os seus usuários reais. Esse fluxo de trabalho é coberto passo a passo em Corrija e identifique problemas de LCP. O DevTools então responde à única pergunta que resta: por quê.

Se você pular o 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 num 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 você gravar qualquer coisa, ele mostra uma visualização de métricas ao vivo com o LCP, o CLS e o INP da página em que você está, medidos localmente enquanto você navega.

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

Uma dica rápida: se você quer o elemento do LCP destacado em qualquer página sem abrir o DevTools, use nossa extensão gratuita Core Web Vitals Visualizer para o Chrome.

Configure o throttling antes de gravar

Um trace sem throttling na máquina de um desenvolvedor é quase inútil. Os números serão ótimos e nenhum deles vai bater com o que seus usuários experimentam. Configure o throttling tanto de CPU quanto de rede no painel antes de gravar.

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

Quando o field data está ativado, o DevTools pode até recomendar um preset de throttling que bate com o que seus usuários reais experimentam. 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 o Core Web Vitals.

Grave o carregamento da 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 para a gravação sozinho alguns segundos após o carregamento terminar. Para o LCP você não precisa tocar em nada durante a gravação. Tire as mãos da página.

Uma dica rápida: grave em uma janela anônima com as extensões desativadas. Extensões injetam scripts em toda página, 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 o trace terminar, a barra lateral Insights à esquerda lista o que o DevTools encontrou. O que você quer é o LCP breakdown (versões mais antigas do Chrome o chamam de LCP by phase). Ele divide o tempo do LCP em suas quatro subpartes:

Para um LCP de texto sem uma 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 render delay.

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

Como deve ser um breakdown saudável? A orientação do Google é que as duas subpartes de delay devem estar perto de zero (abaixo de 10% do LCP cada), com quase todo o tempo indo para o TTFB e o download de fato. Nossa própria pesquisa sobre o Core Web Vitals em milhões de carregamentos de página mostra o quão longe a realidade está disso: o TTFB toma 48%, o load delay 24%, a load duration apenas 10% e o render delay 17%. Leia isso de novo: no site mediano, as duas fases de espera juntas desperdiçam quatro vezes mais tempo do que o próprio download. Não há nada baixando durante essas fases. Não há nada renderizando também. O navegador está esperando por um trabalho que poderia ter começado antes, e é por isso que essas duas subpartes são o primeiro lugar para buscar ganhos.

O insight LCP request discovery

Quando o LCP é uma imagem, há um segundo insight que vale a pena abrir: o LCP request discovery. Ele executa três checagens 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 está corretamente não aplicado a ela?

Qualquer checagem 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 uma correção concreta, e todas elas estão cobertas no guia sobre Resource Load Delay.

Lendo a timeline por conta própria

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, do LCP, do DCL e do evento de load. O marcador do LCP é o momento em que o elemento foi pintado. Tudo o que você está diagnosticando acontece à esquerda dele.

A trilha Network mostra cada requisição. Encontre o recurso do LCP e olhe 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 compressão de imagem nenhuma vai salvá-la. Se você tivesse tornado essa imagem descobrível desde os primeiros bytes do HTML, o download teria começado enquanto o navegador ainda estava fazendo o parsing do head.

A trilha Main mostra o trabalho da main thread. As long tasks são sinalizadas com um triângulo vermelho no canto. O padrão a procurar: o recurso do LCP terminou de baixar, mas o marcador do LCP está centenas de milissegundos mais à direita. Essa diferença é o element render delay, e uma dessas tarefas sinalizadas geralmente é a dona disso. Passe o mouse sobre a tarefa para ver qual script é o responsável. Na minha experiência, é um tag manager ou um script de consentimento com muito mais frequência do que o seu próprio código.

Corrija o que você encontrou

A maior subparte no breakdown decide para onde você vai em seguida: TTFB, Resource Load Delay, Resource Load Duration ou Element Render Delay. Se o elemento do LCP for uma imagem, o guia Otimize a imagem do LCP engloba todos os quatro.

Uma nota final: uma página com prerender mostra 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 e não nas landing pages, as speculation rules podem pular todo o diagnóstico.