Corrigir e identificar problemas de Largest Contentful Paint (LCP)

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

Guia de um Consultor para Diagnosticar e Corrigir o LCP

Meu nome é Arjen Karel e sou 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. Segundo o Web Almanac de 2025, 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: Field Data Primeiro, Lab Data Depois

Para otimizar com eficácia, você deve adotar um fluxo de diagnóstico em duas etapas. Isso garante que você resolva os problemas que os usuários realmente enfrentam, em vez de apenas buscar pontuações em ambiente de laboratório.

1. Field data (RUM e CrUX) mostra O QUE está acontecendo. O field data é coletado de usuários reais visitando seu site. Ele diz se você tem um problema de LCP, quais páginas são afetadas e quais usuários (mobile ou desktop) o enfrentam. Você deve sempre começar por aqui para confirmar que existe um problema real.
2. Lab data (Lighthouse, DevTools) ajuda a diagnosticar POR QUE está acontecendo. O lab data é coletado em um ambiente controlado e simulado. Assim que seu field data confirmar um problema numa página específica, você pode usar as ferramentas de laboratório para replicar o problema de forma consistente e dissecar o processo de carregamento para encontrar a causa raiz.

Comece pelo field data. Assim, seus esforços de otimização vão focar em mudanças que realmente impactam usuários reais.

Passo 1: Identificar Problemas de LCP com Field Data

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

Um Ponto de Partida Acessível: Google Search Console

Um bom lugar para começar é o relatório de Core Web Vitals no Google Search Console. Faça login, acesse 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 dos seus usuários está tendo uma experiência ruim.

O Search Console confirma o problema, mas atualiza devagar e agrupa as URLs. Para ter detalhes no nível da página em tempo real, você precisa de uma ferramenta de RUM.

Real User Monitoring (RUM): Detalhes no Nível da Página

Você pode montar sua própria estrutura de RUM usando a biblioteca web-vitals para enviar dados ao seu backend de analytics, mas isso exige muito esforço 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 todo visitante real, separados por página, dispositivo e elemento.

Uma boa ferramenta de RUM permite ver:

• 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 de cada uma das quatro fases do LCP para cada visualização de página, apontando 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%. Isso contribuiu diretamente para um aumento de 8% nas vendas. A otimização focou em identificar e resolver o gargalo específico do LCP nas principais landing pages. Eles usaram uma combinação de análise de field data e correções direcionadas. A otimização do LCP não se resume à imagem. Você precisa entender todo o pipeline de carregamento: resposta do servidor, descoberta de recursos, download e pintura.

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

O objetivo: usar field data para encontrar sua página mais lenta e o elemento LCP mais comum. Esse é o seu alvo.

Medindo o LCP com a Performance Observer API

A Performance Observer API dá acesso direto às entradas de LCP no JavaScript. É a mesma API que as ferramentas de RUM usam por baixo dos panos para coletar field data. O snippet abaixo registra cada candidato a LCP que o navegador identifica. Ele inclui 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. No entanto, para medição em produção, você deve usar a biblioteca web-vitals. Ela lida com casos extremos, como mudanças de visibilidade de abas e restaurações de 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 com o painel Lighthouse no Chrome DevTools.

No relatório, role para baixo até a seção "Diagnostics" e encontre a auditoria "Largest Contentful Paint element". Esse gráfico de cascata divide o tempo do seu LCP em suas quatro subpartes. Sua ferramenta de RUM deve mostrar um detalhamento semelhante baseado no seu field data.

Seu objetivo é encontrar a fase mais longa nesse detalhamento. Esse é o seu gargalo principal. É aí que você deve concentrar seus esforços de otimização primeiro.

Guia passo a passo: prefere trabalhar no DevTools? Diagnostique o LCP com o painel Performance do Chrome DevTools mostra como gravar um trace com throttling e ler as mesmas quatro subpartes do insight de detalhamento do LCP.

Passo 3: Entendendo as Quatro Fases do LCP

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

• Time to First Byte (TTFB): Esta é a base obrigatória. Uma resposta lenta do servidor é uma adição direta, milissegundo por milissegundo, ao seu LCP. Antes de otimizar uma única imagem, você deve garantir que o seu servidor esteja respondendo rapidamente. Saiba mais sobre como otimizar o TTFB.
• Resource Load Delay: Este é o "problema de descoberta". É um dos problemas mais comuns. O navegador não consegue baixar um recurso que desconhece. Se a sua imagem de LCP estiver escondida em um arquivo CSS ou JavaScript, ou até mesmo no HTML mas outros recursos forem solicitados antes, o navegador a encontrará tarde demais. Isso desperdiça um tempo valioso. Leia o guia completo sobre Resource Load Delay.
• Resource Load Duration: Este é o tempo de download do próprio recurso de LCP. Imagens grandes e não compactadas ou condições de rede lentas podem transformar essa fase em um gargalo. Leia o guia completo sobre Resource Load Duration.
• Element Render Delay: Este é o problema de "muito ocupado para pintar". O arquivo da imagem de LCP pode estar totalmente baixado. Porém, se a main thread do navegador estiver bloqueada por execução pesada de JavaScript, ele simplesmente não consegue pintar a imagem na tela. Leia o guia completo sobre Element Render Delay.

