Como o Largest Contentful Paint se divide em quatro partes que dá para corrigir

O que é LCP (Largest Contentful Paint) e o que é uma boa pontuação?

O Google considera o Largest Contentful Paint bom em 2.5 segundos ou menos, precisando melhorar entre 2.5 e 4.0 segundos e ruim acima de 4.0 segundos, lido no percentil 75 dos carregamentos de página e pontuado separadamente para celular e desktop (web.dev, "Largest Contentful Paint (LCP)", atualizado em 4 de setembro de 2025). A métrica marca o momento em que a maior imagem ou o maior bloco de texto visível dentro do viewport terminou de renderizar, que é a melhor aproximação do navegador para o momento em que o visitante decide que a página chegou. Compare o seu número com 2.5 segundos no p75 primeiro, porque uma média aprovada com um p75 reprovado ainda é uma página reprovada.

O tamanho é julgado apenas dentro do viewport, e para imagens o navegador informa o tamanho visível ou o tamanho intrínseco, o que for menor.

Quais elementos podem ser o elemento LCP?

A especificação do LCP conta cinco tipos de elemento, então o vencedor na sua página é um deles e nada além disso. Tudo que fica fora da lista, elementos canvas e gradientes CSS incluídos, não pode assumir o título por mais tela que ocupe.

Elemento elegível	O que o navegador mede
<img>	Tamanho visível ou intrínseco, o que for menor
<image> dentro de <svg>	A mesma regra do <img>
<video>	A imagem de pôster, ou o primeiro quadro pintado
Qualquer elemento com imagem de fundo url()	A área pintada do elemento
Elementos de bloco que contêm nós de texto	O menor retângulo em volta de todos os nós de texto

Identifique o seu antes de mexer em qualquer coisa. O Chrome DevTools nomeia o elemento vencedor no painel Performance, e as ferramentas de campo o anexam a cada amostra, o que importa porque os dois raramente concordam.

Quais são as quatro subpartes do Largest Contentful Paint?

O Google divide o Largest Contentful Paint em time to first byte (tempo até o primeiro byte), resource load delay (espera até o início do download), resource load duration (duração do download do recurso) e element render delay (espera até o elemento ser pintado), quatro intervalos consecutivos que somados dão a métrica inteira. A equipe do Chrome publica uma fatia alvo para cada um em "Optimize Largest Contentful Paint" (web.dev, atualizado em 31 de março de 2025): cerca de 40% para time to first byte, menos de 10% para resource load delay, cerca de 40% para resource load duration e menos de 10% para element render delay. Meça as fatias antes de escolher uma correção, porque uma subparte que já está dentro do orçamento não tem como devolver os segundos de que você precisa.

Subparte	O que cobre	Fatia alvo	O que a deixa lenta	A correção
Time to first byte	Do início da navegação até chegar o primeiro byte da resposta HTML	~40%	Cadeias de redirecionamento, respostas de origem sem cache, trabalho lento no backend, distância até a origem	Cortar redirecionamentos, servir HTML em cache a partir de nós de borda de um CDN, reduzir o tempo de processamento do backend
Resource load delay	Do primeiro byte até o navegador começar a baixar o recurso do LCP	<10%	A imagem só é referenciada em CSS ou JS, então o preload scanner nunca a vê; loading="lazy" no hero; renderização no cliente injetando a imagem tarde	Colocar a imagem do LCP no HTML inicial, adicionar <link rel="preload" fetchpriority="high"> quando ela só for alcançável por CSS ou JS, tirar o lazy loading do hero
Resource load duration	O download do recurso do LCP em si, do começo ao fim	~40%	Imagens grandes demais ou sem compressão, formatos antigos, disputa por banda, sem cabeçalhos de cache	Comprimir e redimensionar, entregar AVIF ou WebP, servir por um CDN, definir tempos de cache longos, embutir recursos pequenos
Element render delay	Do fim do download até o elemento ser de fato pintado	<10%	Folhas de estilo e scripts que bloqueiam a renderização, tarefas longas na thread principal, hidratação que segura a primeira pintura	Adiar ou embutir o CSS e o JS bloqueantes, renderizar no servidor, quebrar as tarefas longas

Como um Largest Contentful Paint de 4.2 segundos se divide entre as quatro partes?

A divisão transforma um número inútil em um alvo óbvio, porque a métrica é uma soma simples:

