Maior Pintura de Conteúdo (LCP)

TL;DR — Largest Contentful Paint (LCP) mede quanto tempo leva para a maior coisa na tela — geralmente uma imagem hero ou um grande bloco de texto — aparecer depois que alguém clica na sua página. Menos de 2,5 segundos é bom. É uma das três Core Web Vitals do Google, e é a que a maioria dos sites tem mais dificuldade.

O que é LCP

A primeira impressão que as pessoas têm do seu site é a velocidade com que ele parece carregar. O LCP tenta colocar um número nisso. Ele mede o tempo necessário para carregar o maior elemento visível no viewport — a parte da página que você pode ver sem rolar.

Esse “maior elemento” geralmente é uma de duas coisas:

• Uma imagem grande — um banner hero, uma foto de produto, uma imagem em destaque.
• Um grande bloco de texto — comum em páginas de artigo que não começam com uma imagem.

O LCP é o momento em que esse elemento termina de renderizar, medido a partir do início do carregamento da página. Quanto menor o número, mais rápida a sua página parece.

A pontuação

O Google divide o LCP em três categorias:

• Bom: 2,5 segundos ou menos
• Precisa de melhorias: 2,5 a 4 segundos
• Ruim: mais de 4 segundos

Você está mirando nessa marca de 2,5 segundos. E é avaliado com base em visitantes reais do seu site, não em um teste que você executa uma vez — então é a experiência que seu público real tem em seus telefones e conexões reais.

Por que pode ser difícil

O LCP é a Core Web Vital com a qual as pessoas mais têm dificuldade. Isso porque tem o maior número de partes móveis: seu servidor precisa responder, o navegador precisa encontrar e baixar a imagem, e então precisa realmente pintá-la. Uma lentidão em qualquer uma dessas etapas arrasta o número inteiro para cima. Comprimir suas imagens é um primeiro palpite comum — e às vezes ajuda — mas muitas vezes não é o gargalo real.

Também é mais difícil no celular do que no desktop, porque os telefones têm conexões mais lentas e menos poder de processamento.

O que fazer primeiro

Três vitórias rápidas que corrigem os erros mais comuns:

1. Não faça lazy-load da sua imagem principal. “Lazy loading” diz ao navegador para esperar antes de buscar uma imagem. Isso é ótimo para coisas lá embaixo na página — mas se você fizer isso com sua imagem hero, você está deliberadamente atrasando a coisa mais importante na tela. Evidence for this claim An LCP image should not be lazy-loaded, and reducing resource load delay is a primary LCP optimization. Scope: web.dev guidance for image-based LCP elements. Confidence: high · Verified: 2026-07-14 web.dev: Optimize LCP
2. Diga ao navegador que a imagem principal é importante — existe um atributo (fetchpriority="high") que faz exatamente isso. Coloque-o na única imagem que é realmente sua candidata a LCP; colocá-lo em várias imagens dilui o sinal.
3. Acelere seu servidor. Se o seu servidor for lento para responder, nada mais que você fizer importa muito.

Quer o modelo mental completo — as quatro subpartes do LCP, como encontrar seu elemento de LCP, as questões de renderização e fontes, e o quanto isso realmente importa para os ranqueamentos? Mude para a aba Avançado.

TL;DR — LCP é o tempo de renderização da maior imagem ou bloco de texto visível no viewport, relativo ao início do carregamento da página. Bom é ≤ 2,5 s no 75º percentil de usuários reais (divididos por dispositivo); 2,5–4 s precisa de trabalho, acima de 4 s é ruim. É uma das três Core Web Vitals e se divide em quatro subpartes — TTFB, atraso de carregamento de recurso, duração de carregamento de recurso, atraso de renderização de elemento — onde TTFB e duração de carregamento geralmente dominam (diretrizes, não proporções fixas — diagnostique sua própria página). Principais correções: nunca faça lazy-load da imagem de LCP, adicione fetchpriority="high" no candidato real, pré-carregue quando não estiver no HTML, elimine CSS/JS que bloqueiam a renderização e corrija o TTFB. É uma métrica de campo — ferramentas de laboratório apenas a aproximam — e o elemento de LCP pode mudar durante o carregamento. O Google confirma que as Core Web Vitals alimentam os sistemas de ranqueamento, mas não publica um peso exato de LCP nem o chama de desempate; a relevância do conteúdo ainda domina.

O que o LCP realmente mede

O LCP informa o tempo de renderização da maior imagem ou bloco de texto visível no viewport, medido em relação ao momento em que o usuário navegou pela primeira vez para a página. O enquadramento do próprio Google: é o proxy padronizado mais próximo de quando o conteúdo principal aparece para o usuário. Ele substituiu métricas anteriores e mais imprecisas, como First Meaningful Paint e Speed Index.

