Corrigir e Identificar Problemas de Largest Contentful Paint (LCP)

Este guia faz parte do hub do Largest Contentful Paint (LCP). O LCP mede a velocidade com que o maior elemento visível é renderizado. O Google recomenda que seja inferior a 2,5 segundos. A seguir, apresento o processo de diagnóstico exato que utilizo em minhas consultorias de velocidade de página.

O Guia de um Consultor para Diagnosticar e Corrigir o LCP

Meu nome é Arjen Karel e sou um consultor de velocidade de página. Ao longo dos anos, auditei centenas de sites, e um dos desafios mais persistentes é o Largest Contentful Paint (LCP). Neste guia, compartilharei a metodologia exata que uso para diagnosticar e resolver problemas de LCP. Você verá menções ao CoreDash, uma ferramenta de RUM que criei para obter os dados precisos necessários para esse processo. Os princípios aqui são universais, mas acredito em mostrar exemplos reais das ferramentas que construo e uso diariamente.

Melhorar o LCP é um processo de eliminação. De acordo com o 2025 Web Almanac, apenas 66% das origens mobile passam no LCP. Isso significa que um terço da web tem problemas de carregamento. Encontre a fase mais lenta, corrija-a e meça novamente.

A Metodologia de Diagnóstico: Dados de Campo Primeiro, Dados de Laboratório Depois

Para otimizar efetivamente, você deve adotar um fluxo de trabalho de diagnóstico em duas etapas. Isso garante que você está resolvendo problemas que seus usuários estão realmente enfrentando, e não apenas perseguindo pontuações em um ambiente de laboratório.

1. Dados de Campo (RUM & CrUX) mostram O QUE está acontecendo. Os dados de campo são coletados de usuários reais que visitam seu site. Eles dizem se você tem um problema de LCP, quais páginas são afetadas e quais usuários (mobile ou desktop) estão enfrentando isso. Você deve sempre começar por aqui para confirmar que um problema real existe.
2. Dados de Laboratório (Lighthouse, DevTools) ajudam a diagnosticar POR QUE isso está acontecendo. Os dados de laboratório são coletados em um ambiente controlado e simulado. Uma vez que seus dados de campo confirmem um problema em uma página específica, você pode usar ferramentas de laboratório para replicar consistentemente o problema e dissecar o processo de carregamento para encontrar a causa raiz.

Comece com os dados de campo para que seus esforços de otimização tenham como alvo as mudanças que realmente impactam usuários reais.

Passo 1: Identificar Problemas de LCP com Dados de Campo

Sua primeira tarefa é usar dados de usuários reais para confirmar quais páginas, se houver, têm um LCP ruim.

Um Ponto de Partida Acessível: Google Search Console

Um lugar válido para começar é o relatório Core Web Vitals no Google Search Console. Faça login, navegue até o relatório e revise os gráficos de mobile e desktop. Se o Google estiver sinalizando URLs com "Problema de LCP: mais de 2,5s", você tem a confirmação do Chrome User Experience (CrUX) Report de que uma porcentagem de seus usuários está tendo uma experiência ruim.

O Search Console confirma o problema, mas é atualizado lentamente e agrupa as URLs. Para detalhes em nível de página em tempo real, você precisa de uma ferramenta de RUM.

Real User Monitoring (RUM): Detalhe em Nível de Página

Você pode construir sua própria configuração de RUM usando a biblioteca web-vitals para enviar dados ao seu backend de analytics, mas isso exige um esforço significativo de engenharia.

Eu criei o CoreDash especificamente para isso. Você adiciona uma tag de script e ele começa a coletar dados de LCP de todos os visitantes reais, detalhados por página, dispositivo e elemento.

Uma boa ferramenta de RUM permite que você veja:

• Sua pontuação exata de LCP para qualquer URL específica.
• Um detalhamento de cada elemento LCP (ex.: uma imagem, um título) e quais são mais frequentemente associados a um LCP lento.
• O tempo exato para cada uma das quatro fases do LCP para cada visualização de página, identificando com precisão o gargalo.

