LCP (Largest Contentful Paint)

LCP Largest Contentful Paint é a métrica do Core Web Vitals do Google que mede o tempo até o maior elemento visível na tela inicial ficar carregado. Pode ser uma imagem grande, um bloco de texto, um vídeo ou um banner — o que ocupar mais espaço na viewport. A meta oficial é manter LCP abaixo de 2,5 segundos. Acima de 4 segundos é considerado ruim e impacta diretamente o ranqueamento no Google e a percepção de velocidade do usuário.

O que é LCP

O Largest Contentful Paint foi introduzido pelo Google em 2020 como parte dos Core Web Vitals. Substituiu métricas mais antigas como First Meaningful Paint e Speed Index, que tentavam medir velocidade percebida mas eram complexas e inconsistentes. O LCP propôs uma simplificação útil: medir o que mais importa visualmente, o maior elemento, ignorando o resto.

O que é lcp na prática: o navegador acompanha cada elemento renderizado na tela inicial. Para cada novo candidato (imagem que apareceu, bloco de texto que ficou visível), atualiza a métrica se aquele elemento for o maior. Quando o usuário interage ou rola a página, o LCP é finalizado com o último maior elemento registrado. Geralmente esse momento acontece entre 1 e 5 segundos do início do carregamento.

A meta de 2,5 segundos foi calibrada com base em pesquisa de UX. Acima desse tempo, usuários começam a perceber a página como lenta. Acima de 4 segundos, abandonam mais frequentemente. O Google escolheu 2,5s como limite “bom” e 4s como limite “ruim” — a faixa intermediária é “precisa melhorar”.

O LCP é medido em campo (dados reais via CrUX) e em laboratório (testes sintéticos via Lighthouse). O Google usa principalmente o dado de campo para decisões de ranqueamento, capturado de visitantes reais usando Chrome com dados anônimos enviados ao serviço. Sites de baixo tráfego podem não ter dados de campo suficientes — nesses casos, dados sintéticos viram referência.

O que conta como elemento LCP

O Google considera certos tipos de elemento como candidatos a LCP. A lista oficial inclui: tags img, tags image dentro de svg, tags video com poster definido, elementos com background-image inserido via url() no CSS, e blocos de texto (qualquer parágrafo ou heading). O maior desses dentro da viewport inicial vira o LCP da página.

Em sites WordPress típicos, o elemento LCP é geralmente uma imagem hero — banner principal no topo da página, imagem do post acima do fold, ou logo de página de categoria. Em sites editoriais sem imagem grande no topo, costuma ser o título do post (H1) ou primeiro parágrafo. Em e-commerce, tipicamente a imagem principal do produto.

Importante: só elementos visíveis no carregamento inicial contam. Se o conteúdo abaixo do fold for maior que o que aparece inicialmente, ele não conta para LCP — só conta o que está dentro da viewport visível antes do scroll. Isso muda a estratégia de otimização: foco no que aparece na primeira tela, não no peso total da página.

Ferramentas como o Chrome DevTools mostram exatamente qual elemento foi identificado como LCP. Aba Performance, gravar carregamento, procurar marcador LCP — o elemento aparece destacado. PageSpeed Insights também mostra screenshot com o elemento LCP identificado e tempo medido. Esse é o ponto de partida para qualquer otimização.

Como medir LCP

A primeira ferramenta é PageSpeed Insights (pagespeed.web.dev). Cole a URL e veja LCP de campo (dados reais do CrUX) e de laboratório (teste sintético no momento). Indica em verde, amarelo ou vermelho. Mostra screenshot do elemento LCP. Sugere otimizações específicas. É o ponto de partida para qualquer auditoria.

A segunda ferramenta é o Lighthouse, embutido no Chrome DevTools. F12, aba Lighthouse, gerar relatório. Diferente do PageSpeed que combina dados de campo, Lighthouse roda só dados sintéticos no momento — útil para reproduzir e debugar issues específicas. Lighthouse simula 4G lenta, então tempos costumam ser piores que em rede real.

A terceira ferramenta é Search Console na seção Core Web Vitals. Mostra agregado de LCP do site separado por mobile e desktop, com URLs em estado “Bom”, “Precisa melhorar” ou “Ruim”. Permite acompanhar evolução ao longo das semanas após implementar otimizações. Dados do CrUX, ou seja, usuários reais.

A quarta opção é monitoramento contínuo via web-vitals.js, biblioteca oficial do Google. Adicione ao seu site e capture LCP de cada visitante real, enviando para Google Analytics ou outro sistema de logs. Mais técnico, mas dá granularidade — você pode ver LCP por página, por dispositivo, por país, e identificar páginas problemáticas que ferramentas agregadas escondem.

A quinta forma é Chrome DevTools direto, na aba Performance. Grave sessão de carregamento, identifique a marca “LCP” na timeline, veja exatamente qual elemento, em que momento, e o que estava acontecendo. Útil para debug específico de problema reproduzível.

Como otimizar LCP no WordPress

O caminho número um para como melhorar lcp é otimizar a imagem hero. Se o LCP é uma imagem grande, comprima e converta para formato moderno (WebP ou AVIF). Use srcset para servir versão adequada ao dispositivo do visitante. Pré-carregue com tag link rel=”preload” para que o navegador comece o download antes do CSS dizer onde colocar.

O caminho número dois é cache agressivo. Site sem cache roda PHP e MySQL a cada visita, somando 500ms-2s antes de o HTML começar a chegar. Com cache de página em arquivos estáticos, esse tempo cai para próximo de zero. WP Rocket, LiteSpeed Cache, W3 Total Cache resolvem o problema. Em hospedagens premium, vem por padrão.

O caminho número três é CDN para assets estáticos. Imagens, CSS e JavaScript servidos via Cloudflare, BunnyCDN ou similar entregam de servidor próximo ao visitante, reduzindo latência. Para sites brasileiros, isso é especialmente útil para visitantes em capitais distantes do servidor de origem. Ganho mensurável em LCP.

O caminho número quatro é eliminar render-blocking resources. CSS e JS no head bloqueiam renderização. CSS crítico inline (above-the-fold) e o resto async ou deferred. JavaScript não-crítico com defer ou async. Isso permite ao navegador começar a desenhar a página antes de baixar tudo. Plugins de performance fazem essa otimização automaticamente quando bem configurados.

O caminho número cinco é otimizar TTFB. Time to First Byte alto significa que o servidor demora a responder. Causas comuns: hospedagem ruim, plugin lento, banco não otimizado, falta de cache de objeto. Combine hospedagem premium, otimização de banco e cache via Redis para reduzir TTFB e impactar diretamente LCP.

Combine essas otimizações com tratamento de CLS e FID/INP para uma abordagem completa de Core Web Vitals. Para sites profissionais que precisam dessa configuração otimizada por padrão, sem virar trabalho de tuning manual a cada plugin novo, a FULL Services entrega o Perfmatter já licenciado e configurado dentro da stack profissional, com preload automático de imagens críticas, lazy loading inteligente, otimização de fontes, deferral de JS não-crítico e tuning específico para reduzir LCP em temas WordPress. É a forma de manter Core Web Vitals consistentemente no verde mesmo em sites complexos com múltiplos plugins ativos.