Algumas coisas que confundem as pessoas logo de cara:

• Não é “tempo de carregamento da página”. Uma página pode ter todos os recursos buscados e ainda assim registrar um LCP lento se a renderização do maior elemento foi bloqueada. O LCP diz respeito a esse único elemento, não à página inteira.
• Não é o mesmo que FCP. O First Contentful Paint é acionado quando qualquer conteúdo aparece pela primeira vez; o LCP espera pelo elemento maior. Uma página pode ter um FCP rápido (a barra de navegação é pintada) e um LCP lento (a imagem hero carrega tarde).
• É uma métrica dinâmica. O navegador envia um novo candidato a LCP sempre que um elemento maior se torna visível. A última entrada antes de o usuário interagir (toque, rolagem, tecla) ou de a página ser descarregada é o valor que conta — a interação geralmente muda o que está visível, então o relatório para aí. Um candidato que é posteriormente removido do DOM não apaga a própria entrada — ele continua sendo o elemento informado, a menos que um elemento ainda maior seja renderizado antes de o relatório parar.

Os limites — e por que 2,5 segundos

Avaliado no 75º percentil dos carregamentos de página de usuários reais, segmentado por tipo de dispositivo. Ou seja, três em cada quatro visitas precisam ficar abaixo de 2,5 s para uma origem passar.

Por que 2,5 especificamente? A metodologia de limites do Google se apoiou em duas coisas: pesquisas de percepção humana apontando para aproximadamente 1–3 segundos como a faixa que parece “imediata”, e dados de viabilidade do CrUX mostrando que 2,5 s era consistentemente alcançável para sites bem otimizados sem ser trivialmente fácil. Metas mais apertadas, como 1,5 s ou 2,0 s, não eram consistentemente alcançáveis em origens suficientes, então não entraram no corte.

O que conta como elemento de LCP

Os tipos de elemento considerados para LCP:

• Elementos <img>
• Elementos <image> dentro de um <svg>
• Elementos <video> (o tempo de carregamento da imagem do pôster, ou o primeiro quadro, o que ocorrer antes)
• Um elemento com imagem de fundo carregada via função url() do CSS
• Elementos de nível de bloco contendo nós de texto ou outros filhos de texto inline

O tamanho informado é o que está realmente visível no viewport — porções cortadas ou roladas para fora não contam, e para imagens é o tamanho visível ou o tamanho intrínseco, o que for menor. Margens, preenchimento e bordas são ignorados. Alguns elementos são excluídos por heurísticas: qualquer coisa com opacity: 0, elementos que cobrem todo o viewport (tratados como fundos) e imagens de espaço reservado de baixa entropia.

Cerca de três quartos das páginas têm uma imagem como elemento de LCP — então o trabalho com imagens geralmente é o primeiro passo certo. Mas nem sempre, e nem sempre compressão (mais sobre isso a seguir). O restante são LCPs de texto, onde a alavanca é totalmente diferente: é o carregamento de fontes, não o peso da imagem.

As quatro subpartes — a parte que a maioria dos artigos pula

Este é o framework com o qual eu começaria qualquer diagnóstico de LCP. O web.dev divide o LCP em quatro subpartes sequenciais:

1. Time to First Byte (TTFB) — desde quando o usuário começa a carregar a página até quando o navegador recebe o primeiro byte de HTML. Participação típica: ~40% do LCP total.
2. Atraso no carregamento do recurso — a lacuna entre o TTFB e o navegador começando a carregar o recurso de LCP. Este é o tempo de descoberta. Participação típica: menos de 10%.
3. Duração do carregamento do recurso — quanto tempo o próprio recurso de LCP leva para ser baixado. Participação típica: ~40%.
4. Atraso na renderização do elemento — desde quando o recurso termina de carregar até quando o elemento realmente é pintado. Participação típica: menos de 10%.

O princípio por trás da tabela: a grande maioria do tempo de LCP deve ser gasta carregando o documento HTML e o recurso de LCP. Qualquer trecho em que nenhum deles está carregando é uma oportunidade de melhoria.

O web.dev é explícito que essas porcentagens são diretrizes, não regras estritas — não as converta em metas de segundos absolutos e não force cada página a corresponder à divisão. Elas só são significativas em relação umas às outras, e se o seu LCP já estiver consistentemente dentro de 2,5 segundos, as proporções relativas não importam em nada. Use a tabela para identificar qual subparte está consumindo uma parcela desproporcional na sua página e corrija essa — não para buscar uma divisão exata de 40/10/40/10.

