Largest Contentful Paint (LCP): O Que É, Como Medir e Otimizar

O que é a Largest Contentful Paint (LCP)?

A Largest Contentful Paint é uma medida do tempo de renderização do maior elemento de conteúdo (do tipo imagem, vídeo ou texto) que foi pintado na parte visível da tela. O tempo da LCP indica o tempo em milissegundos entre a solicitação da página e quando o maior elemento de conteúdo é exibido na parte visível da página da web (above the fold).

História da Largest Contentful Paint

Se você parar para pensar, a LCP pode parecer uma métrica trivial para representar a parte de carregamento das Core Web Vitals. Por que não medir a velocidade de carregamento como 'o tempo que leva para a página carregar'?

Isso ocorre porque é difícil (ou até impossível) na maioria dos sites modernos definir quando a página foi carregada. Mais e mais sites usam técnicas como lazy loading ou carregamento progressivo, onde a página basicamente pode continuar carregando para sempre. Isso significa que a velocidade da página não pode ser medida por um único ponto no tempo.

Existem vários momentos ao carregar a página que podem fazer com que um usuário experimente a página como rápida ou lenta. Por exemplo, o atraso do servidor (Time to First Byte), a primeira vez que o conteúdo fica visível (First Contentful Paint), o momento em que a viewport visível pode parecer completa (Largest Contentful Paint) e quando a página se torna interativa (quando é possível clicar em um link) são todos pontos durante o processo de carregamento em que o site pode parecer lento ou rápido!

A Largest Contentful Paint (LCP) é escolhida porque foca na user experience do visitante. Quando a LCP ocorre, você pode presumir que um visitante acha que a página terminou de carregar (mesmo que os processos em segundo plano ainda estejam em execução). A LCP foi criada para responder à pergunta: 'Quando o conteúdo de uma página está visível?'. É por isso que a LCP é reconhecida como um indicador central de desempenho focado no usuário.

LCP vs FCP: Qual é a Diferença?

A Largest Contentful Paint (LCP) e a First Contentful Paint (FCP) medem o desempenho de carregamento, mas capturam momentos fundamentalmente diferentes na linha do tempo de carregamento da página. A FCP é disparada assim que o navegador pinta o primeiro pixel de conteúdo, que pode ser uma pequena barra de navegação ou um spinner de carregamento. A LCP é disparada quando o maior elemento significativo é renderizado na viewport.

Pense desta forma: a FCP diz que a página começou a carregar; a LCP diz que a página parece carregada. O Google escolheu a LCP como uma Core Web Vital porque ela reflete com mais precisão o que os usuários percebem como "velocidade".

Para a maioria dos sites, otimizar a LCP deve ser a prioridade. Se sua LCP for rápida, sua FCP quase sempre será rápida também, porque a FCP ocorre mais cedo na linha do tempo de carregamento. O inverso não é verdadeiro: uma FCP rápida não garante uma LCP rápida.

Por que a LCP é Importante para o Seu Negócio

A Largest Contentful Paint é uma das 3 Core Web Vitals. Como uma Core Web Vital, a Largest Contentful Paint é importante para o SEO, mas, mais importante, a LCP é crítica para a UX. Os visitantes não gostam de ser mantidos esperando, e com cada vez mais tráfego mobile (que tende a ser mais lento que o tráfego desktop), otimizar a Largest Contentful Paint faz muito sentido.

• Para SEO. Sim, o Google foca em servir as melhores páginas em seus resultados de busca. A LCP faz parte das Core Web Vitals do Google. O Google afirma claramente que a velocidade do site é um fator nos resultados de busca.
• Para Visitantes: De acordo com pesquisas recentes do próprio Google, a probabilidade de um usuário abandonar o site dobra com um tempo de carregamento de 3 segundos. Você provavelmente reconhecerá isso por si mesmo. Ao navegar na internet, quase nada parece tão irritante quanto um site que carrega lentamente. As chances são de que você sairá rapidamente de uma página de carregamento lento.
• Outras razões: A Velocidade da Página é um fator no seu Ad Score do Google. Isso significa que você pode comprar seus anúncios mais baratos. Além disso, passar nas Core Web Vitals é um dos pré-requisitos para a caixa de Top Stories do Google.