LCP = time to first byte + resource load delay + resource load duration + element render delay

Pegue uma página com LCP p75 de 4.2 segundos, o que é ruim. Os dados de campo dividem esse tempo em 0.9s de time to first byte, 2.0s de resource load delay, 1.0s de resource load duration e 0.3s de element render delay. Aplique as fatias alvo a 4.2 segundos para chegar ao orçamento de cada subparte.

Subparte	Medido	Fatia de 4.2s	Orçamento em 4.2s	Veredito
Time to first byte	0.9s	21%	1.68s	Dentro do orçamento
Resource load delay	2.0s	48%	0.42s	4.8x acima
Resource load duration	1.0s	24%	1.68s	Dentro do orçamento
Element render delay	0.3s	7%	0.42s	Dentro do orçamento

Três das quatro estão saudáveis. A imagem do hero só é solicitada dois segundos inteiros depois que o HTML chega, o que aponta para a descoberta: a imagem está atrás de uma regra CSS, atrás de um script ou atrás de loading="lazy". Comprimir mais atacaria o 1.0s que já está bem e deixaria a página ruim.

Corrija o problema de descoberta e o resource load delay cai para cerca de 0.2s. A nova soma é 0.9 + 0.2 + 1.0 + 0.3 = 2.4s, que passa. Uma mudança, 1.8 segundos, nenhuma imagem recodificada. Leve a mesma divisão para Cumulative Layout Shift e Interaction to Next Paint, e use ela para decidir o que conta como um bom LCP em uma página específica.

Por que o elemento LCP muda entre celular e desktop?

O elemento LCP é o que for maior dentro do viewport daquele visitante, então um layout que se reorganiza entre breakpoints entrega o título a um elemento diferente em cada dispositivo. Uma foto de hero de desktop com 1200px de largura pode ficar escondida por uma media query no celular, onde o bloco de texto do título passa a ser o maior elemento pintado. Os dois números então não compartilham mecanismo nenhum: o LCP de desktop é dominado por resource load duration, o LCP de celular por time to first byte e element render delay, porque texto não precisa de download separado.

Essa é a armadilha por trás da maioria dos trabalhos de LCP que fracassam. A equipe faz preload da imagem do hero, vê o LCP de desktop melhorar e vê o p75 de celular se recusar a andar, porque no celular aquela imagem nunca foi o elemento LCP. O Google pontua celular e desktop separadamente, então depure os dois separadamente: puxe o elemento LCP por formato de dispositivo nos dados de campo e conte com duas correções diferentes. Quando o texto ganha o título, uma fonte web que bloqueia a renderização joga a métrica inteira para element render delay e nenhum trabalho em imagem encosta nela.

Mesma página, elemento LCP diferente

DesktopA foto do hero, com 1200px de largura, vence por tamanho; o LCP é dominado por resource load duration

MobileUma media query esconde o hero, então o bloco de texto do título vence no lugar dela; o LCP é dominado por time to first byte e render delay

Por que aplicar lazy loading na imagem do hero piora o LCP?

Aplicar loading="lazy" na imagem do LCP sempre acrescenta resource load delay, porque o preload scanner a ignora durante a análise do HTML e o download espera o layout rodar e posicionar o elemento perto do viewport. A equipe do Chrome diz isso sem rodeios em "Optimize Largest Contentful Paint" (web.dev, atualizado em 31 de março de 2025): "a lazy-loaded LCP image will always lead to unnecessary resource load delay", ou seja: uma imagem de LCP carregada com lazy loading sempre vai gerar resource load delay desnecessário. A espera não compra nada, já que um hero acima da dobra já está no viewport.

O estrago vem pelos padrões. Um CMS ou uma biblioteca de componentes que carimba loading="lazy" em toda imagem acerta nas 40 que estão abaixo da dobra e erra na única que está no topo. Coloque loading="eager" e fetchpriority="high" no hero, mantenha o lazy loading em todo o resto, e depois confirme nos dados de campo em vez de em um teste de laboratório.

Como você vê o LCP que os seus visitantes reais tiveram?

Dados de campo são a única fonte que informa o elemento LCP e a divisão em subpartes a partir de dispositivos reais em redes reais, e é por isso que o real user monitoring, o monitoramento de usuários reais, está embaixo de cada número desta página. Um teste de laboratório devolve um LCP repetível para uma máquina que você configurou; o p75 que decide o seu veredito de Core Web Vitals vem das visitas que você de fato recebeu.