E aqui está o ponto que derruba a suposição comum: a partir de fevereiro de 2025, essas quatro subpartes estão disponíveis na API do CrUX para LCPs de imagem, e a análise da equipe do Chrome dos dados do HTTP Archive descobriu que o tempo de download da imagem era frequentemente a menor parte do tempo de LCP. Em outras palavras, “apenas comprima minhas imagens” frequentemente corrige a subparte errada. TTFB e atraso de descoberta geralmente são as maiores alavancas.

Como encontrar seu elemento de LCP

Antes de otimizar qualquer coisa, descubra qual elemento é o seu LCP e qual subparte é o gargalo:

• PageSpeed Insights — a seção Diagnostics sinaliza o elemento de LCP, e a aba de dados de campo mostra sua pontuação de usuários reais.
• Chrome DevTools — o painel Performance marca o nó de LCP na linha do tempo.
• A biblioteca JS web-vitals — registre o LCP (e o elemento) a partir do seu próprio monitoramento de usuários reais.

Como melhorar o LCP

Mapeie cada correção para a subparte que ela visa:

Corrija o atraso no carregamento do recurso (descoberta). Esta é a de maior alavancagem e a mais comumente quebrada.

• Nunca use lazy-load na sua imagem de LCP. loading="lazy" no elemento de LCP sempre adiciona atraso de carregamento desnecessário. Reserve o lazy loading para imagens abaixo da dobra.
• Adicione fetchpriority="high" à imagem provável de LCP para que o navegador a busque cedo com alta prioridade.
• Pré-carregue-a com <link rel="preload"> quando a imagem não for detectável no HTML inicial — por exemplo, quando ela é carregada via CSS ou JavaScript. Carregar a imagem hero via JS é um anti-padrão precisamente porque esconde a URL do scanner de pré-carregamento do navegador.
• Hospede recursos críticos na mesma origem para que o navegador não pague custo extra de configuração de conexão.

Preload e fetchpriority resolvem problemas diferentes, então não use ambos por hábito. O preload expõe um recurso que o scanner de pré-carregamento do navegador descobriria tarde (uma imagem carregada via JS ou CSS, por exemplo); fetchpriority altera a prioridade de busca de um recurso que o navegador já encontrou. Se a descoberta e a prioridade já estiverem corretas — a imagem é um <img> simples no HTML inicial — adicionar qualquer um pode fazer pouco além de requisições extras. Verifique um trace, aplique o que corresponde ao problema real e confirme que o número de campo mudou.

Corrija o atraso na renderização do elemento.

• Reduza ou inline o CSS que bloqueia a renderização; adie estilos não críticos.
• Evite scripts síncronos no <head>.
• Prefira renderização no servidor ou geração estática para que o markup chegue pronto para pintar, e divida tarefas longas do thread principal.

Reduza a duração do carregamento do recurso.

• Formatos de imagem modernos (WebP, AVIF), compressão sensata e um CDN.
• Cache-Control eficiente. E não ignore a contenção de rede — usar lazy-load nas outras imagens abaixo da dobra pode liberar largura de banda para que a imagem de LCP chegue mais cedo.

Reduza o TTFB.

• Minimize redirecionamentos, remova parâmetros de URL únicos desnecessários e otimize o tempo de resposta do servidor. Observe que o LCP inclui qualquer tempo de descarga da página anterior, configuração de conexão e tempo de redirecionamento — tudo isso entra no TTFB.

Caso especial: LCP baseado em texto. Quando o maior elemento é texto, o caminho crítico é o carregamento de fontes, não o peso da imagem. font-display: optional ou fontes do sistema eliminam o atraso de renderização induzido por fontes; font-display: swap sem pré-carregar o arquivo de fonte pode introduzi-lo.

Lab vs. campo — essa distinção importa

O LCP é fundamentalmente uma métrica de campo. O Google o avalia em usuários reais via CrUX, apresentado na aba de campo do PageSpeed Insights e no relatório Core Web Vitals do Search Console. Esses dados de campo são o que alimenta o ranqueamento.

Ferramentas de laboratório — Lighthouse, Chrome DevTools, WebPageTest — apenas aproximam sob condições simuladas, e elas nem usam a mesma pontuação. O Lighthouse aplica limiares de desktop mais rigorosos (Bom ≤ 1,2 s) do que o padrão de campo (≤ 2,5 s). Portanto, uma pontuação de aprovação no Lighthouse não garante uma pontuação de aprovação no CrUX, e vice-versa. Use ferramentas de laboratório para depurar e reproduzir; confie nos dados de campo para o veredito real.