Uma LCP rápida dá ao visitante a ideia de que a página carrega rapidamente. Como resultado, é menos provável que um visitante saia da página.

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

A Vodafone Itália realizou um experimento controlado otimizando sua pontuação de LCP. Ao reduzir a LCP em 31%, eles mediram um aumento de 8% nas vendas. Isso não é uma correlação; é um teste A/B direto que prova que um carregamento percebido mais rápido se traduz em mais receita. A otimização se concentrou em fazer o preload da imagem LCP e reduzir os recursos que bloqueiam a renderização. Leia o estudo de caso completo da Vodafone no web.dev.

Estudo de Caso: Google Flights (fetchpriority Economizou 700ms)

A equipe do Google Flights adicionou fetchpriority="high" à sua imagem hero e viu a LCP melhorar em 700 milissegundos. Esta simples alteração de atributo HTML foi a otimização mais impactante no sprint de desempenho deles. O atributo fetchpriority diz ao navegador para priorizar o download da imagem LCP em relação a outros recursos, e como o experimento do Google Flights demonstra, o impacto pode ser dramático. Saiba mais sobre priorização de recursos para Core Web Vitals.

Quais Elementos são Considerados Elementos LCP?

Nem todos os elementos são considerados como um elemento LCP. O maior elemento Contentful 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 do poster ou o primeiro quadro do vídeo, o que ocorrer primeiro, é usado).
• Um elemento com uma imagem de fundo carregada via a função CSS url(). (Nota: Este é um anti-padrão para otimização de LCP, pois torna a imagem não detectável pelo scanner de preload do navegador. Leia nosso guia sobre adiamento de imagens de fundo).

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

Atualmente, certos elementos são excluídos como candidatos à LCP, como elementos ocultos com opacity: 0, imagens que correspondem a 100% do tamanho da viewport (imagens de capa) e placeholders (imagens de baixa entropia). Tenha em mente que isso pode mudar à medida que a especificação evolui!

Entrando na Parte Técnica: Medindo o Tamanho do Elemento LCP

A LCP identifica o maior elemento de conteúdo visível na viewport e calcula seu tamanho com base em um conjunto de regras precisas. Essas regras garantem consistência e precisão, mesmo em layouts complexos.

• 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: Os elementos de texto são relatados como o menor retângulo que pode ser pintado ao redor do(s) nó(s) de texto.
• Tamanho da imagem: Para imagens, a menor das 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 a LCP.
• Elementos removidos são incluídos: Quando um elemento é removido do DOM, ele ainda é um candidato à LCP.

Natureza Dinâmica da LCP

A Largest Contentful Paint (LCP) é uma métrica dinâmica. Embora a renderização possa ser complexa e ocorrer em estágios, é normal que o elemento LCP mude durante o carregamento da página. Antes da primeira interação do usuário, o performance observer do navegador identifica todos os elementos que poderiam ser considerados candidatos à LCP. Se um novo elemento for renderizado que seja visível na viewport e maior que o elemento LCP previamente identificado, ele se tornará a nova LCP.

Conclusões dos dados de campo da LCP: No CoreDash rastreamos milhões de entradas de LCP por dia. Como se constata, para visualizações de página mobile, o elemento LCP é frequentemente um elemento baseado em texto, seja um parágrafo ou um título. Em média (ou no percentil 75 para ser mais preciso), as Core Web Vitals passarão quando o elemento LCP for um nó de texto ou mesmo uma imagem normal. Quando o elemento LCP é uma imagem de fundo, vídeo ou uma imagem em lazy loading, as Core Web Vitals tendem a falhar.

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

Para passar nas Core Web Vitals para a Largest Contentful Paint, pelo menos 75% dos seus visitantes precisam ter uma pontuação LCP 'boa'. Uma pontuação de LCP entre 0 e 2,5 segundos é considerada uma boa pontuação de LCP, uma pontuação de LCP entre 2,5 e 4 segundos precisa de melhoria e uma pontuação de LCP acima de 4 segundos é considerada ruim.

