Como otimizar LCP - Guia Core Web Vitals
LCP (Largest Contentful Paint) mede o tempo até o maior elemento visível da página ser renderizado, e o Google considera bom qualquer valor abaixo de 2,5 segundos em field data. Em julho de 2025, 62,3% dos sites móveis e 74,4% dos desktops passavam nesse critério segundo o Chrome User Experience Report, uma melhoria expressiva desde 2022, quando o índice mobile era de apenas 44%. A maioria dos sites que ainda falha em LCP não falha por causa de uma única coisa pesada, mas pela soma de TTFB (Time to First Byte, ou Tempo até o primeiro byte) lento, recurso descoberto tarde pelo navegador e atraso de renderização. Este artigo decompõe LCP nas suas quatro sub-partes oficiais, mostra como diagnosticar cada uma e detalha as correções com impacto real, incluindo fetchpriority, Speculation Rules e Early Hints.
Para o panorama completo das três métricas, veja antes Como medir, diagnosticar e otimizar Core Web Vitals. Para as as outras métricas do CWV, Como otimizar INP e Como otimizar CLS.
O que LCP mede e o que ele não mede
LCP marca o ponto no tempo em que o maior elemento de conteúdo visível na viewport termina de renderizar, contado a partir do momento em que o usuário navegou para a página. O navegador considera como candidatos quatro tipos de elemento: imagens (<img> ou <image> em SVG), elementos com background-image em CSS, vídeos com poster definido, e blocos de texto, incluiindo headings e parágrafos. À medida que a página carrega, o navegador identifica o maior desses elementos e dispara um evento de LCP (que pode ser substituído por um elemento maior até que o usuário interaja com a página).
A confusão mais comum sobre LCP é tratá-la como "tempo de carregamento da página". Não é isso. LCP não considera o que existe abaixo da dobra, não considera elementos invisíveis nem opacidade zero, e termina antes da página estar totalmente carregada na maioria dos casos. Para uma métrica que considere experiência completa de uso, a referência é INP (Interaction to Next Paint), que mede responsividade ao longo de toda a sessão. LCP é uma métrica de percepção inicial, o usuário olha a tela e decide se a página "carregou" baseado no que vê acima da dobra.
Os limites oficiais aplicados pelo Google são os seguintes:
| Status | Valor de LCP |
|---|---|
| Bom | até 2,5s |
| Precisa de melhorias | 2,5s a 4s |
| Ruim | acima de 4s |
O percentil de referência é p75, ou seja, 75% das sessões reais precisam estar abaixo de 2,5s para que o site seja classificado como "Bom" em LCP no Search Console.
As quatro sub-partes do LCP segundo o Google
Desde fevereiro de 2024, o Chrome User Experience Report passou a expor LCP em quatro sub-partes oficiais, cada uma com causa raiz distinta e estratégia de correção específica.
| Sub-parte | O que mede | Alvo do Google | Causa típica de excesso |
|---|---|---|---|
| TTFB | Tempo até o primeiro byte do HTML chegar ao navegador | < 800ms | Backend lento, ausência de CDN, falta de cache |
| Resource Load Delay | Tempo entre TTFB e início do download do recurso LCP | < 10% do LCP total | LCP descoberto tarde pelo preload scanner |
| Resource Load Duration | Tempo de download do recurso LCP | ~40% do LCP total (para imagens) | Imagem grande, sem WebP/AVIF, sem responsive |
| Element Render Delay | Tempo entre o recurso baixar e o navegador pintar | < 10% do LCP total | CSS render-blocking, JavaScript executando antes do paint |
Há duas notas críticas. As sub-partes Load Delay e Load Duration só existem quando o LCP é uma imagem ou vídeo. Se o LCP da sua página é um bloco de texto, como é comum em landing pages e blogs, apenas TTFB e Render Delay aparecem no relatório, e os outros dois ficam zerados. A soma das fases delay (Load Delay + Render Delay) deveria ficar abaixo de 20% do LCP total, segundo a recomendação do Chrome team. Quando passa disso, há otimização significativa disponível.
A consequência prática dessa decomposição é importante: páginas com LCP ruim em texto são problema diferente de pages com LCP ruim em imagem. Para texto, o gargalo está em servidor lento ou em recursos render-blocking. Para imagem, o gargalo geralmente está em load delay, quando o navegador descobriu a imagem tarde demais.
Como medir LCP corretamente
Existem três caminhos com nível crescente de fidelidade, e cada um responde a uma pergunta diferente:
- Lighthouse e PageSpeed Insights. Medem LCP em ambiente controlado (Chrome headless, hardware padrão, rede simulada). Útil para diagnosticar gargalos específicos em pré-produção e validar correções antes do deploy. Mostra também o elemento LCP identificado e, desde 2024, a decomposição em sub-partes na seção "Diagnostics".
- Chrome User Experience Report (CrUX) via Search Console. Mostra LCP de usuários reais agregado em janelas de 28 dias. É o que efetivamente pesa para ranqueamento. Disponível apenas para sites com volume suficiente de tráfego Chrome (sites com menos de aproximadamente 1.000 visitas mensais via Chrome não terão dados).
- Performance Observer API com o evento
largest-contentful-paintÉ como você coleta o LCP no seu próprio sistema de monitoramento, capturando um a um os eventos disparados no navegador dos usuários reais. Como o dado é seu, dá pra recortar do jeito que quiser, por template de página, por país, por tipo de dispositivo, etc., algo que o CrUX, por trabalhar com dados agregados, não permite. A biblioteca web-vitals do Google Chrome já implementa essa API pronta e cuida dos detalhes de medição. Ela oferece ainda uma variante chamada attribution build, que retorna não só o valor final do LCP, mas também a decomposição dele, qual elemento foi o candidato, quanto tempo cada fase do carregamento consumiu.
A combinação mais útil em produção é PageSpeed para diagnóstico pontual + CrUX para visão consolidada + API para alertas e segmentação. Sites com tráfego baixo dependem mais de Lighthouse e API, já que CrUX não terá amostra suficiente.
Por que sites com bom Lighthouse falham em LCP no Search Console
Esta é uma das dúvidas mais frequentes a respeito dos componentes do Core Web Vitals. O Lighthouse aponta LCP de 1,8 segundo, o Search Console reporta 3,2 segundos. Quem está certo?
Ambos. Lighthouse mede em ambiente simulado: rede 4G estável, CPU padrão, Chrome headless sem extensões, primeiro acesso sem cache. O Search Console reporta field data com usuários reais, em dispositivos Android medianos, em conexões variáveis, com cookies aceitos, com extensões instaladas, em horários de pico de tráfego no servidor. A divergência entre os dois é normal.
O caso mais comum por trás dessa divergência é a página ter LCP ruim em um segmento específico de usuários. Pode ser usuários de regiões do interior do Brasil acessando um servidor concentrado em São Paulo ou usuários utilizando dispositivos mais antigos, como celulares Android de 4–5 anos, dominantes em segmentos populares. O Lighthouse passa, mas o p75 do CrUX reflete a cauda dessa distribuição. Para diagnosticar, o caminho é abrir o relatório de Core Web Vitals do Search Console, filtrar por device type e por país, e procurar onde a média está sendo puxada.
As correções de LCP com maior impacto
1. fetchpriority="high" na imagem hero
A correção isolada com maior efeito em LCP quando o elemento é uma imagem. Em um teste oficial do Google em sua própria página de Flights, adicionar fetchpriority="high" reduziu LCP de 2,6 para 1,9 segundo — uma melhoria de 700ms. Outros sites reportam ganhos de 20–30% em casos onde o hero competia com slider, script ou imagem decorativa.
A sintaxe é direta: <img src="hero.webp" fetchpriority="high" width="..." height="...">. Há três regras para uso correto dessa propriedade:
- Aplicar em apenas um elemento por página. Usar em múltiplas imagens anula o efeito, porque o navegador trata tudo como prioridade normal.
- Se o hero é
background-imageem CSS, trocar para<img>. Background images não são descobertas pelo preload scanner do navegador. - A partir do WordPress 6.3, o sistema tenta adicionar
fetchpriority="high"automaticamente na imagem que entende como LCP. Isso funciona em sites simples, mas em temas customizados e page builders frequentemente erra o alvo. Vale validar manualmente no DevTools.
2. CDN com cache de hero e do HTML
Para sites brasileiros com origem em São Paulo e audiência distribuída por todo o país, ativar CDN segue sendo uma das correções isoladas com maior efeito sobre TTFB e, portanto, sobre LCP, já que TTFB é a primeira fase da métrica. A latência entre estados com infraestrutura menos densa e um servidor em São Paulo via roteamento padrão tem um custo de dezenas de milissegundos, contra menos de 20 ms na mediana do Sudeste e Sul. Roraima é hoje o caso mais extremo, com latência de ~90ms, seguida por Amapá e Acre de acordo com o Mapa de Qualidade da Internet do NIC.br.
CDNs como Cloudflare, Fastly e BunnyCDN cobrem a maioria dos CMS tradicionais e têm presença no Brasil. O passo seguinte é garantir que o CDN está fazendo cache do HTML para usuários anônimos, não só dos assets. Para conteúdo institucional e e-commerce com catálogo estável, esse ajuste faz bastante diferença.
3. Speculation Rules API para prerender da próxima navegação
A correção que praticamente zera LCP para a segunda página visitada. O Speculation Rules API permite ao site instruir o navegador a prerenderizar páginas que o usuário provavelmente vai acessar. Quando o usuário clica no link, a página já está pronta e o LCP cai para próximo de zero milissegundos.
A API é suportada em Chrome 122+ e Edge, mas é ignorada por Safari e Firefox. Em estatística agregada de tráfego no Brasil, isso cobre cerca de 65–70% dos usuários. O Google Search adotou prefetch via Speculation Rules em desktop em setembro de 2024, e Astro, Next.js e outras frameworks oferecem integração nativa desde 2024.
Cuidado relevante: prerender executa JavaScript, e portanto analytics, pixels de campanha e A/B testing tools podem disparar antes do usuário efetivamente chegar à página. Tratar com a Page Visibility API ou condicional baseado em document.prerendering evita inflar métricas falsamente.
4. 103 Early Hints para hero descoberto tarde
O 103 Early Hints é um status code HTTP informativo (família 1xx) que o servidor envia antes da resposta final (200, 404 etc.), enquanto ainda está processando a requisição. Para casos em que o LCP é uma imagem injetada via CSS ou descoberta depois de scripts e stylesheets no HTML, o cabeçalho HTTP 103 Early Hints permite ao servidor enviar dicas de preload antes mesmo da resposta principal chegar. É suportado por Chrome, Edge e Firefox e o Cloudflare ativa Early Hints automaticamente para clientes em plano Pro+. Para sites que servem hero como background image, é a forma mais limpa de antecipar o download sem mexer no markup da página. Safari 17+ suporta apenas preconnect, mas não suporta preload em respostas 103.
5. Imagens em formato moderno e responsivo
Continua sendo correção fundamental, mesmo em 2026. Três providências que vão direto em Resource Load Duration:
- Servir WebP ou AVIF como formato padrão, com fallback PNG/JPEG via
<picture>para navegadores antigos. - Usar
srcsetcomsizespara servir resolução adequada por dispositivo. Imagem 1920×1080 servida para celular é desperdício de banda, tempo de download e LCP. - Lazy load em tudo abaixo da dobra. Nunca aplicar
loading="lazy"na imagem LCP, isso atrasa o início do download e degrada a métrica.
A validação direta é abrir o DevTools no painel Network, comparar a coluna "Resource Size" (tamanho real) com "Transferred" (tamanho enviado) na imagem hero. Se há diferença grande, há otimização disponível.
O que mudou em LCP entre 2024 e 2026
Fevereiro 2024. Google passa a expor as quatro sub-partes do LCP no Chrome User Experience Report, separando inclusive TTFB para sessões com LCP em imagem versus texto. Mudança crítica para diagnóstico em sites grandes, já que antes era impossível saber se o gargalo era servidor ou recurso descoberto tarde.
Setembro 2024. Google Search habilita prefetch via Speculation Rules em desktop por padrão, depois do rollout em Android desde outubro de 2022. Em paralelo, Astro 4.2 e Next.js passam a oferecer prerender client-side via Speculation Rules como opção nativa.
2025. Search Console adiciona a decomposição em sub-partes no relatório de Core Web Vitals, facilitando diagnóstico sem precisar abrir PageSpeed para cada URL. Pelo Web Almanac 2025, a taxa de aprovação em CWV chegou a 48% em mobile e 56% em desktop, a maior contribuição individual veio do INP, mas LCP também subiu de forma consistente.
2026. Discussão em curso, sem mudança oficial, sobre incluir métrica de "LCP interativo" que considere o momento em que o elemento principal não só renderiza mas também responde a interação. Por enquanto, o threshold de 2,5s e a definição clássica permanecem.
Como monitorar LCP ao longo do tempo
Algumas práticas simples ajudam a evitar que a performance degrade silenciosamente:
- Checagem obrigatória antes da publicação. Toda página nova deve passar pelo PageSpeed Insights antes do deploy, em mobile e desktop. Se LCP, INP ou CLS caírem em "Precisa de melhorias" ou "Ruim", a página não deve ser publicada enquanto não se entender o motivo. Em alguns casos a regressão é aceitável e a página sobe assim mesmo, o ponto é que a decisão seja consciente, não acidental.
- Revisão mensal do Search Console. O relatório de Core Web Vitals mostra problemas em dados reais (field data) conforme eles aparecem. Detectar uma regressão na primeira semana é fácil; rastrear três meses depois, quando o sintoma já apareceu em outro lugar, é bem mais difícil.
- Alertas automáticos. Quando o LCP de um template passar de 2,5s por três dias seguidos, dispara um alerta. Com
web-vitals.jsinstalado, ele captura a métrica de cada visitante real e despacha pro analytics, daí é só criar a regra (GA, BigQuery, Datadog). - Histórico por template. Uma planilha simples com snapshot mensal de LCP por template e por classe de dispositivo já basta. Sem histórico, é difícil diferenciar regressão real de variação sazonal.
A regra mais importante é mobile-first: como o Google indexa mobile primeiro e field data mostra que LCP mobile é quase sempre pior que desktop, quando há trade-off de prioridade, mobile vence.
Perguntas frequentes sobre LCP
Imagem hero em SVG conta como LCP?
Sim, desde que seja renderizada como <img> apontando para o arquivo SVG ou como <svg> inline, com tamanho relevante na viewport. SVGs decorativos pequenos não disputam LCP. Para hero, prefira SVG inline para evitar a requisição de rede adicional.
Posso ter mais de uma imagem com fetchpriority="high" por página?
Tecnicamente sim, mas anula o efeito. O atributo serve para priorizar um único recurso acima dos demais. Usar em múltiplos elementos faz o navegador tratar todos como prioridade normal e o ganho desaparece. A boa prática é usar em exatamente um elemento por página, idealmente o hero acima da dobra.
LCP melhora se eu aplicar lazy loading em todas as imagens abaixo da dobra?
Sim, indiretamente. Lazy loading libera banda e parser para o recurso LCP, especialmente em conexões móveis com poucas conexões paralelas disponíveis. Mas jamais aplique loading="lazy" no próprio elemento LCP, pois isso atrasa o início do download e piora a métrica.
Preciso de CDN se meu site é pequeno e regional?
Para sites com audiência concentrada em uma região e servidor próximo, o ganho de CDN é menor, mas ainda existe, principalmente em mobile com latência variável e em horários de pico. Para sites com audiência nacional ou internacional, CDN deixa de ser opcional. Para sites brasileiros com presença Norte/Nordeste, é a correção com maior custo-benefício individual.
Qual é a diferença entre <link rel="preload"> e fetchpriority="high"?
<link rel="preload"> força o navegador a baixar um recurso o mais cedo possível, independentemente de onde aparece no HTML. fetchpriority="high" sinaliza prioridade relativa entre recursos já descobertos. Para imagem hero presente no HTML inicial, fetchpriority é suficiente e mais simples. Para hero injetado por JavaScript ou descoberto tarde (background image em CSS), preload é necessário e os dois podem ser combinados.
Quanto tempo leva para uma correção em LCP aparecer no Search Console?
A janela do CrUX é de 28 dias de field data. Correções efetivas aparecem progressivamente com primeiras mudanças visíveis em 1–2 semanas e estabilização em 4–6 semanas. Para validar a correção no curto prazo, use Lighthouse (lab data) e RUM próprio. Não espere o Search Console para confirmar que a mudança funcionou.
Vale a pena adotar Speculation Rules se Safari não suporta?
Sim. A API foi desenhada para falhar silenciosamente em navegadores que não suportam, o Safari simplesmente ignora as regras e a página carrega no padrão. Para os usuários Chrome e Edge (cerca de 65–70% do tráfego no Brasil, segundo Statcounter), o ganho é potencialmente enorme: LCP próximo de zero em navegações previstas. O custo-benefício é positivo na grande maioria dos sites.
Para validar se sua página atende ao critério de INP e aos outros 60+ critérios técnicos de SEO, use o SEO Check. Para entender se seu site está preparado para ser citado por motores de busca generativa como ChatGPT, Perplexity e Copilot, use o GEO Check.