Há uma segunda razão pela qual os números de laboratório e campo podem divergir, que vale a pena conhecer para que uma leitura estranha não o faça perseguir um bug fantasma: a atual API do navegador LargestContentfulPaint (ainda um Working Draft do W3C) é limitada a um único carregamento de documento. Ela não é redefinida em restaurações do cache de ida e volta (bfcache) ou em navegações SPA no mesmo documento, e páginas que começam fora da tela — abas em segundo plano, páginas pré-renderizadas — podem relatar valores inflados porque o tempo é medido a partir do carregamento, não de quando a página realmente se tornou visível. O algoritmo de relatório também é interrompido em entrada de usuário qualificada, então se um usuário interage antes de seu conteúdo principal ser exibido, o LCP não o capturará. Nada disso muda a tabela de limiares acima; isso explica por que o número de uma sessão específica pode parecer errado quando a navegação subjacente não é um primeiro carregamento simples.

O LCP afeta o ranqueamento?

Sim, no sentido de que o Google confirma que os Core Web Vitals alimentam seus sistemas de ranqueamento e recomenda alcançar boas pontuações. Mas a documentação atual do Search Central não publica um peso exato para o LCP e não o descreve como um desempate — o próprio enquadramento do Google é que a experiência da página “can contribute to success in Search” (tradução) «pode contribuir para o sucesso na Pesquisa» para consultas em que várias páginas já oferecem conteúdo comparável e relevante, e que uma boa pontuação não garante um impulso no ranqueamento. A relevância e a qualidade do conteúdo ainda dominam. Otimize o LCP porque uma página que parece mais rápida é genuinamente melhor para os usuários (e para as conversões) — não porque o mecanismo seja documentado como um desempate de ranqueamento, porque não é.

Algumas realidades dos dados: dos Core Web Vitals, o LCP é o que os sites mais têm dificuldade em melhorar, e é visivelmente mais difícil no mobile do que no desktop — CPUs e conexões mais lentas. Em 3G ou mais lento, o limiar de 2,5 s pode parecer quase impossível de alcançar.

Onde isso se encaixa

O LCP é um dos três Core Web Vitals, ao lado de Interaction to Next Paint e Cumulative Layout Shift. Sua primeira subparte, Time to First Byte, é sua própria métrica de diagnóstico, e First Contentful Paint fica logo ao lado na linha do tempo de carregamento. Você verá todos esses no PageSpeed Insights, no Lighthouse e no Chrome User Experience Report (CrUX). Cada um é um mergulho profundo próprio neste cluster.

Resumo de IA

Uma visão condensada da versão Avançada:

• LCP = tempo de renderização do maior bloco visível de imagem ou texto, relativo ao momento em que a página começou a carregar. É o proxy padronizado mais próximo de “quando o conteúdo principal aparece”.
• Limiares: Bom ≤ 2,5 s, Precisa de melhorias 2,5–4 s, Ruim > 4 s — no 75º percentil de usuários reais, dividido por dispositivo. É uma das três Core Web Vitals.
• Não é tempo de carregamento da página, nem FCP. FCP = primeiro pixel de qualquer conteúdo; LCP = o maior elemento. LCP também é dinâmico — o maior candidato pode mudar durante o carregamento; o último antes da interação do usuário conta.
• Elementos de LCP: <img>, <image> em <svg>, poster de <video>, CSS background-image: url(), ou um elemento de texto em nível de bloco. ~3 em cada 4 páginas têm LCP de imagem; o restante é texto (onde fontes, não o peso da imagem, são a alavanca).
• Quatro subpartes: TTFB (~40%), atraso de carregamento do recurso (<10%), duração do carregamento do recurso (~40%), atraso de renderização do elemento (<10%) — o web.dev chama essas diretrizes, não parcelas fixas; diagnostique por página em vez de buscar uma divisão exata. Dados CrUX 2025: o download da imagem costuma ser a parte menor — então “apenas comprima imagens” muitas vezes corrige a coisa errada.
• Principais correções: nunca faça lazy-load da imagem de LCP; adicione fetchpriority="high" no candidato real; pré-carregue quando ela não estiver no HTML (pré-carregamento e fetchpriority resolvem problemas diferentes — não use ambos por hábito); reduza CSS/JS que bloqueiam a renderização; reduza o TTFB.
• Campo, não laboratório. CrUX/Search Console impulsionam o ranqueamento; Lighthouse apenas aproxima e usa limiares de desktop mais rígidos (≤ 1,2 s). A API atual LargestContentfulPaint é limitada a carregamentos de documento e não é redefinida para restaurações de bfcache ou navegações SPA no mesmo documento.
• Ranqueamento: o Google confirma que os sistemas de ranqueamento de CWV alimentam os resultados, mas não publica um peso exato para LCP e não o chama de desempate; a relevância do conteúdo ainda domina. É a CWV mais difícil de melhorar, e mais difícil no mobile.

Documentação oficial

Orientação de fonte primária das equipes de Chrome e Search do Google.

web.dev (equipe do Chrome)

