Largest Contentful Paint (LCP): O que é, como medir e otimizar

O que é o Largest Contentful Paint (LCP)?

O Largest Contentful Paint é o tempo de renderização do maior elemento de conteúdo (uma imagem, vídeo ou bloco de texto) pintado na parte visível da tela. O valor do LCP é o tempo em milissegundos entre a requisição da página e o momento em que esse elemento é exibido acima da dobra.

Algumas pessoas o chamam de "last contentful paint". Trata-se do maior elemento: um elemento menor pintado depois não altera isso.

História do Largest Contentful Paint

Por que não medir a velocidade de carregamento como 'o tempo que a página leva para carregar'?

Porque na maioria dos sites modernos não dá para dizer quando a página carregou. O lazy loading e o carregamento progressivo fazem com que a página continue carregando enquanto o visitante permanecer. Um único ponto no tempo não descreve a velocidade da página.

Uma página pode parecer lenta em vários momentos enquanto carrega. O servidor responde tarde (Time to First Byte), nada aparece por um tempo (First Contentful Paint) ou o hero ainda é uma caixa cinza quando o resto já está lá (Largest Contentful Paint). Ou o primeiro clique não faz nada.

O LCP foi escolhido porque acompanha o que o visitante vê. Quando o LCP acontece, a maioria dos visitantes acha que a página terminou, mesmo com scripts ainda rodando. A métrica foi criada para responder a uma pergunta: 'Quando o conteúdo de uma página está visível?'.

LCP vs FCP: Qual é a Diferença?

O Largest Contentful Paint (LCP) e o First Contentful Paint (FCP) medem o desempenho de carregamento, mas medem momentos diferentes. O FCP dispara assim que o navegador pinta o primeiro pixel de conteúdo, que pode ser uma barra de navegação minúscula ou um spinner de carregamento. O LCP dispara quando o maior elemento significativo é renderizado na viewport.

O FCP diz que a página começou a carregar. O LCP diz que a página parece carregada, e é por isso que o Google fez do LCP o Core Web Vital.

Para a maioria dos sites, trabalhe no LCP primeiro. O FCP sempre acontece antes do LCP, então um LCP rápido geralmente traz um FCP rápido. Um FCP rápido diz pouco sobre o LCP: uma página pode pintar seu cabeçalho em 0.8 segundos e sua imagem hero em 4.

Por que o LCP Importa

Como um Core Web Vital, o LCP importa para SEO. Ele importa mais para os seus visitantes: ninguém gosta de esperar, e a maior parte do tráfego é mobile, onde as páginas carregam mais devagar.

• Rankings. O LCP faz parte dos Core Web Vitals do Google, e o Google usa a velocidade da página como fator de ranqueamento.
• Visitantes. Um visitante que encara uma tela branca ou uma caixa cinza onde o hero deveria estar vai embora. O teste da Vodafone abaixo quantificou isso.
• Google Ads. A experiência na landing page faz parte do seu Quality Score. Uma landing page lenta torna cada clique mais caro.

Estudo de Caso: Vodafone (Melhoria de 31% no LCP, 8% Mais Vendas)

A Vodafone Itália dividiu o tráfego 50/50 entre a landing page antiga e uma cópia mais rápida com aparência e funcionamento iguais. A cópia mais rápida renderizava no servidor em vez de usar widgets no lado do cliente, servia uma imagem hero redimensionada, adiava as imagens abaixo da dobra e usava arquivos SVG e PNG menores. O LCP foi de 8.3 para 5.7 segundos (31% mais rápido) e as vendas subiram 8%. (Estudo de caso da Vodafone no web.dev)

Teste: Google Flights (fetchpriority Poupou 700ms)

Em um teste na página do Google Flights, adicionar fetchpriority="high" à imagem LCP reduziu o LCP de 2.6 para 1.9 segundos. Sem isso, o Chrome requisita imagens com prioridade baixa e só aumenta a prioridade quando o layout mostra que a imagem está na viewport. Em uma página pesada, isso representa centenas de milissegundos de espera. Saiba mais sobre a priorização de recursos para os Core Web Vitals.

Quais Elementos são Considerados Elementos LCP?

Nem todo elemento pode ser o elemento LCP. Ele deve ser pintado na parte visível da tela (a viewport) antes que o usuário interaja com a página.

O elemento deve ser:

• Um elemento <img>.
• Um elemento <image> aninhado dentro de um elemento <svg>.
• Um elemento <video> (a imagem de poster ou o primeiro frame do vídeo, o que ocorrer primeiro, é usado).
• Um elemento com uma imagem de fundo carregada via a função url() do CSS. Ele conta, mas o scanner de preload não consegue vê-lo, então o navegador encontra a imagem tarde. Mais em adiamento de imagens de fundo.

• Um elemento de bloco contendo nós de texto ou outros elementos de texto inline (no caso de elementos de texto inline como <span>, o elemento de bloco mais próximo, <div> ou <p>, é considerado).

Alguns elementos são ignorados: elementos com opacity: 0, imagens que cobrem toda a viewport (o Chrome as trata como fundo) e imagens de baixa entropia. Desde o Chrome 112, uma imagem com menos de 0.05 bits de dados de imagem por pixel exibido é ignorada como um placeholder. O Chrome altera essas regras de tempos em tempos.

Como o Tamanho do Elemento LCP é Medido

O navegador calcula o tamanho de cada candidato com estas regras:

• Apenas viewport: Apenas a parte visível da página é considerada. Se um elemento estiver apenas parcialmente na viewport visível, o tamanho considerado será cortado.
• Sem borda, padding ou margin: Para todos os elementos, bordas de texto e imagem, padding e margins são completamente ignorados.
• Tamanho do texto: Elementos de texto são reportados como o menor retângulo que pode ser pintado ao redor do(s) nó(s) de texto.
• Tamanho da imagem: Para imagens, o menor entre as dimensões intrínsecas (a largura e altura originais) e o tamanho de exibição (o tamanho na tela) é usado para calcular o tamanho do elemento LCP.
• O primeiro tamanho conta: Quando o layout muda ou quando o tamanho de um elemento muda, apenas o primeiro tamanho é considerado para o LCP.
• Elementos removidos são incluídos: Quando um elemento é removido do DOM, ele continua sendo um candidato ao LCP.

O Elemento LCP Pode Mudar Durante o Carregamento

Uma página renderiza em estágios, então o elemento LCP frequentemente muda enquanto a página carrega. Até a primeira interação do usuário, o navegador reporta cada novo candidato ao LCP. Quando um novo elemento é pintado, sendo visível na viewport e maior que o candidato anterior, ele se torna o novo elemento LCP.

Conclusões dos field data de LCP: No CoreDash rastreamos milhões de entradas de LCP por dia. No mobile, o elemento LCP costuma ser um parágrafo ou um título. No desktop, a viewport mais larga acomoda uma imagem maior, então a mesma página frequentemente tem um elemento LCP diferente em cada dispositivo. Verifique ambos antes de decidir o que corrigir.

O que é uma Boa Pontuação de LCP?

Para passar na parte de LCP dos Core Web Vitals, pelo menos 75% das visitas da sua página precisam de um bom LCP: menos de 2.5 segundos. Entre 2.5 e 4 segundos precisa de melhoria, acima de 4 é ruim. Verifique a aba mobile no PageSpeed Insights primeiro. Os field data no topo são o p75 dos últimos 28 dias.

O que os Dados do CoreDash Mostram

LCP de Imagem vs LCP de Texto

Páginas com elementos LCP baseados em imagem têm um LCP p75 de 744ms, quase duas vezes mais lentas que elementos LCP baseados em texto, com 388ms. A maior parte dessa diferença vem do quão tarde o navegador encontra e requisita a imagem (veja as quatro fases abaixo).

O Impacto do Preloading e do Lazy Loading

Imagens LCP com preloading têm um p75 de 364ms e nenhum carregamento de página ruim. Imagens LCP com lazy loading ficam em 720ms, com 4.3% dos carregamentos de página avaliados como ruins, e imagens sem preloading ficam em 752ms. Nunca aplique lazy loading na imagem LCP, e garanta que ela seja requisitada cedo: no HTML com fetchpriority="high", ou com preloading quando isso não for possível.

LCP no Mobile vs Desktop

O LCP no mobile (764ms no percentil 75) é o dobro do LCP no desktop (380ms). As redes mobile são mais lentas e os celulares têm menos CPU. O Google avalia mobile e desktop separadamente, e o mobile é onde a maioria dos sites falha, então comece por aí.

O LCP pela Web