O que os Dados de LCP do Mundo Real Mostram

O CoreDash rastreia milhões de medições de LCP de usuários reais todos os dias. Aqui está o que os dados revelam sobre o desempenho da LCP na web.

LCP de Imagem vs LCP de Texto

Páginas com elementos LCP baseados em imagens têm um LCP no percentil 75 de 744ms, quase duas vezes mais lento que os elementos LCP baseados em texto com 388ms. Isso confirma que a otimização de imagens é a área mais impactante para melhorar as pontuações de LCP. Se o seu elemento LCP for uma imagem, você precisa ser particularmente agressivo com a otimização.

O Impacto do Preloading e Lazy Loading

Imagens LCP com preloading atingem 100% de pontuações "boas" com um percentil 75 de 364ms. Em contraste, imagens LCP com lazy loading estão entre as mais lentas, com 720ms, tendo 4,3% dos carregamentos de página classificados como "ruins". Imagens sem preloading têm um desempenho quase tão ruim, com 752ms. A conclusão é clara: faça o preloading da sua imagem LCP e nunca use lazy loading nela.

LCP Mobile vs Desktop

A LCP em dispositivos móveis (764ms no percentil 75) é 2x mais lenta do que a LCP em desktops (380ms). Essa lacuna é impulsionada por redes móveis mais lentas e processadores móveis menos potentes. Como o Google usa a indexação mobile-first, a otimização para LCP mobile deve ser a prioridade.

Estatísticas Globais de LCP

De acordo com o HTTP Archive Web Almanac 2025, 62% das páginas mobile globalmente alcançam uma boa pontuação de LCP (abaixo de 2,5 segundos), um aumento em relação aos 44% de 2022. A LCP continua sendo a Core Web Vital mais difícil de passar e é o principal gargalo para as pontuações gerais de CWV. Além disso, 73% dos elementos LCP em dispositivos móveis são imagens, e 16% dos sites mobile cometem o erro de aplicar lazy loading em suas imagens LCP.

Como a LCP é Medida: As Quatro Fases Principais

De acordo com o Google, a Largest Contentful Paint pode ser dividida em 4 subpartes. Entender qual fase está causando o gargalo é essencial para uma otimização eficiente, pois cada fase requer uma correção completamente diferente. Um Time to First Byte (TTFB) lento requer trabalho no lado do servidor, enquanto um atraso lento no carregamento de recursos requer alterações em seu HTML.

O tempo final de LCP de uma página não é um valor único e monolítico. É a soma de quatro subpartes distintas. Entender esse detalhamento é a chave para diagnosticar e corrigir problemas de LCP de forma eficiente.

Aqui está uma análise das quatro fases:

• Time to First Byte (TTFB): Este é o tempo de resposta puro do servidor. Cobre tudo, desde a pesquisa 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 é um problema fundamental que sempre arruinará sua LCP. Em toda a web, sites com LCP ruim gastam em média 2,27 segundos apenas no TTFB, o que é quase todo o limite de 2,5 segundos. Otimizar o TTFB envolve cache no lado do servidor, configuração de CDN e código de back-end eficiente.
• Resource Load Delay: Este é o "gap de descoberta". Ele mede o tempo entre a conclusão do TTFB e o momento em que o navegador realmente começa a baixar o recurso da LCP. Um longo atraso aqui significa que o navegador encontrou o recurso da LCP muito tarde. Este é o sintoma clássico do uso de imagens de fundo em CSS (que o scanner de preload não consegue descobrir) ou renderização no lado do cliente (onde o elemento LCP só aparece após a execução do JavaScript). A correção é garantir que seu elemento LCP esteja no HTML inicial e fazer o preloading da imagem LCP se o navegador não puder descobri-la cedo o suficiente.
• Resource Load Duration: É o tempo que leva para realmente baixar o arquivo do recurso da LCP (a imagem, fonte ou vídeo). Esta fase é toda sobre tamanho de arquivo e condições de rede. Otimizar significa usar formatos de imagem modernos como AVIF ou WebP, implementar imagens responsivas com srcset e servir assets por meio de uma CDN com compressão adequada.
• Element Render Delay: Este é o atraso final. Mede o tempo entre quando o recurso da LCP termina de ser baixado e quando o elemento é totalmente renderizado na tela. Este atraso é quase sempre causado pelo bloqueio da main thread do navegador por outras tarefas, especialmente o processamento de JavaScript. CSS que bloqueia a renderização e scripts síncronos são as causas mais comuns.