• Maior Pintura de Conteúdo (LCP) — a definição canônica: o que conta como elemento de LCP, como o tamanho é calculado, quando o relatório para e as APIs de medição.
• Otimize o Largest Contentful Paint — a estrutura das quatro subpartes e o manual completo de otimização.
• Core Web Vitals — onde o LCP se encaixa entre as três Core Web Vitals.
• Como foram definidos os limiares das métricas Core Web Vitals — a pesquisa e os dados de viabilidade por trás da marca de 2,5 s.

Equipe do Chrome

• Subpartes de imagem do LCP e RTT agora disponíveis no CrUX — o lançamento de dados de campo de fev de 2025 das quatro subpartes (apenas LCPs de imagem).
• Maior Pintura de Conteúdo | Lighthouse — a métrica de laboratório e sua pontuação específica por dispositivo.

Google Search Central

• Entendendo os Core Web Vitals e os resultados de pesquisa do Google — como as Core Web Vitals influenciam a Pesquisa.

Citações da fonte

Declarações registradas da documentação e da equipe do Google. Cada link é um link profundo que salta para a passagem citada.

web.dev — definição e comportamento (Philip Walton & Barry Pollard, Google)

• “LCP reports the render time of the largest image, text block, or video visible in the viewport, measured relative to when the user first navigated to the page.” (tradução) «O LCP informa o tempo de renderização da maior imagem, bloco de texto ou vídeo visível no viewport, medido em relação ao momento em que o usuário navegou pela primeira vez para a página.» Ir para a citação
• Sobre o que é medido: “LCP doesn’t consider margins, paddings, or borders applied using CSS.” (tradução) «O LCP não considera margens, preenchimentos ou bordas aplicados usando CSS.» Ir para a citação
• Sobre quando o relatório para: “The browser will stop reporting new entries as soon as the user interacts with the page (via a tap, scroll, or keypress), as user interaction often changes what’s visible to the user.” (tradução) «O navegador para de reportar novas entradas assim que o usuário interage com a página (por meio de toque, rolagem ou tecla), pois a interação do usuário frequentemente altera o que está visível para ele.» Ir para a citação
• Sobre o que está incluído no tempo: “It is important to note that LCP includes any unload time from the previous page, connection set up time, redirect time, and other Time To First Byte (TTFB) delays.” (tradução) «É importante observar que o LCP inclui qualquer tempo de descarga da página anterior, tempo de configuração da conexão, tempo de redirecionamento e outros atrasos de Time To First Byte (TTFB).» Ir para a citação

web.dev — otimização (Philip Walton & Barry Pollard, Google)

• A regra mais importante de lazy-loading: “Never lazy-load your LCP image, as that will always lead to unnecessary resource load delay.” (tradução) «Nunca faça lazy-load da sua imagem de LCP, pois isso sempre levará a um atraso desnecessário no carregamento do recurso.» Ir para a citação
• O princípio por trás das metas das subpartes: “The vast majority of the LCP time should be spent loading the HTML document and LCP source.” (tradução) «A grande maioria do tempo de LCP deve ser gasta carregando o documento HTML e a fonte do LCP.» Ir para a citação

Google Search Central — rankings

• “We highly recommend site owners achieve good Core Web Vitals for success with Search and to ensure a great user experience generally.” (tradução) «Recomendamos fortemente que os proprietários de sites alcancem bons Core Web Vitals para obter sucesso na Pesquisa e garantir uma ótima experiência do usuário em geral.» (Transmitido do documento Core Web Vitals do Search Central; confirme na página ao vivo antes de tratar como definitivo.)

Lista de verificação de correção do LCP

Trabalhe de cima para baixo — descoberta e TTFB primeiro, porque geralmente são as alavancas maiores e mais comumente quebradas.

• Encontrou o elemento LCP real (Diagnostics do PageSpeed Insights, painel Performance do DevTools ou a biblioteca web-vitals) — não otimize às cegas.
• Verificou as quatro subpartes para ver qual é o gargalo antes de mudar qualquer coisa.
• A imagem LCP não está com loading="lazy" (lazy loading é só para conteúdo abaixo da dobra).
• A imagem LCP tem fetchpriority="high".
• A imagem LCP é detectável no HTML inicial — ou pré-carregada (<link rel="preload">) se for carregada via CSS/JS.
• Não está carregando a imagem hero via JavaScript (isso a esconde do scanner de pré-carregamento).
• CSS que bloqueia a renderização minimizado/inline; estilos não críticos adiados.
• Nenhum script síncrono no <head>; tarefas longas divididas.
• Formato de imagem moderno (WebP/AVIF), compressão sensata, servido via CDN com bom Cache-Control.
• Imagens abaixo da dobra com lazy loading para não competirem por largura de banda com a imagem LCP.
• TTFB tratado: redirecionamentos minimizados, resposta do servidor otimizada, parâmetros de URL inúteis removidos.
• LCP de texto? Usando font-display: optional ou fontes do sistema, e pré-carregando qualquer arquivo de fonte trocado.
• Verificado com dados de campo (CrUX / Search Console), não apenas com um teste de laboratório do Lighthouse.