No lançamento do CrUX de agosto de 2026, 68.1% das origens tinham um bom LCP, contra 66.7% no ano anterior. Esse ainda é o menor dos três Core Web Vitals (INP 85.3%, CLS 81.5%), então para a maioria dos sites o LCP decide se eles passam.

O crawl do HTTP Archive adiciona o que o CrUX não coleta. No Web Almanac de 2025, o elemento LCP é uma imagem em 76% das páginas mobile e cerca de 16% das páginas aplicam lazy loading a ela. Apenas 17% das páginas mobile com uma imagem LCP usam fetchpriority="high". Cerca de 2% fazem preloading dela.

Como o LCP é Medido: As Quatro Fases Principais

Segundo o Google, o Largest Contentful Paint pode ser dividido em 4 subpartes. Cada fase precisa de uma correção diferente, então primeiro descubra qual fase está lenta. Um Time to First Byte (TTFB) lento precisa de trabalho no servidor, enquanto um Resource Load Delay lento precisa de mudanças no seu HTML.

O tempo do LCP é a soma destas quatro fases:

• Time to First Byte (TTFB): O tempo de resposta do servidor. Ele cobre tudo desde a busca de DNS, passando pela conexão TCP/TLS, até o momento em que o navegador recebe o primeiro byte do documento HTML. Um TTFB lento empurra tudo que vem depois. O motivo usual é HTML sem cache, fazendo com que cada visita construa a página de novo em PHP ou Node. Uma CDN que não faz cache do HTML só torna as imagens mais rápidas.
• Atraso no Carregamento do Recurso (Resource Load Delay): O tempo entre a conclusão do TTFB e o navegador realmente começar a baixar o recurso LCP. Um longo atraso aqui significa que o navegador encontrou o recurso LCP tarde. Isso geralmente vem de imagens de fundo no CSS (que o scanner de preload não consegue descobrir) ou de renderização client-side (onde o elemento LCP só aparece depois que o JavaScript executa). Coloque o elemento LCP no HTML inicial, e faça o preloading da imagem LCP apenas quando isso não for possível.
• Duração do Carregamento do Recurso (Resource Load Duration): Quanto tempo leva para baixar o recurso LCP (a imagem, fonte ou vídeo). Essa fase depende do tamanho do arquivo e da rede: AVIF ou WebP, um srcset para que os celulares recebam uma imagem do tamanho da tela. Na maioria dos sites, é a mais curta das quatro.
• Atraso na Renderização do Elemento (Element Render Delay): O tempo entre o recurso LCP terminar de baixar e o elemento ser totalmente renderizado na tela. A imagem está lá, mas o navegador ainda não consegue pintá-la. CSS e JavaScript render blocking na main thread são os motivos usuais. Um clássico é um snippet de teste A/B que esconde a página até que o script do teste seja carregado.

O Google analisou navegações reais do Chrome com um LCP de imagem e dividiu o LCP p75 nessas fases. A origem mediana em cada grupo:

Em sites com um LCP ruim, o TTFB e o atraso de carregamento juntos levam mais de 3.5 segundos. Baixar a imagem leva 350ms. A maioria das origens com um LCP ruim passa menos de 10% do seu LCP baixando a imagem LCP.

Para os passos para encontrar e corrigir cada fase, leia Identificar e Corrigir Problemas do Largest Contentful Paint (LCP).

Erros Comuns de LCP

Erro 1: Lazy Loading na Imagem LCP

O loading="lazy" manda o navegador aguardar com o download até a imagem estar perto da viewport. A imagem LCP já está na viewport, então o navegador primeiro tem que fazer o layout para descobrir isso, e só então inicia o download. Temas e page builders costumam adicionar isso a toda imagem, incluindo o hero. Remova isso da imagem LCP. Só isso. Segundo o Web Almanac de 2025, cerca de 16% das páginas fazem isso. Leia o guia sobre como corrigir uma imagem LCP com lazy loading.

Erro 2: A Imagem LCP é Encontrada Tarde

Um slider ou um hero com renderização client-side só coloca a URL da imagem na página depois que o CSS é analisado ou o JavaScript roda. Isso custa centenas de milissegundos antes que o download sequer comece. A melhor correção é uma <img> normal no HTML. Quando isso não for possível, adicione um preload no <head>:

<link rel="preload" as="image" href="/img/hero.webp" fetchpriority="high">