O peso é a restrição, porque um script de monitoramento que atrasa a página corrompe a métrica que ele informa. A Flowsery coleta dados de campo por um script com menos de 10 KB, sem cookies e hospedado na UE, sem amostragem de dados, então o p75 vem de todas as sessões e não de um subconjunto. Ele grava a sessão junto com os tempos e sinaliza rage clicks, dead clicks, erros de JavaScript e abandonos, o que transforma um p75 lento em uma gravação que você pode assistir.

Perguntas frequentes

O Largest Contentful Paint é medido antes ou depois da interação do usuário?

O navegador para de informar novos candidatos a LCP na primeira interação do usuário, seja ela um scroll, um toque ou uma tecla. Nada pintado depois desse ponto vira o elemento LCP, por maior que seja. O corte mantém a métrica presa ao carregamento inicial em vez de a conteúdo que o visitante trouxe à tela rolando a página.

O elemento LCP precisa continuar na página?

Não. Depois que um elemento é registrado como largest contentful paint, ele mantém o título mesmo que saia do viewport com a rolagem ou deixe o DOM por completo, a menos que um elemento maior renderize depois. Uma imagem de abertura que some em 500ms define o seu LCP do mesmo jeito, e em um carrossel o primeiro slide vence enquanto os seguintes não mudam nada.

Por que meu LCP de laboratório é rápido e o de campo é ruim?

Ferramentas de laboratório medem um dispositivo em uma conexão que você configurou, e os dados de campo medem os dispositivos que o seu público realmente tem. Um LCP de 1.6s no Lighthouse e um p75 de campo de 4.2s são duas respostas corretas para perguntas diferentes. Verifique uma correção no laboratório, decida se a página passa no campo.

Um CDN resolve o Largest Contentful Paint?

Um CDN reduz duas das quatro subpartes: time to first byte, servindo o HTML de um nó de borda perto do visitante, e resource load duration, servindo a imagem do mesmo jeito. Ele não faz nada pelo resource load delay causado por descoberta tardia, nem pelo element render delay causado por scripts que bloqueiam a renderização. Divida o seu LCP primeiro e a resposta já fica visível.

Um vídeo pode ser o elemento LCP?

Sim. Elementos de vídeo são elegíveis, e o navegador mede a imagem de pôster ou o primeiro quadro pintado. Colocar um pôster em um vídeo acima da dobra dá ao navegador algo para pintar antes de os dados do vídeo chegarem; sem pôster, o título de LCP vai para o que for maior.

De quantas amostras eu preciso para um número de LCP significar alguma coisa?

O suficiente para o percentil 75 parar de se mexer quando um único dispositivo fora do comum aparece. Uma rota com 40 visitas por semana produz um p75 que balança com um visitante em um celular lento, então agregue no modelo de página ou amplie a janela. Dividir por país e por dispositivo ao mesmo tempo multiplica o tráfego necessário, já que cada segmento carrega a própria distribuição.

Um gradiente CSS pode ser o elemento LCP?

A especificação do LCP reconhece cinco tipos de elemento: imagens, imagens SVG, vídeos, elementos com uma imagem de fundo url() e blocos de texto. Gradientes CSS e elementos canvas ficam fora dessa lista, então nenhum dos dois pode ganhar o título por mais que ocupem da viewport.

Um título pode virar o elemento LCP em vez de uma imagem?

Qualquer elemento de bloco que contenha nós de texto se qualifica, medido como o menor retângulo que envolve esses nós. É exatamente o que acontece em layouts mobile onde uma media query esconde a foto do hero e o bloco de texto do título passa a ser o maior elemento pintado.

Comprimir a imagem do hero sempre resolve um LCP lento?

Só quando resource load duration é a subparte acima do orçamento. No exemplo de 4.2 segundos desta página, resource load duration já estava dentro do orçamento em 1.0s enquanto resource load delay estava 4,8 vezes acima, então comprimir ainda mais a imagem teria deixado a página igualmente ruim. Confira a divisão antes de mexer na imagem.

Que fatia do LCP a resource load duration deveria ocupar?

Cerca de 40%, a mesma fatia alvo de time to first byte. As outras duas subpartes, resource load delay e element render delay, deveriam ficar cada uma abaixo de 10% do total.