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

O que é o Largest Contentful Paint (LCP)?

O Largest Contentful Paint é uma medição 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 do ecrã. O tempo de LCP indica o tempo em milissegundos entre o pedido da página e quando o maior elemento de conteúdo é exibido na parte visível da página web (acima da dobra).

História do Largest Contentful Paint

Quando se pensa nisso, o LCP pode parecer uma métrica trivial para representar a parte de carregamento dos Core Web Vitals. Porque não medir a velocidade de carregamento como 'o tempo que a página leva para carregar'?

Isso porque é difícil (ou até impossível) na maioria dos websites modernos definir quando a página foi carregada. Cada vez mais websites usam técnicas como lazy loading ou carregamento progressivo onde a página basicamente pode continuar a carregar 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 durante o carregamento da página que podem fazer o utilizador perceber 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 é visível (First Contentful Paint), o momento em que o viewport visível pode parecer completo (Largest Contentful Paint) e quando a página se torna interativa (quando clicar num link se torna possível) são todos pontos durante o processo de carregamento onde o site pode parecer lento ou rápido!

O Largest Contentful Paint (LCP) foi escolhido porque se foca na user experience do visitante. Quando o LCP ocorre, pode-se assumir que o visitante pensa que a página terminou de carregar (mesmo que processos nos bastidores ainda estejam em execução). O LCP foi criado para responder à questão: 'Quando é que o conteúdo de uma página é visível?'. É por isso que o LCP é reconhecido como um indicador central de desempenho centrado no utilizador.

LCP vs FCP: Qual é a Diferença?

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

Pense assim: o FCP indica que a página começou a carregar; o LCP indica que a página parece carregada. O Google escolheu o LCP como Core Web Vital porque reflete com mais precisão o que os utilizadores percecionam como "velocidade".

Para a maioria dos websites, otimizar o LCP deve ser a prioridade. Se o seu LCP for rápido, o seu FCP será quase sempre rápido também, porque o FCP ocorre mais cedo na cronologia de carregamento. O inverso não é verdade: um FCP rápido não garante um LCP rápido.

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

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

• Para SEO. Sim, o Google foca-se em servir as melhores páginas nos seus resultados de pesquisa. O LCP faz parte dos Core Web Vitals do Google. O Google afirma claramente que a velocidade do site é um fator nos resultados de pesquisa.
• Para Visitantes: Segundo pesquisas recentes do próprio Google, a probabilidade de um utilizador abandonar o site duplica com um tempo de carregamento de 3 segundos. Provavelmente reconhece isso por si próprio. Ao navegar na internet, quase nada parece tão irritante quanto um website de carregamento lento. É provável que abandone rapidamente uma página de carregamento lento.
• Outras razões: A velocidade da página é um fator no seu Google Ad Score. Isso significa que pode comprar os seus anúncios mais baratos. Além disso, passar os Core Web Vitals é um dos pré-requisitos para a caixa de Top Story do Google.

Um LCP rápido dá ao visitante a ideia de que a página carrega rapidamente. Como resultado, é menos provável que um visitante navegue para fora da página.

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

A Vodafone Itália realizou uma experiência controlada otimizando a sua pontuação de LCP. Ao reduzir o LCP em 31%, mediram um aumento de 8% nas vendas. Isto 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 focou-se em precarregar a imagem LCP e reduzir recursos que bloqueiam a renderização. Leia o caso de estudo completo da Vodafone no web.dev.

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

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

Que Elementos São Considerados Elementos LCP?

Nem todos os elementos são considerados como um elemento LCP. O maior elemento de conteúdo tem de ser pintado na parte visível do ecrã (o viewport) antes que o utilizador tenha interagido com a página.

O elemento tem de ser:

• Um elemento <img>.
• Um elemento <image> aninhado dentro de um elemento <svg> .
• Um elemento <video> (a imagem poster ou o primeiro frame do vídeo, o que acontecer 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 indetectável pelo scanner de preload do browser. Leia o nosso guia sobre adiar imagens de fundo).

• Um elemento de nível 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 nível de bloco mais próximo <div> ou <p> é considerado).

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

Ficando Técnico: Medindo o Tamanho do Elemento LCP

O LCP identifica o maior elemento de conteúdo visível no viewport e calcula o seu tamanho com base num conjunto de regras precisas. Estas 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 está apenas parcialmente no viewport visível, o tamanho considerado será cortado.
• Sem borda, padding ou margem: Para todos os elementos, bordas de texto e imagem, padding e margens são completamente ignorados.
• Tamanho do texto: Elementos de texto são reportados como o menor retângulo que pode ser pintado à volta 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 no ecrã) é 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, continua a ser um candidato a LCP.

Natureza Dinâmica do LCP

O Largest Contentful Paint (LCP) é uma métrica dinâmica. Embora a renderização possa ser complexa e ocorrer em etapas, é normal que o elemento LCP mude durante o carregamento da página. Antes da primeira interação do utilizador, o performance observer do browser identifica todos os elementos que podem ser considerados candidatos a LCP. Se um novo elemento é renderizado que é tanto visível dentro do viewport como maior que o elemento LCP previamente identificado, torna-se o novo LCP.