Sempre comece garantindo um TTFB rápido e que seu recurso de LCP seja descobrível. Só então passe para o tamanho do arquivo e otimizações de 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 os princípios universais primeiro. Depois, aborda as especificidades de WordPress e frameworks JS.

1. Otimizando o Time to First Byte (TTFB)

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

Soluções Universais de TTFB

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

Correções de TTFB Específicas por Plataforma

No WordPress:

• Invista em Hospedagem de Qualidade: No WordPress, o TTFB lento muitas vezes está relacionado ao ambiente de hospedagem. Uma hospedagem barata e compartilhada pode ser um gargalo. Considere uma hospedagem gerenciada de WordPress que seja otimizada para performance.
• 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ê. Esse é o núcleo de um cache eficaz nesta plataforma.

Em um JS Framework:

• Escolha a Plataforma de Hospedagem Certa: Para aplicações Node.js, plataformas como Vercel ou Netlify são altamente otimizadas para frameworks SSR/SSG. Elas oferecem cache inteligente e execução de funções serverless prontas 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). Isso evita a nova renderização a cada requisição.
• Cuidado com Cold Starts Serverless: 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 TTFB alto. Use provisioned concurrency ou estratégias de keep-alive para mitigar isso.

2. Reduzindo o Resource Load Delay

Este costuma ser o maior gargalo. Isso significa que o navegador estava pronto para trabalhar, mas não conseguiu encontrar 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 assunto, 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 descobrível na marcação HTML inicial e receba alta prioridade do navegador. Veja como conseguir isso:

• Torne o Recurso LCP Descobrível: O passo mais importante é garantir que o seu elemento LCP esteja presente no HTML que o servidor envia. Os navegadores usam um "preload scanner" de alta velocidade para examinar previamente o HTML bruto em busca de recursos como imagens e scripts para download. Se sua imagem de LCP for carregada via um background-image no CSS ou injetada com JavaScript, ela fica invisível para esse scanner. Isso causa um grande atraso. A solução mais robusta é sempre usar uma tag <img> padrão com um atributo src no seu HTML renderizado pelo servidor.
• Controle a Ordem de Carregamento com preload: Se você não puder tornar o recurso LCP diretamente descobrível (um problema comum com fontes ou imagens de fundo no CSS), a próxima melhor solução é usar <link rel="preload">. Essa tag age como uma instrução explícita no <head> do seu HTML. Ela manda o navegador começar a baixar um recurso crítico muito mais cedo do que ele encontraria naturalmente. Para detalhes de implementação e exemplos, veja nosso guia sobre como fazer o preload da imagem de LCP.
• Garanta Alta Prioridade com fetchpriority: Mesmo quando um recurso é descobrí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 forte para o navegador. Isso indica que este recurso específico é o mais importante para a experiência do usuário. Isso o ajuda a vencer a corrida por banda contra outros recursos.

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

No WordPress:

• Evite Imagens de Fundo em Page Builders: Muitos page builders facilitam definir uma hero image como um background-image de CSS em uma div. Isso a torna invisível para o preload scanner do navegador. Se possível, use um bloco <img> padrão. Caso contrário, você pode precisar de um plugin ou código customizado para fazer o preload dessa imagem específica.
• Desabilite o Lazy Loading para a Imagem de LCP: Muitos plugins de otimização vão fazer o lazy loading automático de todas as imagens. Você deve encontrar a configuração no seu plugin para excluir a imagem de LCP (e, frequentemente, as primeiras imagens da página) do lazy loading. Esse é um erro tão comum que temos um artigo dedicado sobre como corrigir imagens de LCP com lazy loading.

Em um JS Framework:

• Use Server-Side Rendering (SSR): Esta costuma ser a correção de maior impacto. Um app padrão em React com Client-Side Rendered (CSR) envia um HTML mínimo. O elemento LCP só existe depois que um pacote grande de JS é baixado e executado. Frameworks de 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 prop priority. Usar a prop de prioridade aplica o fetchpriority="high" e outras otimizações automaticamente à sua imagem de LCP.

3. Diminuindo o Resource Load Duration