Olhar além do próprio elemento LCP é importante. Em um estudo de caso bem documentado, a Vodafone melhorou seu LCP em 31%, o que contribuiu diretamente para um aumento de 8% nas vendas. Sua otimização concentrou-se em identificar e resolver o gargalo específico de LCP em landing pages importantes, usando uma combinação de análise de dados de campo e correções direcionadas. A otimização do LCP não diz respeito apenas à imagem. Você precisa entender o pipeline completo de carregamento: resposta do servidor, descoberta de recursos, download e paint.

Por exemplo, no CoreDash, você pode navegar até a página de LCP e visualizar uma tabela de dados que mostra os elementos de LCP mais lentos. Ao clicar em um elemento específico (como uma determinada classe CSS de uma imagem principal), você pode filtrar todas as métricas para ver os dados de desempenho apenas das páginas onde esse elemento foi o LCP.

O objetivo: usar dados de campo para encontrar a sua página mais lenta e seu elemento LCP mais comum. Esse é o seu alvo.

Medindo o LCP com a Performance Observer API

A Performance Observer API fornece acesso direto às entradas do LCP no JavaScript. Esta é a mesma API que as ferramentas de RUM usam nos bastidores para coletar dados de campo. O snippet a seguir registra cada candidato de LCP que o navegador identifica, incluindo o elemento, seu tamanho e o tempo de renderização.

const observer = new PerformanceObserver((list) => {
  const entries = list.getEntries();
  const lastEntry = entries[entries.length - 1];
  console.log('LCP element:', lastEntry.element);
  console.log('LCP time:', lastEntry.renderTime || lastEntry.loadTime);
  console.log('LCP size:', lastEntry.size);
});
observer.observe({ type: 'largest-contentful-paint', buffered: true });

Isso é útil para validação rápida durante o desenvolvimento, mas para medições em produção você deve usar a biblioteca web-vitals, que lida com casos extremos (edge cases), como mudanças de visibilidade de abas e restaurações de cache de avançar/voltar (back/forward cache).

Passo 2: Diagnosticar o Gargalo com Ferramentas de Laboratório

Você sabe qual página corrigir. Agora descubra por que ela está lenta. Execute um teste com o PageSpeed Insights ou o painel do Lighthouse no Chrome DevTools.

No relatório, role para baixo até a seção "Diagnostics" e encontre a auditoria de "Largest Contentful Paint element". Este gráfico de cascata divide o tempo do seu LCP em suas quatro subpartes. Sua ferramenta de RUM deve mostrar um detalhamento semelhante com base nos seus dados de campo.

Seu objetivo é encontrar a fase mais longa neste detalhamento. Esse é o seu gargalo principal, e é aqui que você deve focar seus esforços de otimização primeiro.

Passo 3: Entendendo as Quatro Fases do LCP

Cada pontuação de LCP é a soma de quatro fases sequenciais. Cada fase tem um guia dedicado neste site cobrindo técnicas específicas de otimização.

• Time to First Byte (TTFB): Esta é a base que não pode ser ignorada. Uma resposta lenta do servidor é um acréscimo direto, milissegundo por milissegundo, ao seu LCP. Antes de otimizar uma única imagem, você deve garantir que seu servidor esteja respondendo rapidamente. Saiba mais sobre como otimizar o TTFB.
• Resource Load Delay: Este é o "problema de descoberta" e um dos problemas mais comuns. O navegador não pode fazer download de um recurso que não conhece. Se a imagem do seu LCP estiver oculta em um arquivo CSS ou JavaScript, ou mesmo se estiver no HTML mas outros recursos forem solicitados primeiro, o navegador a encontrará tarde demais, desperdiçando um tempo valioso. Leia o guia completo sobre Resource Load Delay.
• Resource Load Duration: Este é o tempo de download para o próprio recurso do LCP. Imagens grandes e não compactadas ou condições de rede lentas podem tornar esta fase um gargalo. Leia o guia completo sobre Resource Load Duration.
• Element Render Delay: Este é o problema de "muito ocupado para renderizar". O arquivo de imagem do LCP pode estar totalmente baixado, mas se a thread principal do navegador estiver bloqueada por uma execução pesada de JavaScript , ele simplesmente não conseguirá renderizar a imagem na tela. Leia o guia completo sobre Element Render Delay.

