Corrija e identifique problemas de Largest Contentful Paint (LCP)

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

Um Guia de 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 um problema de carregamento. Encontre a fase mais lenta, corrija, meça novamente.

A Metodologia de Diagnóstico: Field Data Primeiro, Lab Data Depois

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

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

Comece com field data para que seus esforços de otimização foquem 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, se houver, possuem um LCP ruim.

Um Ponto de Partida Acessível: Google Search Console

Um lugar válido para começar é o relatório de 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: superior a 2,5 s", 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 atualiza lentamente e agrupa 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 é um esforço de engenharia significativo.

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, divididos por página, dispositivo e elemento.

Uma boa ferramenta de RUM permite que você veja:

• Sua pontuação precisa de LCP para qualquer URL específico.
• Um detalhamento de cada elemento do LCP (por exemplo, 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 elemento do LCP em si é 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 focou em identificar e resolver o gargalo específico de LCP nas principais landing pages usando uma combinação de análise de field data e correções direcionadas. Otimização de LCP não é apenas sobre a imagem. Você precisa entender o pipeline completo de carregamento: resposta do servidor, descoberta de recursos, download e renderização.

Por exemplo, no CoreDash, você pode navegar até a página de LCP e ver uma tabela de dados que mostra os seus elementos de LCP mais lentos. Ao clicar em um elemento específico (como uma classe CSS particular de uma hero image), você pode filtrar todas as métricas para ver 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 seu elemento de LCP mais comum. Esse é o seu alvo.

Medindo o LCP com a Performance Observer API

A Performance Observer API fornece acesso direto a entradas de LCP em JavaScript. Esta é a mesma API que as ferramentas de RUM usam nos bastidores para coletar field data. O snippet a seguir registra cada candidato a 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ção em produção você deve usar a biblioteca web-vitals, que lida com casos extremos, como mudanças na 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 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". Este gráfico em cascata divide o tempo do seu LCP em suas quatro sub-partes. Sua ferramenta de RUM deve mostrar um detalhamento semelhante baseado no seu field data.

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

Guia passo a passo: prefere trabalhar no DevTools? Diagnosticar o LCP com o painel Performance do Chrome DevTools mostra como gravar um trace com throttling e ler as mesmas quatro sub-partes no 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 tem um guia dedicado neste site cobrindo técnicas de otimização específicas.

• Time to First Byte (TTFB): Esta é a base incontornável. Uma resposta de servidor lenta é uma adição direta, milissegundo a milissegundo, ao seu LCP. Antes de otimizar uma única imagem, você deve garantir que seu servidor está respondendo rapidamente. Saiba mais sobre como otimizar o TTFB.
• Resource Load Delay: Este é o "problema de descoberta" e uma das questões mais comuns. O navegador não pode baixar um recurso sobre o qual não sabe. Se sua imagem de LCP está escondida em um arquivo CSS ou JavaScript, ou até mesmo se está no HTML, mas outros recursos são solicitados primeiro, o navegador a encontra tarde demais, desperdiçando um tempo valioso. Leia o guia completo sobre Resource Load Delay.
• Resource Load Duration: Este é o tempo de download do recurso de LCP em si. Imagens grandes 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 estar "muito ocupado para renderizar". O arquivo da imagem de LCP pode estar totalmente baixado, mas se a main thread do navegador estiver bloqueada por execução pesada de JavaScript, ele simplesmente não consegue 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 de LCP seja descobrível antes de prosseguir 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 e, depois, as especificidades do WordPress e de frameworks JS.

1. Otimizando o Time to First Byte (TTFB)

Se o seu TTFB está lento (uma boa meta é abaixo de 800 ms), 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

• Habilite o Caching: Esta é uma das maneiras mais eficientes de melhorar o TTFB. O caching gera e armazena uma cópia da página para que ela possa ser servida instantaneamente sem esperar que o servidor a construa do zero em cada visita.
• Use uma CDN: Uma Content Delivery Network serve o seu conteúdo a partir de um servidor fisicamente próximo ao seu usuário, o que reduz a latência de rede. Armazenar em cache suas páginas HTML completas na borda da CDN é uma estratégia poderosa para um TTFB global rápido. Para dicas detalhadas de configuração de CDN, consulte nosso guia sobre como configurar a Cloudflare para performance ideal.
• Use Compressão Brotli ou Gzip: Garanta que seu servidor esteja compactando assets baseados em texto como HTML, CSS e JavaScript. O Brotli oferece melhor compactação que o Gzip e deve ser preferido.
• Use HTTP/3 com 0-RTT: Garanta que seu servidor esteja configurado para usar HTTP/3. Ele oferece vantagens significativas de performance, 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 impulso instantâneo no 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 sobre arquivos CSS e JS críticos ao navegador enquanto ele ainda está preparando o documento HTML completo, permitindo que os downloads comecem ainda mais cedo. Para um guia completo de implementação, consulte nosso artigo sobre 103 Early Hints.

Correções de TTFB Específicas da Plataforma

No WordPress:

• Invista em Hospedagem de Qualidade: No WordPress, um TTFB lento está frequentemente relacionado ao ambiente de hospedagem. Hospedagens compartilhadas e baratas podem ser um gargalo. Considere um host WordPress gerenciado que seja otimizado para performance.
• Use um Plugin de Caching: Um plugin de caching 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 efetivo nesta plataforma.

Em um JS Framework:

• Escolha a Plataforma de Hospedagem Correta: Para aplicações Node.js, plataformas como Vercel ou Netlify são altamente otimizadas para frameworks SSR e oferecem caching inteligente e execução de funções serverless por padrão.
• Implemente Caching SSR: Se você estiver usando Server-Side Rendering, armazene em cache as páginas renderizadas no servidor (ex: usando Redis ou um in-memory cache) para evitar a nova renderização em cada requisição.
• Cuidado com os Cold Starts Serverless: Se estiver usando funções serverless para renderização, esteja ciente de que um "cold start" (a primeira requisiçã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 é frequentemente o maior gargalo. Isso significa que o navegador estava pronto para trabalhar, mas não conseguiu encontrar sua imagem principal ou arquivo de fonte imediatamente. Este atraso é tipicamente causado por um de dois problemas: o recurso é descoberto tarde ou recebe uma prioridade de download baixa. 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 de LCP seja descobrível na marcação HTML inicial e receba uma prioridade alta pelo navegador. Veja como alcançar isso:

• Torne o Recurso de LCP Descobrível: O passo mais importante é garantir que o seu elemento de LCP esteja presente no HTML que o servidor envia. Navegadores usam um "preload scanner" de alta velocidade para olhar adiante no HTML bruto em busca de recursos como imagens e scripts para baixar. Se a sua imagem de LCP for carregada via um background-image de CSS ou injetada com JavaScript, ela fica 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 no seu HTML renderizado pelo servidor.
• Controle a Ordem de Carregamento com preload: Se você não puder tornar o recurso de LCP diretamente descobrível (um problema comum com fontes ou imagens de background no CSS), a segunda 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 antes do que ele teria encontrado naturalmente. Para detalhes de implementação e exemplos, consulte 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 poderosa para o navegador de que esse recurso específico é o mais importante para a experiência do usuário, ajudando-o a vencer a corrida por banda contra outros recursos.

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

No WordPress:

• Evite Background Images de 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 em vez disso. Se não, você pode precisar de um plugin ou código customizado para fazer o preload dessa imagem específica.
• Desative o Lazy Loading para a Imagem de LCP: Muitos plugins de otimização aplicam lazy loading automaticamente em todas as imagens. Você deve encontrar a configuração no seu plugin para excluir a imagem de LCP (e muitas vezes as primeiras imagens na página) do lazy loading. Este é um erro tão comum que temos um artigo dedicado sobre como consertar imagens de LCP com lazy loading.

Em um JS Framework:

• Use Server-Side Rendering (SSR): Esta é frequentemente a correção de maior impacto. Um app React padrão com Client-Side Rendering (CSR) envia um HTML mínimo, e o elemento de LCP só existe depois que um bundle JS grande é baixado e executado. Frameworks SSR como Next.js ou Remix entregam o HTML completo, incluindo a tag <img>, para que o navegador possa descobri-lo 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 priority aplica automaticamente o fetchpriority="high" e outras otimizações à sua imagem de LCP.

3. Reduzindo a Resource Load Duration

Garantir que seu recurso de LCP seja o menor possível ainda é uma parte essencial do processo. Esta fase é sobre o tempo que leva para baixar o arquivo do recurso de LCP através da rede. Para um guia completo de técnicas de otimização de imagem, consulte nosso artigo sobre otimização da imagem de LCP, e para mais detalhes sobre Resource Load Duration especificamente.

Soluções Universais de Load Time

• 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 um usuário em um dispositivo móvel receba uma imagem devidamente dimensionada para sua tela menor, em vez de ser forçado a baixar uma imagem massiva no tamanho para desktop. Uma tela de celular 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 formato eficiente WOFF2 e sofram subsetting para remover caracteres não utilizados.
• Reduza a Contenção de Rede: O recurso de LCP tem que competir pela largura de banda limitada do usuário. Adiar recursos não críticos, como scripts de analytics ou CSS de conteúdo below-the-fold, libera banda para que o navegador possa focar em baixar o recurso de LCP mais rápido.
• Hospede Recursos Críticos no seu Domínio Principal: Evite carregar seu recurso de LCP de um domínio diferente se possível. Configurar uma nova conexão para outro servidor adiciona lookups de DNS e handshakes demorados.

Correções de Load Time Específicas da Plataforma

No WordPress:

• Use um Plugin de Otimização de Imagem: Ferramentas como ShortPixel ou Smush podem compactar automaticamente as imagens no upload, convertê-las para formatos modernos como WebP/AVIF e gerar tamanhos responsivos via srcset.
• Redimensione Imagens Manualmente: Antes de enviar, 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 de apenas 1200px de largura nas telas maiores.

Em um JS Framework:

• 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 via 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 fazer o hash automaticamente e otimizar o arquivo como parte do processo de build.

4. Encurtando o Element Render Delay

O recurso terminou de ser baixado, mas ainda não está na tela. Isso significa que a main thread do navegador está ocupada com outras tarefas e não consegue 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 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 CSS Crítico: Uma stylesheet grande e render-blocking pode atrasar a renderização. A técnica de CSS crítico envolve extrair o CSS mínimo necessário para estilizar o conteúdo above-the-fold, embuti-lo no <head> e carregar o restante dos estilos de forma assíncrona.
• Divida as Long Tasks: Um script de longa execução pode bloquear a main thread por um período prolongado, impedindo a renderização. Esta é também uma causa principal de Interaction to Next Paint (INP) ruim. Divida seu código em pedaços menores e assíncronos que façam yield de volta para a main thread.

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

No WordPress:

• Audite Seus Plugins: Plugins demais, especialmente os pesados como sliders ou page builders complexos, podem adicionar um CSS e JS significativo que bloqueia a main thread. Desative os plugins um por um para identificar os vilões da performance.
• Use um Tema Leve: Um tema inflado com dezenas de recursos que você não usa pode ser uma fonte principal de código render-blocking. Escolha um tema focado em performance.
• Use Gerenciadores de Assets de Plugin: Ferramentas como Asset CleanUp ou Perfmatters permitem que você desative condicionalmente o CSS e JS de plugins específicos em páginas onde eles não são necessários.

Em um JS Framework:

• Code Splitting é Fundamental: Não entregue todo o JavaScript do seu app em um pacote gigante. Divida 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 Loading de Componentes: Use React.lazy e Suspense para aplicar lazy loading em componentes que não são imediatamente visíveis (por exemplo, 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 a navegação no seu site parecer instantânea ao otimizar os carregamentos de páginas 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, resultando em um LCP próximo a zero. Muitas páginas não são elegíveis para esse cache devido a coisas como event listeners de unload. Use a auditoria "bfcache" do Lighthouse para testar suas páginas e remover quaisquer recursos bloqueantes.

Use a Speculation Rules API para Prerendering

A Speculation Rules API permite que você informe declarativamente ao navegador para quais páginas é provável que um usuário navegue a seguir. O navegador pode então buscar e pré-renderizar essas páginas em segundo plano. Quando o usuário clica em um link para uma página pré-renderizada, a navegação é instantânea, levando a um LCP próximo a zero. Você pode definir estas 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 links na página atual que vão para páginas de produto e 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, repita.

Próximos Passos: Cada Fase do LCP em Detalhes

Cada fase do LCP tem seu próprio guia:

• Otimizar a Imagem de LCP: Um guia completo sobre seleção de formato de imagem, imagens responsivas, preloading e erros comuns na otimização de imagens.
• Resource Load Delay: Como garantir que o navegador descubra seu recurso de 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 de LCP através 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 renderizar o elemento de LCP imediatamente após o download, cobrindo CSS crítico, adiamento de JavaScript e content-visibility.