Folha de consulta rápida de LCP

Limites (percentil 75 dos usuários reais, por dispositivo)

As quatro subpartes — o que cada uma é e a correção

O que pode ser o elemento LCP

• <img> · <image> dentro de <svg> · poster de <video> · CSS background-image: url() · texto em nível de bloco

Excluídos por heurística: opacity: 0, elementos de “fundo” em viewport inteiro, placeholders de baixa entropia.

Fatos rápidos

• LCP é uma métrica de campo (CrUX / Search Console impulsionam o ranqueamento); o Lighthouse só aproxima e usa um limite de Bom mais rigoroso para desktop, de ≤ 1,2 s.
• O elemento LCP pode mudar durante o carregamento; o último candidato antes da interação do usuário é o que conta.
• ~3 em cada 4 páginas têm LCP de imagem; o restante é texto (fontes são a alavanca).
• O tempo de download da imagem costuma ser a menor subparte — compressão nem sempre é a resposta.
• LCP ≠ FCP; LCP ≠ tempo total de carregamento da página.

Ferramentas para medir e corrigir LCP

Dados de campo (o que o ranqueamento usa)

• PageSpeed Insights — a aba de campo mostra seu LCP CrUX de usuários reais; o Diagnostics sinaliza o elemento LCP.
• Search Console — relatório Core Web Vitals — status do LCP nas suas URLs, agrupado, com dados de usuários reais.
• Chrome User Experience Report (CrUX) — o conjunto de dados de campo subjacente; desde fev/2025 inclui as quatro subpartes de LCP de imagem via API.
• Biblioteca JS web-vitals — registre o LCP e o elemento LCP do seu próprio monitoramento de usuários reais.

Dados de laboratório (para depuração)

• Lighthouse — LCP de laboratório rápido e uma lista de oportunidades (lembre: limites de desktop mais rigorosos que os de campo).
• Chrome DevTools — painel Performance — marca o nó LCP e a linha do tempo completa de renderização.
• WebPageTest — visualização em cascata para identificar qual subparte está lenta.

Crawlers de SEO

• Ahrefs Site Audit — revela problemas de Core Web Vitals / performance no site em escala.

Como as próprias ferramentas pontuam

Um exemplo ao vivo da métrica que esta página descreve — serviços conhecidos de velocidade de página e monitoramento ranqueados pelo próprio LCP móvel de usuários reais (dados de campo do Chrome UX Report):

Correções de LCP que miram o problema errado

Carregamento lento da imagem hero

loading="lazy" atrasa a descoberta de uma imagem acima da dobra que provavelmente se tornará LCP. Carregue-a com prioridade, dê ao candidato provável fetchpriority="high" e reserve o carregamento lento para imagens abaixo da dobra.

Comprimindo todas as imagens antes de encontrar o gargalo

A duração do download da imagem é apenas uma das quatro subpartes do LCP e pode ser a menor. Identifique o elemento LCP e inspecione TTFB, atraso de carregamento, duração do carregamento e atraso de renderização antes de escolher uma correção.

Carregando a imagem hero via JavaScript

Uma imagem injetada por JS esconde sua URL do scanner de pré-carregamento do navegador e cria atraso no carregamento do recurso. Coloque a imagem no HTML inicial ou pré-carregue-a quando CSS ou JS devem possuí-la.

Declarando vitória com uma única execução do Lighthouse

O Lighthouse é um diagnóstico controlado, enquanto o veredito de CWV do Google vem dos dados de campo do CrUX. Use execuções de laboratório para verificar o mecanismo e aguarde os dados de usuários reais para mostrar se o resultado p75 melhorou.

O recurso LCP começa tarde

Sintoma: um longo intervalo aparece entre TTFB e a solicitação do recurso LCP. Causa provável: carregamento lento, descoberta via JS, imagem de fundo CSS ou baixa prioridade de busca. Correção: torne o recurso descobrível no HTML inicial, remova o carregamento lento, aplique fetchpriority="high" ou pré-carregue-o. Confirme que a solicitação se move para mais cedo em um trace.

O recurso carrega, mas o LCP ainda dispara tarde

Sintoma: a duração do carregamento termina bem antes do evento LCP. Causa provável: CSS que bloqueia a renderização, JavaScript síncrono, uma tarefa longa ou renderização de fonte para um LCP de texto. Correção: reduza o trabalho de bloqueio e teste a estratégia de fonte para texto; confirme que o atraso de renderização do elemento encolhe.