Sempre comece garantindo que seu TTFB seja rápido e que seu recurso LCP seja detectável antes de passar para otimizações de tamanho de arquivo e renderização.

Passo 4: Executar a Correção

Com o gargalo identificado, aplique a correção. A implementação depende da sua stack. Cada fase abaixo cobre princípios universais primeiro, depois especificidades do WordPress e de frameworks JS.

1. Otimizando o Time to First Byte (TTFB)

Se o seu TTFB estiver lento (um bom alvo é abaixo de 800ms), isso estabelece um piso alto para o seu LCP. Melhorar o TTFB melhorará todas as outras métricas de carregamento.

Soluções Universais de TTFB

• Habilite o Caching: Esta é uma das maneiras mais eficazes de melhorar o TTFB. O cache gera e armazena uma cópia da página para que possa ser servida instantaneamente, sem esperar que o servidor a construa do zero a cada visita.
• Use uma CDN: Uma Content Delivery Network serve seu conteúdo a partir de um servidor fisicamente próximo ao seu usuário, o que reduz a latência da rede. Fazer cache de suas páginas HTML completas na edge da CDN é uma estratégia poderosa para um TTFB global e rápido. Para dicas detalhadas de configuração de CDN, veja nosso guia sobre como configurar a Cloudflare para um desempenho ideal.
• Use a Compressão Brotli ou Gzip: Certifique-se de que seu servidor esteja comprimindo ativos baseados em texto, como HTML, CSS e JavaScript. O Brotli oferece uma compressão melhor do que o Gzip e deve ser preferido.
• Use HTTP/3 com 0-RTT: Certifique-se de que seu servidor esteja configurado para usar HTTP/3. Ele oferece vantagens significativas de desempenho, incluindo melhor multiplexação. Ele suporta 0-RTT (Zero Round Trip Time Resumption), o que elimina o tempo de configuração da conexão para visitantes recorrentes, fornecendo um aumento instantâneo de TTFB.
• Use 103 Early Hints: Para um impulso avançado, use o código de status 103 Early Hints. Isso permite que seu servidor ou CDN envie hints (dicas) sobre arquivos críticos de CSS e JS para o navegador enquanto ele ainda está preparando o documento HTML completo, permitindo que os downloads comecem ainda mais cedo. Para um guia de implementação completo, veja nosso artigo sobre 103 Early Hints.

Correções de TTFB Específicas por Plataforma

No WordPress:

• Invista em uma Hospedagem de Qualidade: No WordPress, um TTFB lento costuma estar relacionado ao ambiente de hospedagem. Hospedagens compartilhadas baratas podem ser um gargalo. Considere uma hospedagem WordPress gerenciada que seja otimizada para desempenho.
• Use um Plugin de Cache: Um plugin de cache de alta qualidade (ex.: WP Rocket, W3 Total Cache) é inegociável. Ele lida com a geração de arquivos HTML estáticos para você, o que é o núcleo do caching eficaz nesta plataforma.

Em um Framework JS:

• Escolha a Plataforma de Hospedagem Certa: Para aplicações Node.js, plataformas como Vercel ou Netlify são altamente otimizadas para frameworks SSR/SSG e oferecem cache inteligente e execução de funções serverless out of the box (pronto para uso).
• Implemente SSR Caching: Se você estiver usando Server-Side Rendering, faça cache das páginas renderizadas no servidor (ex.: usando Redis ou um cache em memória) para evitar re-renderizar a cada requisição.
• Cuidado com Serverless Cold Starts: Se estiver usando funções serverless para renderização, esteja ciente de que um "cold start" (a primeira solicitação após um período de inatividade) pode ter um alto TTFB. Use simultaneidade provisionada (provisioned concurrency) ou estratégias de keep-alive para mitigar isso.