Conclusões dos dados de campo de LCP: No CoreDash rastreamos milhões de entradas de LCP por dia. Como se verifica, 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 preciso) os Core Web Vitals passam quando o elemento LCP é um nó de texto ou mesmo uma imagem normal. Quando o elemento LCP é uma imagem de fundo, vídeo ou uma imagem lazy-loaded, os Core Web Vitals tendem a falhar.

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

Para passar os Core Web Vitals para o Largest Contentful Paint, pelo menos 75% dos seus visitantes precisam de ter uma pontuação de LCP 'boa'. Uma pontuação de LCP entre 0 e 2,5 segundos é considerada uma pontuação de LCP boa, 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 fraca.

O que os Dados Reais de LCP Mostram

O CoreDash rastreia milhões de medições reais de LCP de utilizadores todos os dias. Eis o que os dados revelam sobre o desempenho de LCP na web.

LCP de Imagem vs LCP de Texto

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

O Impacto do Preloading e Lazy Loading

Imagens LCP precarregadas alcançam 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, com 4,3% dos carregamentos de página classificados como "fracos". Imagens não precarregadas têm um desempenho quase tão mau com 752ms. A conclusão é clara: precarregue a sua imagem LCP e nunca aplique lazy loading nela.

LCP Mobile vs Desktop

O LCP mobile (764ms no percentil 75) é 2x mais lento que o LCP desktop (380ms). Esta diferença é impulsionada por redes móveis mais lentas e processadores mobile menos potentes. Como o Google usa indexação mobile-first, otimizar o LCP mobile deve ser a prioridade.

Estatísticas Globais de LCP

Segundo 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), acima dos 44% em 2022. O LCP continua a ser o 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 mobile são imagens, e 16% dos sites mobile aplicam erradamente lazy loading na sua imagem LCP.

Como o LCP é Medido: As Quatro Fases Principais

Segundo o Google, o Largest Contentful Paint pode ser dividido em 4 sub-partes. Compreender qual fase está a causar o gargalo é essencial para uma otimização eficiente, porque cada fase requer uma correção completamente diferente. Um Time to First Byte (TTFB) lento precisa de trabalho no lado do servidor, enquanto um atraso no carregamento do recurso precisa de alterações no seu HTML.

O tempo final de LCP de uma página não é um valor único e monolítico. É a soma de quatro sub-partes distintas. Compreender esta divisão é a chave para diagnosticar e corrigir problemas de LCP eficientemente.

Aqui está uma análise das quatro fases:

• Time to First Byte (TTFB): Este é o tempo puro de resposta do servidor. Abrange tudo desde a pesquisa DNS, passando pela conexão TCP/TLS, até ao momento em que o browser recebe o primeiro byte do documento HTML. Um TTFB lento é um problema fundamental que irá sempre prejudicar o seu LCP. Em toda a web, sites com LCP fraco gastam em média 2,27 segundos apenas no TTFB, que é quase todo o limiar de 2,5 segundos. Otimizar o TTFB envolve cache no lado do servidor, configuração de CDN e código backend eficiente.
• Resource Load Delay: Este é o "intervalo de descoberta". Mede o tempo entre a conclusão do TTFB e o browser realmente começar a descarregar o recurso LCP. Um atraso longo aqui significa que o browser encontrou o recurso LCP tarde. Este é o sintoma clássico de usar imagens de fundo 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 de JavaScript). A correção é garantir que o seu elemento LCP está no HTML inicial e precarregar a imagem LCP se o browser não a conseguir descobrir cedo o suficiente.
• Resource Load Duration: Este é o tempo que leva para realmente descarregar o ficheiro do recurso LCP (a imagem, fonte ou vídeo). Esta fase é toda sobre o tamanho do ficheiro e as condições de rede. Otimizar significa usar formatos de imagem modernos como AVIF ou WebP, implementar imagens responsivas com srcset, e servir recursos através de um CDN com compressão adequada.
• Element Render Delay: Este é o atraso final. Mede o tempo entre quando o recurso LCP termina o download e quando o elemento é completamente renderizado no ecrã. Este atraso é quase sempre causado pelo thread principal do browser estar bloqueado por outras tarefas, especialmente processamento de JavaScript. CSS que bloqueia a renderização e scripts síncronos são as causas mais comuns.

Cada uma destas áreas de foco pode ser otimizada para melhorar o Largest Contentful Paint. Para compreender os passos que precisa de 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 através do CoreDash, três erros de LCP aparecem com muito mais frequência do que quaisquer outros. Evitá-los levará a maioria dos sites a uma pontuação de LCP aprovada.

Erro 1: Lazy Loading na Imagem LCP

Adicionar loading="lazy" à sua imagem hero é o erro de LCP mais comum. O lazy loading diz ao browser para atrasar intencionalmente o download da imagem até que ela entre no campo de visão. Para a sua imagem LCP (que já está no viewport), isto cria um atraso totalmente desnecessário. Segundo os dados CrUX, 16% dos sites mobile cometem este erro. Os dados do CoreDash mostram que imagens LCP com lazy loading têm um percentil 75 de 720ms com 4,3% de experiências fracas, comparado com 364ms e 0% fracas para imagens precarregadas. Leia o nosso guia completo sobre como corrigir uma imagem LCP com lazy loading.