Cada uma dessas áreas de foco pode ser otimizada para melhorar a Largest Contentful Paint. Para entender os passos que você precisa tomar, leia Corrigir e Identificar problemas de Largest Contentful Paint (LCP).

Erros Comuns de LCP

Após analisar milhões de carregamentos de página por meio do CoreDash, três erros de LCP aparecem com muito mais frequência do que quaisquer outros. Evitá-los fará com que a maioria dos sites alcance uma pontuação de LCP aprovada.

Erro 1: Lazy Loading da Imagem LCP

Adicionar loading="lazy" à sua imagem hero é o erro de LCP mais comum. O lazy loading diz ao navegador para atrasar intencionalmente o download da imagem até que ela role para a visualização. Para a sua imagem LCP (que já está na viewport), isso cria um atraso totalmente desnecessário. De acordo com os dados do CrUX, 16% dos sites mobile cometem esse erro. Os dados do CoreDash mostram que as imagens LCP com lazy loading têm um percentil 75 de 720ms com 4,3% de experiências ruins, em comparação com 364ms e 0% de experiências ruins para imagens com preloading. Leia nosso guia completo sobre como consertar uma imagem LCP com lazy loading.

Erro 2: Não Fazer o Preloading da Imagem LCP

Mesmo sem o lazy loading, muitos sites falham em informar o navegador sobre a imagem LCP com a devida antecedência. Se a URL da imagem só for descoberta após a análise do CSS ou a execução do JavaScript, o navegador desperdiça centenas de milissegundos antes mesmo de começar a baixar. A correção é adicionar uma dica de preload na seção <head> do seu documento:

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

Isso diz ao navegador para começar a baixar a imagem imediatamente, sem esperar por cálculos de CSS ou layout. Combine isso com fetchpriority="high" para o máximo impacto. Saiba mais em nosso guia para fazer o preload da imagem LCP.

Erro 3: Usar uma Imagem de Fundo CSS para LCP

As imagens de fundo CSS carregadas via background-image: url(...) são invisíveis para o scanner de preload do navegador. O navegador não consegue descobri-las até que tenha baixado o HTML, analisado o CSS e construído a render tree. Isso adiciona um atraso significativo na carga de recursos. De acordo com dados do CrUX, 9% das páginas mobile usam uma imagem de fundo CSS como seu elemento LCP. A solução é usar uma tag <img> padrão em vez disso, com o atributo fetchpriority="high":

<img src="/img/hero.webp"
     alt="Texto alternativo descritivo"
     width="1200"
     height="600"
     fetchpriority="high">

O atributo fetchpriority="high" é um sinal direto ao navegador de que esta imagem é o recurso de maior prioridade na página. Como demonstrado no estudo de caso do Google Flights, esse atributo único pode reduzir a LCP em 700ms. Para um entendimento mais profundo, consulte nosso guia sobre priorização de recursos.

Como Medir a Largest Contentful Paint

A Largest Contentful Paint (LCP) pode ser medida com JavaScript puro, dados de Laboratório (Lab) e ferramentas de Campo (Field). Ambas têm suas vantagens e desvantagens.

Medir a Largest Contentful Paint com JavaScript

Para medir a Largest Contentful Paint (LCP) usando JavaScript, a API Performance Observer oferece uma solução rápida. O seguinte trecho de código demonstra como capturar o tempo da LCP e as informações do elemento:

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 });