2. Reduzindo o Resource Load Delay

Este é frequentemente o maior gargalo. Isso significa que o navegador estava pronto para trabalhar, mas não conseguiu encontrar o seu arquivo principal de imagem ou fonte de imediato. Esse atraso geralmente é causado por um de dois problemas: o recurso é descoberto tarde, ou recebe uma baixa prioridade de download. Para o guia completo sobre este tópico, leia nosso guia dedicado sobre Resource Load Delay.

Soluções Universais de Load Delay

A solução universal para o Resource Load Delay é garantir que seu recurso LCP seja detectável na marcação HTML inicial e receba alta prioridade pelo navegador. Veja como alcançar isso:

• Torne o Recurso LCP Detectável: O passo mais importante é garantir que seu elemento LCP esteja presente no HTML que o servidor envia. Os navegadores usam um "preload scanner" de alta velocidade para olhar adiante no HTML bruto por recursos como imagens e scripts para fazer download. Se sua imagem LCP for carregada via um background-image do CSS ou injetada com JavaScript, ela ficará invisível para esse scanner, causando um grande atraso. A solução mais robusta é sempre usar uma tag <img> padrão com um atributo src em seu HTML renderizado pelo servidor.
• Controle a Ordem de Carregamento com preload: Se você não pode tornar o recurso LCP diretamente detectável (um problema comum com fontes ou imagens de fundo em CSS), a próxima melhor solução é usar <link rel="preload">. Esta tag atua como uma instrução explícita no <head> do seu HTML, dizendo ao navegador para começar a baixar um recurso crítico muito mais cedo do que ele o teria encontrado naturalmente. Para detalhes de implementação e exemplos, consulte nosso guia sobre como fazer preload da imagem do LCP.
• Garanta Alta Prioridade com fetchpriority: Mesmo quando um recurso é detectável, o navegador pode não dar a ele a maior prioridade de download. Adicionar fetchpriority="high" à sua tag <img> ou à sua tag <link rel="preload"> é uma dica (hint) poderosa para o navegador de que este recurso específico é o mais importante para a user experience, ajudando-o a ganhar a corrida pela largura de banda contra outros recursos.

Correções de Load Delay Específicas por Plataforma

No WordPress:

• Evite Imagens de Fundo em Page Builders: Muitos construtores de página (page builders) facilitam a definição de uma imagem principal (hero image) como um background-image CSS em uma div. Isso a torna invisível ao preload scanner do navegador. Se possível, use um bloco <img> padrão em vez disso. Se não, você pode precisar de um plugin ou código personalizado para fazer o preload dessa imagem específica.
• Desative o Lazy-Loading para a Imagem LCP: Muitos plugins de otimização irão automaticamente aplicar lazy-load a todas as imagens. Você deve encontrar a configuração no seu plugin para excluir a imagem do LCP (e frequentemente as primeiras imagens na página) do lazy-loading. Este é um erro tão comum que temos um artigo dedicado sobre como corrigir imagens do LCP com lazy-loading.

Em um Framework JS:

• Use Server-Side Rendering (SSR): Esta costuma ser a correção mais impactante. Um aplicativo React Client-Side Rendered (CSR) padrão envia o mínimo de HTML, e o elemento LCP só existe depois que um grande bundle JS é baixado e executado. Frameworks SSR como Next.js ou Remix entregam o HTML completo, incluindo a tag <img>, para que o navegador possa descobri-la imediatamente.
• Use Componentes de Imagem Específicos do Framework: Frameworks como Next.js oferecem um componente de imagem com uma propriedade (prop) priority. Usar a prop priority aplica automaticamente o fetchpriority="high" e outras otimizações para sua imagem LCP.

3. Diminuindo o Resource Load Duration