O navegador inicia o download na hora. Um preload sozinho não aumenta a prioridade, então mantenha o fetchpriority="high" nele, senão a imagem continua esperando atrás de folhas de estilo e scripts. Mais no guia de preloading da imagem LCP.

Erro 3: Imagem de Fundo CSS como Elemento LCP

O scanner de preload não consegue ver um background-image: url(...). O navegador só encontra a imagem depois de baixar o HTML e o CSS e cruzar a regra com um elemento na página. Isso adiciona Resource Load Delay. A correção é usar uma tag <img> padrão, com o atributo fetchpriority="high":

<img src="/img/hero.webp"
     alt="Descriptive alt text"
     width="1200"
     height="600"
     fetchpriority="high">

Agora o scanner de preload a encontra no HTML, e o fetchpriority="high" a coloca na frente da fila. Mais no guia sobre priorização de recursos.

Como Medir o Largest Contentful Paint

Medir o Largest Contentful Paint com JavaScript

O jeito mais rápido é um PerformanceObserver. Este snippet registra no console o tempo e o elemento do LCP:

new PerformanceObserver((list) => {
    const lcpEntry = list.getEntries().at(-1);
    console.log('LCP value: ', lcpEntry.startTime);
    console.log('LCP element: ', lcpEntry.element, lcpEntry.url);
  }).observe({ type: 'largest-contentful-paint', buffered: true });

Para mais do que uma checagem rápida, use a Web Vitals Library.

Medir o Largest Contentful Paint (LCP) no Chrome DevTools

1. Abra o Chrome DevTools pressionando Ctrl+Shift+I (ou Cmd+Option+I no Mac).
2. Vá para o painel Performance. Ele mostra o LCP da página atual na hora, com o elemento LCP.
3. Clique no botão de recarregar no painel para gravar um trace. O marcador do LCP no trace mostra o elemento LCP e suas quatro fases.

O passo a passo completo, com o que procurar no trace, está em diagnosticar o LCP com o Chrome DevTools.

Medir o Largest Contentful Paint com Ferramentas de Lab e Field

Os lab data e os field data fazem trabalhos diferentes. Você precisa de ambos.

• Os field data (RUM e CrUX) são o que o Google usa para decidir se você passa. É o que os seus usuários reais recebem. Comece por aqui para descobrir se você tem um problema.
• Os lab data (Lighthouse, etc.) são um teste controlado. O Google não ranqueia com base neles, mas você precisa deles para debug: eles dizem por que você tem um problema.

As ferramentas:

Melhorando o Largest Contentful Paint

Pegue o seu template mais lento no mobile e observe as suas quatro fases do LCP: o CoreDash as mostra por página para visitantes reais, o DevTools para um único carregamento. Nos field data acima, o TTFB e o atraso de carregamento são os maiores vilões em quase todo site com um LCP ruim, então comece por eles.

Converter a imagem hero para AVIF é o que todo mundo tenta primeiro. Em um site com um LCP de 4 segundos, o download inteiro leva cerca de 350ms, então um arquivo menor economiza uma fração disso. Faça isso, mas faça por último.

Por fase:

• TTFB: faça cache do HTML, no servidor ou na CDN. Leia mais no nosso guia de otimização de TTFB.
• Atraso no Carregamento do Recurso (Resource Load Delay): uma <img> no HTML, sem loading="lazy", com fetchpriority="high". Veja como corrigir o Resource Load Delay.
• Duração do Carregamento do Recurso (Resource Load Duration): um arquivo menor, dimensionado para o dispositivo. Veja como otimizar a imagem LCP. Você também pode ler sobre como baixamos o LCP em 70% em um projeto real.
• Atraso na Renderização do Elemento (Element Render Delay): menos CSS render blocking, scripts adiados, sem snippets anti-flicker. Veja como corrigir o Element Render Delay.

Guias Relacionados

Cada parte do LCP tem o seu próprio guia:

• Identificar e Corrigir Problemas de LCP: descubra qual fase está lenta, com o DevTools, WebPageTest e CoreDash.
• Diagnosticar o LCP com o Chrome DevTools: o marcador do LCP num trace de Performance.
• Otimizar a Imagem LCP: formatos, tamanhos e srcset.
• Resource Load Delay: como fazer a imagem LCP ser requisitada cedo.
• Resource Load Duration: o download em si.
• Element Render Delay: quando a imagem chegou, mas ainda não foi pintada.