Este trecho de código rastreia a entrada de LCP conforme ela é reportada, exibindo seu timestamp e detalhes do elemento no console. Para insights mais extensos, considere usar a Biblioteca Web Vitals.

Medir a Largest Contentful Paint (LCP) no Chrome DevTools

1. Abra o Chrome DevTools pressionando Ctrl+Shift+I (ou Cmd+Option+I no Mac).
2. Navegue até a aba Performance.
3. Recarregue a página para visualizar as Core Web Vitals.

A aba de Performance do DevTools agora exibe informações sobre as Core Web Vitals, incluindo o tempo e o elemento da Largest Contentful Paint.

Medir a Largest Contentful Paint com Ferramentas de Laboratório e de Campo

Vamos ser claros: dados de Laboratório e de Campo servem a dois propósitos diferentes. Você precisa de ambos.

• Dados de campo (RUM e CrUX) são os únicos dados que realmente importam para passar nas Core Web Vitals. É o que seus usuários reais experimentam. O Google usa esses dados de seu conjunto de dados CrUX. Você começa aqui para descobrir se tem um problema.
• Dados de laboratório (Lighthouse, etc.) é um teste controlado. Não é o que o Google usa para ranqueamento, mas é essencial para depuração. Você usa isso para descobrir por que você tem um problema.

Aqui está um guia rápido para as ferramentas essenciais:

Melhorando a Largest Contentful Paint

Otimizar a LCP requer uma abordagem sistemática que aborda as quatro fases. Qualquer coisa que aconteça antes de o elemento LCP ser pintado, seja relacionado à rede ou de uso intensivo da CPU, pode impactar a pontuação de LCP. Não persiga apenas uma correção; compreenda a cadeia inteira. Aqui está a estratégia de alto nível:

• Otimize o TTFB: Seu servidor precisa ser rápido. Se o seu TTFB for lento, nada mais importa. Isso envolve cache no lado do servidor, usar uma CDN e um código de back-end eficiente. Leia mais em nosso guia para otimização de TTFB.
• Elimine o Resource Load Delay: Certifique-se de que o elemento LCP esteja no HTML inicial para que o scanner de preload do navegador possa encontrá-lo instantaneamente. Evite imagens de fundo CSS para a LCP. Faça o preload de imagens críticas que são descobertas tarde. Saiba como em nosso guia sobre como corrigir o Resource Load Delay.
• Reduza o Resource Load Time: Torne o arquivo da LCP menor. Isso significa usar formatos de imagem modernos como AVIF, imagens responsivas e compressão adequada. Veja nosso guia completo sobre como Otimizar a Imagem LCP. Você também pode ler sobre como nós baixamos a LCP em 70% num projeto real.
• Encurte o Element Render Delay: Pare de bloquear a main thread. Adie (defer) JavaScript não crítico, divida tarefas longas e minimize o CSS que bloqueia a renderização. Isso é coberto em nosso guia sobre como corrigir o Element Render Delay.

Guias Relacionados

Esta página central aborda a Largest Contentful Paint em um nível macro. Para orientações práticas e detalhadas sobre cada aspecto da otimização de LCP, explore estes guias dedicados:

• Corrigir e Identificar Problemas de LCP: Um guia de diagnóstico passo a passo para encontrar exatamente o que está causando a lentidão da sua LCP, usando o Chrome DevTools, WebPageTest e CoreDash.
• Otimizar a Imagem LCP: Tudo sobre formatos de imagem, imagens responsivas, compressão e como fornecer a imagem ideal para cada dispositivo.
• Resource Load Delay: Como garantir que o navegador descubra seu recurso LCP o mais cedo possível, incluindo preloading, fetchpriority e como evitar imagens de fundo CSS.
• Resource Load Duration: Redução do tempo real de download do recurso LCP por meio da otimização do tamanho do arquivo, configuração da CDN e compressão moderna.
• Element Render Delay: Eliminação do atraso entre o download do recurso e a renderização na tela, reduzindo o bloqueio da main thread por JavaScript e CSS.