Garantir que o seu recurso LCP seja o menor possível ainda é uma parte essencial do processo. Esta fase trata de quanto tempo leva para baixar o arquivo do recurso LCP pela rede. Para um guia completo sobre técnicas de otimização de imagem, veja nosso artigo sobre como otimizar a imagem do LCP, e para saber mais sobre Resource Load Duration especificamente.

Soluções Universais de Tempo de Carregamento

• Reduza o Tamanho do Arquivo com Formatos Modernos e Imagens Responsivas: A maneira mais direta de reduzir o tempo de download é tornar o arquivo menor. Para imagens, isso significa usar formatos modernos e altamente eficientes como AVIF ou WebP. Você também deve servir imagens responsivas usando o elemento <picture> ou os atributos srcset e sizes. Isso garante que um usuário em um dispositivo móvel receba uma imagem dimensionada adequadamente para a sua tela menor, em vez de ser forçado a baixar uma imagem massiva feita para desktop. Uma tela mobile de 400 pixels de largura simplesmente não precisa de um arquivo de imagem de 2000 pixels de largura. Para LCPs baseados em texto, certifique-se de que suas fontes estejam no eficiente formato WOFF2 e sejam divididas em subconjuntos (subsetted) para remover caracteres não utilizados.
• Reduza a Contenção de Rede: O recurso do LCP tem que competir pela largura de banda limitada da rede do usuário. Adiar (defer) recursos não críticos, como scripts de analytics ou CSS para conteúdo below-the-fold, libera a largura de banda para que o navegador possa focar em baixar o recurso do LCP mais rapidamente.
• Hospede Recursos Críticos no seu Domínio Principal: Evite carregar seu recurso LCP de um domínio diferente se possível. Configurar uma nova conexão para outro servidor adiciona pesquisas (lookups) de DNS e handshakes que consomem tempo.

Correções de Tempo de Carregamento Específicas por Plataforma

No WordPress:

• Use um Plugin de Otimização de Imagens: Ferramentas como ShortPixel ou Smush podem comprimir automaticamente imagens no momento do upload, convertê-las para formatos modernos como WebP/AVIF, e gerar tamanhos responsivos em srcset.
• Redimensione Imagens Manualmente: Antes de fazer o upload, redimensione suas imagens para não serem maiores do que precisam ser. Não faça upload de uma imagem de 4000px de largura para um espaço que tem apenas 1200px de largura nas maiores telas.

Em um Framework JS:

• Use uma CDN de Imagens: Esta é uma solução poderosa. Serviços como Cloudinary, Imgix ou o Image & Video Manager da Akamai podem automatizar todo o processo de otimização. Você faz o upload de uma imagem de alta qualidade, e eles entregam uma versão perfeitamente dimensionada, compactada e formatada para cada usuário através de uma CDN rápida.
• Aproveite as Build Tools (Ferramentas de Build): Quando você importa uma imagem em um componente de um framework moderno, a ferramenta de build (como Webpack ou Vite) pode automaticamente aplicar hash e otimizar o arquivo como parte do processo de build.

4. Reduzindo o Element Render Delay

O recurso terminou de ser baixado, mas ainda não está na tela. Isso significa que a thread principal do navegador está ocupada com outras tarefas e não pode renderizar o elemento. Este é outro gargalo muito comum e significativo. Para o guia completo, leia nosso guia sobre Element Render Delay.

Soluções Universais de Render Delay

• Adie (Defer) ou Remova JavaScript Não Utilizado: Qualquer JS que não seja essencial para renderizar a parte inicial e visível da página deve ser adiado (deferred) usando os atributos defer ou async.
• Use Critical CSS: Uma folha de estilo grande que bloqueia a renderização (render-blocking) pode atrasar a mesma. A técnica de critical CSS envolve extrair o CSS mínimo necessário para estilizar o conteúdo above-the-fold, inserindo-o inline no <head>, e carregando o restante dos estilos de forma assíncrona.
• Divida Long Tasks (Tarefas Longas): Um script de longa duração pode bloquear a thread principal por um período prolongado, impedindo a renderização. Esta também é uma das principais causas de um Interaction to Next Paint (INP) ruim. Divida seu código em pedaços menores e assíncronos que façam yield (cedam) o controle de volta para a thread principal.