LCP de laboratório é bom, mas LCP de campo é ruim

Sintoma: o Lighthouse passa enquanto o CrUX ou o Search Console não. Causa provável: usuários reais têm dispositivos, redes, estados de cache, geografia ou elementos LCP diferentes. Correção: segmente os dados de campo, capture detalhes de elemento/subparte do RUM e reproduza o segmento lento em vez de ajustar apenas o perfil de laboratório padrão.

O elemento LCP relatado muda entre execuções

Sintoma: o DevTools identifica diferentes imagens ou blocos de texto. Causa provável: breakpoints responsivos, personalização, mudanças tardias no DOM ou candidatos concorrentes. Correção: teste viewports e estados representativos e otimize cada candidato recorrente em vez de assumir que um hero de desktop cobre todos os usuários.

Descoberta da imagem hero: atrasada vs. antecipada

Uma implementação atrasada simplificada esconde a imagem atrás de JavaScript:

<div id="hero"></div>
<script>
  document.querySelector('#hero').innerHTML = '<img src="hero.webp" alt="">';
</script>

O navegador pode descobrir e priorizar esta versão enquanto analisa o HTML:

<img src="hero.webp" alt="" fetchpriority="high" width="1200" height="675">

Imagem de fundo CSS: não divulgada vs. pré-carregada

Quando a imagem LCP deve permanecer como fundo CSS, divulgue-a antes que a folha de estilo termine:

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

O pré-carregamento só ajuda quando sua URL e atributos de solicitação correspondem ao recurso real.

Listar candidatos LCP recentes no Chrome DevTools

Cole isto no Console do Chrome DevTools, recarregue a página e observe cada candidato que o navegador relata. O último candidato antes da interação é o relevante.

new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    console.table({
      lcp: Math.round(entry.startTime),
      element: entry.element?.tagName,
      url: entry.url || '',
      size: entry.size,
    });
  }
}).observe({ type: 'largest-contentful-paint', buffered: true });

Encontrar imagens acima da dobra provavelmente com carregamento lento

Execute isto no Console do DevTools. Ele lista imagens lentas cuja borda superior começa no viewport atual; verifique o candidato LCP real antes de remover o atributo.

[...document.querySelectorAll('img[loading="lazy"]')]
  .filter((img) => img.getBoundingClientRect().top < innerHeight)
  .map((img) => ({ src: img.currentSrc || img.src, top: img.getBoundingClientRect().top }));

Extrair atributos de prioridade de imagem em um crawler

Use este XPath na extração personalizada do Screaming Frog para retornar imagens marcadas como alta prioridade:

//img[@fetchpriority='high']/@src

Provar que uma correção de LCP foi aplicada

Teste de ordem de descoberta

Teste a executar: grave um trace de Performance do DevTools após alterar a imagem hero. Resultado esperado: a solicitação LCP começa mais cedo e não é carregada lentamente. Interpretação de falha: o recurso permanece oculto, com prioridade reduzida ou bloqueado atrás de outra dependência. Janela de monitoramento: resultado de laboratório imediato. Gatilho de reversão: a alteração atrasa outro recurso crítico ou torna o LCP de laboratório consistentemente pior.

Teste de atraso de renderização

Teste a executar: compare a conclusão do recurso LCP e o evento LCP em rastreamentos antes/depois equivalentes. Resultado esperado: o atraso de renderização do elemento diminui sem nova regressão de layout ou visual. Interpretação de falha: CSS, JavaScript ou fontes ainda bloqueiam a pintura. Janela de monitoramento: imediata em viewports representativas. Gatilho de reversão: renderização quebrada, estilos ausentes ou LCP recorrente pior.

Teste de resultado de campo

Teste a executar: monitore o LCP p75 no nível de URL via CrUX ou RUM de primeira parte após a implantação. Resultado esperado: o p75 se move em direção ou permanece dentro do limite Bom sem regredir INP ou CLS. Interpretação de falha: o caso de laboratório não era representativo ou outra subparte domina as visitas reais. Janela de monitoramento: o RUM pode liderar; o CrUX precisa que sua janela contínua de 28 dias se renove. Gatilho de reversão: uma regressão de campo sustentada ligada ao lançamento.

Métricas de LCP que valem a pena acompanhar

LCP p75 de campo

Métrica: LCP no 75º percentil por fator de forma. O que isso indica: se usuários reais atendem ao limite de carregamento do Core Web Vitals. Como obter: CrUX, Search Console ou RUM de primeira parte. Referência / faixa realista: Bom é igual ou inferior a 2,5 segundos; segmente mobile e desktop. Cadência: semanal, com a janela contínua do CrUX registrada.