Erro 2: Não Precarregar a Imagem LCP

Mesmo sem lazy loading, muitos sites falham em informar o browser sobre a imagem LCP cedo o suficiente. Se o URL da imagem só é descoberto após analisar CSS ou executar JavaScript, o browser desperdiça centenas de milissegundos antes de sequer começar a descarregar. A correção é adicionar uma dica de preload no <head> do seu documento:

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

Isto diz ao browser para começar a descarregar a imagem imediatamente, sem esperar por CSS ou cálculos de layout. Combine com fetchpriority="high" para máximo impacto. Saiba mais no nosso guia para precarregar a imagem LCP.

Erro 3: Usar uma Imagem de Fundo CSS para LCP

Imagens de fundo CSS carregadas via background-image: url(...) são invisíveis para o scanner de preload do browser. O browser não as consegue descobrir até ter descarregado o HTML, analisado o CSS e construído a árvore de renderização. Isto adiciona um atraso significativo no carregamento do recurso. Segundo os dados 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="Descriptive alt text"
     width="1200"
     height="600"
     fetchpriority="high">

O atributo fetchpriority="high" é um sinal direto para o browser de que esta imagem é o recurso de maior prioridade na página. Como o caso de estudo do Google Flights demonstrou, este único atributo pode reduzir o LCP em 700ms. Para uma compreensão mais profunda, consulte o nosso guia de priorização de recursos.

Como Medir o Largest Contentful Paint

O Largest Contentful Paint (LCP) pode ser medido com JavaScript puro, dados de Lab e ferramentas de Campo. Ambos têm as suas vantagens e desvantagens.

Medir o Largest Contentful Paint com JavaScript

Para medir o 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 timing de LCP e 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 rastreia a entrada de LCP à medida que é reportada, exibindo o seu timestamp e detalhes do elemento na consola. Para insights mais extensos, considere usar a Biblioteca Web Vitals.

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. Navegue até ao separador Performance.
3. Recarregue a página para ver os Core Web Vitals.

O separador Performance do DevTools agora exibe informações sobre os Core Web Vitals, incluindo o timing e o elemento do Largest Contentful Paint.

Medir o Largest Contentful Paint com Ferramentas de Lab e Campo

Sejamos claros: dados de Lab e Campo servem dois propósitos diferentes. Precisa de ambos.

• Dados de campo (RUM e CrUX) são os únicos dados que realmente importam para passar os Core Web Vitals. É o que os seus utilizadores reais experienciam. O Google usa estes dados do seu dataset CrUX. Comece aqui para descobrir se tem um problema.
• Dados de lab (Lighthouse, etc.) são um teste controlado. Não é o que o Google usa para ranking, mas é essencial para debugging. Use isto para descobrir porque tem um problema.

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

Melhorar o Largest Contentful Paint

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

• Otimize o TTFB: O seu servidor precisa de ser rápido. Se o seu TTFB é lento, nada mais importa. Isto envolve cache no lado do servidor, usar um CDN e código backend eficiente. Leia mais no nosso guia para otimizar o TTFB.
• Elimine o Resource Load Delay: Garanta que o elemento LCP está no HTML inicial para que o scanner de preload do browser o encontre instantaneamente. Evite imagens de fundo CSS para LCP. Precarregue imagens críticas que são descobertas tarde. Saiba como no nosso guia para corrigir o Resource Load Delay.
• Reduza o Resource Load Time: Torne o ficheiro LCP mais pequeno. Isto significa usar formatos de imagem modernos como AVIF, imagens responsivas e compressão adequada. Veja o nosso guia completo sobre como otimizar a imagem LCP. Pode também ler sobre como reduzimos o LCP em 70% num projeto real.
• Encurte o Element Render Delay: Pare de bloquear o thread principal. Adie JavaScript não-crítico, divida tarefas longas e minimize CSS que bloqueia a renderização. Isto é coberto no nosso guia para corrigir o Element Render Delay.

Guias Relacionados

Esta página hub cobre o Largest Contentful Paint a um nível alto. Para orientação detalhada e prática sobre cada aspeto 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á a causar o seu LCP lento, usando Chrome DevTools, WebPageTest e CoreDash.
• Otimizar a Imagem LCP: Tudo sobre formatos de imagem, imagens responsivas, compressão e servir a imagem ideal para cada dispositivo.
• Resource Load Delay: Como garantir que o browser descobre o seu recurso LCP o mais cedo possível, incluindo preloading, fetchpriority e evitar imagens de fundo CSS.
• Resource Load Duration: Reduzir o tempo real de download do recurso LCP através de otimização do tamanho do ficheiro, configuração de CDN e compressão moderna.
• Element Render Delay: Eliminar o atraso entre o download do recurso e a renderização no ecrã, reduzindo o bloqueio do thread principal por JavaScript e CSS.