Correções de Render Delay Específicas por Plataforma

No WordPress:

• Audite Seus Plugins: Muitos plugins, especialmente os pesados como sliders ou page builders complexos, podem adicionar CSS e JS significativos que bloqueiam a thread principal. Desative plugins um por um para identificar os maiores ofensores de desempenho.
• Use um Tema Leve: Um tema inchado (bloated) com dezenas de recursos que você não usa pode ser uma grande fonte de código render-blocking. Escolha um tema focado em desempenho.
• Use Gerenciadores de Ativos de Plugins: Ferramentas como Asset CleanUp ou Perfmatters permitem que você desative condicionalmente o CSS e o JS de plugins específicos em páginas onde eles não são necessários.

Em um Framework JS:

• Code Splitting é a Chave: Não envie todo o JavaScript do seu aplicativo em um único bundle gigante. Divida (split) o seu código por rota (para que os usuários baixem apenas o código da página que estão visitando) e por componente.
• Faça Lazy Load de Componentes: Use React.lazy e Suspense para fazer lazy-load de componentes que não são imediatamente visíveis (ex.: componentes below the fold ou em modais). Isso os mantém fora do bundle inicial.

Avançado: Otimizando o LCP para Navegações Subsequentes

Corrigir o LCP inicial é importante, mas você pode fazer com que a navegação no seu site pareça instantânea otimizando os carregamentos subsequentes das páginas.

Certifique-se de que as Páginas São Elegíveis para o Back/Forward Cache (bfcache)

O bfcache é uma otimização do navegador que armazena na memória um snapshot completo de uma página quando o usuário navega para fora dela. Se ele clicar no botão de voltar, a página pode ser restaurada instantaneamente, resultando em um LCP próximo a zero. Muitas páginas são inelegíveis para este cache devido a coisas como event listeners de unload. Use a auditoria "bfcache" do Lighthouse para testar suas páginas e remover quaisquer recursos de bloqueio.

Use a Speculation Rules API para Prerendering

A Speculation Rules API permite que você diga de forma declarativa ao navegador para quais páginas o usuário provavelmente navegará em seguida. O navegador pode então buscar (fetch) e fazer o pre-render dessas páginas em segundo plano. Quando o usuário clica num link para uma página com pre-renderização, a navegação é instantânea, levando a um LCP próximo a zero. Você pode definir essas regras em uma tag <script type="speculationrules"> no seu HTML.

<script type="speculationrules">
 {
  "prerender": [{
   "source": "document",
   "where": {
    "href_matches": "/products/*"
   },
   "eagerness": "moderate"
  }]
 }
 </script>  

Este exemplo diz ao navegador para procurar na página atual links que levem a páginas de produtos e iniciar a pre-renderização quando o usuário passa o mouse sobre o link.

Trabalhe nas quatro fases em ordem. Corrija o maior gargalo primeiro, meça novamente, repita.

Próximos Passos: Cada Fase do LCP em Detalhes

Cada fase do LCP tem seu próprio guia:

• Otimize a Imagem do LCP: Um guia completo para seleção de formato de imagem, imagens responsivas, preloading e erros comuns de otimização de imagem.
• Resource Load Delay: Como garantir que o navegador descubra seu recurso LCP o mais cedo possível usando preload, fetchpriority e a estrutura HTML adequada.
• Resource Load Duration: Como reduzir o tempo de download do seu recurso LCP através da compressão de arquivos, formatos modernos, configuração de CDN e otimização de rede.
• Element Render Delay: Como liberar a thread principal do navegador para que ela possa renderizar o elemento LCP imediatamente após o download, abrangendo critical CSS, deferral de JavaScript e content-visibility.