Garantir que seu recurso LCP seja o menor possível continua sendo uma parte essencial do processo. Esta fase trata do tempo que leva para baixar o arquivo do recurso LCP pela rede. Para um guia completo sobre técnicas de otimização de imagens, veja nosso artigo sobre como otimizar a imagem de LCP. Para mais detalhes, leia sobre o 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 encurtar o tempo de download é diminuir o arquivo. 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 o usuário em um dispositivo mobile receba uma imagem dimensionada adequadamente para a sua tela menor. Ele não é forçado a baixar uma imagem gigante no tamanho de desktop. Uma tela mobile com 400 pixels de largura simplesmente não precisa de um arquivo de imagem com 2000 pixels de largura. Para LCPs baseados em texto, garanta que suas fontes estejam no formato eficiente WOFF2. Elas devem ter subsetting para remover caracteres não utilizados.
• Reduza a Competição de Rede: O recurso LCP precisa competir pela largura de banda de rede limitada do usuário. Adiar recursos não críticos, como scripts de analytics ou CSS para conteúdo abaixo da dobra, libera largura de banda. Assim, o navegador pode focar em baixar o recurso 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 buscas de DNS e handshakes demorados.

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 imagens no upload automaticamente, convertê-las para formatos modernos como WebP/AVIF e gerar tamanhos responsivos com srcset.
• Redimensione as Imagens Manualmente: Antes do upload, redimensione suas imagens para não serem maiores do que precisam ser. Não faça upload de uma imagem com 4000px de largura para um espaço que tem apenas 1200px de largura nas telas maiores.

Em um JS Framework:

• Use uma CDN de Imagem: Esta é uma solução poderosa. Serviços como Cloudinary, Imgix ou Akamai's Image & Video Manager podem automatizar todo o processo de otimização. Você faz upload de uma imagem de alta qualidade. Eles entregam uma versão perfeitamente dimensionada, comprimida e formatada para cada usuário por meio de uma CDN rápida.
• Aproveite as Build Tools: Ao importar uma imagem para um componente em um framework moderno, a build tool (como Webpack ou Vite) pode criar o hash e otimizar o arquivo automaticamente como parte do processo de build.

4. Encurtando o Element Render Delay

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

Soluções Universais de Render Delay

• Adie 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 usando os atributos defer ou async.
• Use Critical CSS: Uma grande folha de estilos render blocking pode atrasar a renderização. A técnica de critical CSS envolve extrair o mínimo de CSS necessário para estilizar o conteúdo acima da dobra. Você faz o inline disso no <head> e carrega o restante dos estilos de forma assíncrona.
• Divida os Long Tasks: Um script demorado pode bloquear a main thread por um longo período, impedindo a renderização. Essa também é uma das causas principais de um Interaction to Next Paint (INP) ruim. Divida seu código em pedaços menores e assíncronos que façam o yield de volta para a main thread.

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 main thread. Desative os plugins um por um para identificar os sugadores de performance.
• Use um Tema Leve: Um tema inchado com dezenas de funcionalidades que você não usa pode ser uma grande fonte de código render blocking. Escolha um tema focado em performance.
• Use Gerenciadores de Assets de Plugins: Ferramentas como Asset CleanUp ou Perfmatters permitem que você desative condicionalmente o CSS e JS de plugins específicos nas páginas em que eles não são necessários.

Em um JS Framework:

• Code Splitting é Fundamental: Não envie todo o JavaScript do seu app num único bundle gigante. Divida 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 o Lazy Loading de Componentes: Use React.lazy e Suspense para fazer o lazy loading de componentes que não são imediatamente visíveis (ex: componentes abaixo da dobra 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 de página subsequentes.

Garanta que as Páginas sejam Elegíveis para o Back/Forward Cache (bfcache)

O bfcache é uma otimização do navegador que armazena um snapshot completo de uma página na memória quando um usuário sai dela. Se ele clicar no botão de voltar, a página pode ser restaurada instantaneamente. Isso resulta num LCP próximo a zero. Muitas páginas não são elegíveis para esse cache por causa de coisas como os event listeners de unload. Use a auditoria de "bfcache" do Lighthouse para testar suas páginas e remover quaisquer recursos bloqueadores.

Use a Speculation Rules API para Prerendering

A Speculation Rules API permite informar de forma declarativa ao navegador para quais páginas um usuário deve navegar a seguir. O navegador pode então buscar e pré-renderizar essas páginas em segundo plano. Quando o usuário clica num link para uma página pré-renderizada, a navegação é instantânea. Isso leva a um LCP próximo a zero. Você pode definir essas regras numa 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 links na página atual que vão para páginas de produtos. Ele deve começar a pré-renderizá-los quando um usuário passar o mouse sobre o link.

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

Próximos Passos: Cada Fase do LCP em Detalhes

Cada fase do LCP possui um guia próprio:

• Otimizar a Imagem de LCP: Um guia completo sobre 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 o seu recurso LCP o mais cedo possível usando preload, fetchpriority e uma estrutura HTML adequada.
• Resource Load Duration: Como reduzir o tempo de download do seu recurso LCP por meio de compressão de arquivo, formatos modernos, configuração de CDN e otimização de rede.
• Element Render Delay: Como liberar a main thread do navegador para que ela possa pintar o elemento LCP imediatamente após o download. Cobre critical CSS, adiamento de JavaScript e content-visibility.