Distribuição de subpartes do LCP

Métrica: TTFB, atraso de carregamento de recurso, duração de carregamento e atraso de renderização de elemento para LCP. O que isso indica: qual estágio é responsável pela espera. Como obter: rastreamentos de laboratório representativos e subpartes de LCP de imagem do CrUX/RUM quando disponíveis. Referência / faixa realista: use a divisão diagnóstica aproximada de 40/10/40/10 do artigo como guia, não como promessa universal de desempenho. Cadência: após lançamentos de template e mensalmente para templates prioritários.

Cobertura de URLs com LCP Bom

Métrica: grupos de URLs importantes com LCP de campo Bom. O que isso indica: se a melhoria é ampla ou limitada a uma página de amostra. Como obter: grupos CWV do Search Console mais LCP no nível de URL do CrUX para páginas prioritárias. Referência / faixa realista: estabeleça uma linha de base por template; URLs de baixo tráfego podem não ter dados de campo individuais. Cadência: semanal.

Teste-se: Largest Contentful Paint

Cinco perguntas rápidas sobre medição e diagnóstico de LCP. Escolha uma resposta para cada uma e depois confira.

Recursos que valem seu tempo

Meus escritos relacionados

• O que é Largest Contentful Paint (LCP) e como melhorá-lo — meu guia completo de LCP no blog da Ahrefs.
• O que são Core Web Vitals (CWVs) e como melhorá-los — como o LCP se encaixa com INP e CLS, e por que é o mais difícil de corrigir.
• Guia para iniciantes em SEO técnico — onde o desempenho da página se encaixa no panorama geral.

Oficial (Google / Chrome)

• Maior Pintura de Conteúdo (LCP) e Otimize o LCP — o par canônico.
• Como foram definidos os limiares das métricas CWV — o porquê por trás de 2,5 s.

De outros

• Corrija o Largest Contentful Paint do seu site otimizando o carregamento de imagens — a abordagem voltada para desenvolvedores da MDN, forte em contenção de largura de banda e no anti-padrão de imagem via JS.
• Desempenho — Web Almanac 2025 — o mergulho anual do HTTP Archive; fonte para estatísticas de adoção de fetchpriority, uso de preload, divisão de LCP por imagem vs texto e taxas de aprovação por dispositivo.
• Largest Contentful Paint (LCP) — a documentação da DebugBear cobre análise de waterfall para identificar subpartes, ressalvas de JPEG progressivo e casos extremos de iframe/navegação suave.
• Largest Contentful Paint (LCP): o que é, como medir e otimizar — corewebvitals.io; benchmarks reais de RUM, estudos de caso de impacto nos negócios (Vodafone Itália) e o resultado do fetchpriority do Google Flights.
• Largest Contentful Paint | Documentação MDN Web Docs — referência da MDN para a API LargestContentfulPaint, tipos de elemento e compatibilidade com navegadores.

Estatísticas que valem citar

• LCP é o Core Web Vital mais difícil de passar. Tem mais componentes, por isso os sites sofrem mais com ele do que com INP ou CLS. Fonte
• Mobile é mais difícil que desktop. CPUs e conexões mais lentas aumentam o LCP, e em conexões 3G/lentas o limite de 2,5 s é quase impossível de atingir. Fonte
• O tempo de download da imagem costuma ser a parte menor do LCP. A análise do Chrome dos dados do HTTP Archive descobriu que a duração do download frequentemente não é o gargalo — TTFB e atraso de descoberta geralmente são. Fonte
• A cobertura do CrUX é limitada. Em nosso estudo de 42 milhões de páginas, apenas ~11,4% tinham dados de campo do CrUX associados — a maioria das páginas não recebe tráfego real de usuários suficiente para ser medida. Fonte
• 62% das páginas mobile vs 74% das páginas desktop alcançam LCP Bom (2025 Web Almanac). A diferença no mobile reflete CPUs e conexões de rede mais lentas. Fonte
• Apenas 2,1% das páginas mobile fazem preload da imagem de LCP, apesar de 76% terem uma imagem como elemento de LCP — uma oportunidade significativa de otimização perdida (2025 Web Almanac). Fonte
• A adoção de fetchpriority="high" cresceu de 0,03% dos sites mobile em 2022 para 17,3% em 2025, impulsionada em grande parte pelo WordPress core adicionando o atributo (2025 Web Almanac). O Google Flights viu uma melhoria de 700 ms no LCP com esse único atributo. Fonte

Vídeos

• Google Search Central (YouTube) — os explicadores de Core Web Vitals e experiência de página, incluindo walkthroughs da equipe do Chrome sobre otimização de LCP. Canal

Registro de alterações