Corrigir e Identificar 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 deseja que ele esteja abaixo de 2,5 segundos. O que se segue é o processo de diagnóstico exato que utilizo ao prestar consultoria sobre page speed.

Um Guia de Consultor para Diagnosticar e Corrigir o LCP

Meu nome é Arjen Karel e sou consultor de page speed. 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 utilizo 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 este processo. Os princípios aqui são universais, mas acredito em mostrar exemplos reais das ferramentas que construo e utilizo diariamente.

Melhorar o LCP é um processo de eliminação. De acordo com o 2025 Web Almanac, apenas 66% das origens móveis passam no LCP. Isso significa que um terço da web tem um problema 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 de forma eficaz, você deve adotar um fluxo de trabalho 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. 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 informam se você tem um problema de LCP, quais páginas são afetadas e quais usuários (móveis ou desktop) estão enfrentando isso. Você deve sempre começar por aqui para confirmar que existe um problema real.
2. Dados de Laboratório (Lighthouse, DevTools) ajudam a diagnosticar o PORQUÊ de estar acontecendo. Os dados de laboratório são coletados em um ambiente controlado e simulado. Assim que os seus dados de campo confirmarem um problema em uma página específica, você poderá usar ferramentas de laboratório para replicar consistentemente o problema e dissecar o processo de carregamento para encontrar a causa raiz.

Comece com dados de campo para que seus esforços de otimização visem mudanças que realmente impactem os usuários reais.

Etapa 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 de Core Web Vitals no Google Search Console. Faça login, navegue até o relatório e analise os gráficos de dispositivos móveis 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 Report (CrUX) 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 as URLs. Para detalhes em nível de página em tempo real, você precisa de uma ferramenta de RUM.

Real User Monitoring (RUM): detalhes em nível de página

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

Eu construí o CoreDash especificamente para isso. Você adiciona uma tag de script e ele começa a coletar dados de LCP de cada visitante real, detalhados por página, dispositivo e elemento.

Uma boa ferramenta de RUM permite ver:

• Sua pontuação precisa de LCP para qualquer URL específica.
• Um detalhamento de cada elemento LCP (por exemplo, uma imagem, um título) e quais deles estã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 o gargalo.

Olhar além do elemento 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 do LCP em páginas de destino importantes usando uma combinação de análise de dados de campo e correções direcionadas. A otimização do LCP não se trata apenas da 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 os seus elementos LCP mais lentos. Ao clicar em um elemento específico (como uma classe CSS específica para uma imagem hero), você pode filtrar todas as métricas para ver os dados de performance apenas para as páginas onde esse elemento foi o LCP.

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

Medindo o LCP com a API Performance Observer

A API Performance Observer oferece acesso direto às entradas de LCP em JavaScript. Esta é a mesma API que as ferramentas de RUM usam nos bastidores para coletar dados de campo. O trecho 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('Elemento LCP:', lastEntry.element);
  console.log('Tempo LCP:', lastEntry.renderTime || lastEntry.loadTime);
  console.log('Tamanho LCP:', 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 alterações na visibilidade da aba e restaurações de cache back/forward.

Etapa 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 "Diagnóstico" e encontre a auditoria "Elemento Largest Contentful Paint". Este gráfico de cascata divide o seu tempo de LCP em suas quatro subpartes. Sua ferramenta de RUM deve mostrar um detalhamento semelhante com base em seus dados de campo.

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

Etapa 3: Compreender as quatro fases do LCP

Cada 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 indispensável. 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 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 baixar um recurso que não conhece. Se a sua imagem 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 do próprio recurso 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 pintar". O arquivo de imagem LCP pode estar totalmente baixado, mas se a thread principal do navegador estiver bloqueada por uma pesada execução de JavaScript, ele simplesmente não conseguirá pintar a imagem na tela. Leia o guia completo sobre Element Render Delay.

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

Etapa 4: Executar a correção

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

1. Otimizando o Time to First Byte (TTFB)

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

Soluções universais para TTFB

• Ativar Caching: Esta é uma das formas mais eficazes de melhorar o TTFB. O cache 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.
• Usar um CDN: Uma Content Delivery Network serve seu conteúdo de um servidor fisicamente próximo ao seu usuário, o que reduz a latência da rede. Armazenar em cache suas páginas HTML completas na borda (edge) do 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 o Cloudflare para uma performance ideal.
• Usar compactação Brotli ou Gzip: Certifique-se de que seu servidor esteja compactando ativos baseados em texto, como HTML, CSS e JavaScript. O Brotli oferece melhor compactação que o Gzip e deve ser preferido.
• Usar HTTP/3 com 0-RTT: Certifique-se de 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), que elimina o tempo de configuração da conexão para visitantes recorrentes, proporcionando um impulso instantâneo no TTFB.
• Usar 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 dicas sobre arquivos CSS e JS críticos 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, consulte nosso artigo sobre 103 Early Hints.

Correções de TTFB específicas da plataforma

No WordPress:

• Invista em hospedagem de qualidade: No WordPress, o TTFB lento costuma estar relacionado ao ambiente de hospedagem. Hospedagens compartilhadas baratas podem ser um gargalo. Considere um host WordPress gerenciado que seja otimizado para performance.
• Use um plugin de cache: Um plugin de cache de alta qualidade (por exemplo, WP Rocket, W3 Total Cache) é inegociável. Ele cuida da geração de arquivos HTML estáticos para você, que é o núcleo do cache 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 prontas para uso.
• Implementar cache de SSR: Se você estiver usando Server-Side Rendering, armazene as páginas renderizadas em cache no servidor (por exemplo, usando Redis ou um cache em memória) para evitar a renderização em cada solicitação.
• Cuidado com os "Cold Starts" de 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 estratégias de simultaneidade provisionada ou keep-alive para mitigar isso.

2. Reduzindo o Resource Load Delay

Este é frequentemente o maior gargalo. Significa que o navegador estava pronto para trabalhar, mas não conseguiu encontrar o arquivo de imagem ou fonte principal imediatamente. Esse atraso normalmente é 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 para 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 uma alta prioridade do navegador. Veja como conseguir isso:

• Tornar 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 procurar no HTML bruto recursos como imagens e scripts para baixar. Se a sua imagem LCP for carregada por meio de um background-image 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 no servidor.
• Controlar a ordem de carregamento com preload: Se você não puder tornar o recurso LCP diretamente detectável (um problema comum com fontes ou imagens de fundo 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 antes do que ele o encontraria naturalmente. Para detalhes da implementação e exemplos, consulte nosso guia sobre como fazer o preloading da imagem LCP.
• Garantir alta prioridade com fetchpriority: Mesmo quando um recurso é detectável, o navegador pode não lhe dar 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 este recurso específico é o mais importante para a experiência do usuário, ajudando-o a vencer a corrida por largura de banda contra outros recursos.

Correções de Load Delay específicas da plataforma

No WordPress:

• Evite imagens de fundo de construtores de páginas: Muitos construtores de páginas facilitam a definição de uma imagem hero como um background-image 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. Caso contrário, você poderá precisar de um plugin ou código personalizado para fazer o preloading dessa imagem específica.
• Desativar o lazy-loading para a imagem LCP: Muitos plugins de otimização farão o lazy-load automático de todas as imagens. Você deve encontrar a configuração em seu plugin para excluir a imagem LCP (e muitas vezes as primeiras imagens da página) de sofrerem lazy-loading. Este é um erro tão comum que temos um artigo dedicado sobre como corrigir imagens LCP carregadas com lazy-loading.

Em um framework JS:

• Usar Server-Side Rendering (SSR): Esta é frequentemente a correção mais impactante. Um aplicativo React padrão com Client-Side Rendering (CSR) envia um HTML mínimo, e o elemento LCP só existe depois que um grande pacote 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.
• Usar componentes de imagem específicos do framework: Frameworks como Next.js oferecem um componente de imagem com uma prop priority. O uso da prop priority aplica automaticamente fetchpriority="high" e outras otimizações à sua imagem LCP.

3. Diminuindo a Resource Load Duration

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

Soluções universais para Load Time

• Reduzir o tamanho do arquivo com formatos modernos e imagens responsivas: A maneira mais direta de diminuir 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 dimensionada adequadamente para sua tela menor, em vez de ser forçado a baixar uma imagem enorme em tamanho desktop. Uma tela móvel de 400 pixels de largura simplesmente não precisa de um arquivo de imagem de 2.000 pixels de largura. Para LCPs baseados em texto, certifique-se de que suas fontes estejam no formato WOFF2 eficiente e que sejam submetidas a subsetting para remover caracteres não utilizados.
• Reduzir a contenção de rede: O recurso LCP tem que competir pela largura de banda limitada da rede do usuário. Adiar recursos não críticos, como scripts de analytics ou CSS para conteúdo abaixo da dobra (below-the-fold), libera largura de banda para que o navegador possa se concentrar em baixar o recurso LCP mais rapidamente.
• Hospedar recursos críticos em seu domínio principal: Evite carregar seu recurso LCP de um domínio diferente, se possível. Configurar uma nova conexão com outro servidor adiciona handshakes e pesquisas DNS demoradas.

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 imagens automaticamente no upload, convertê-las para formatos modernos como WebP/AVIF e gerar tamanhos srcset responsivos.
• Redimensionar imagens manualmente: Antes de fazer o upload, redimensione suas imagens para que não sejam maiores do que o necessário. Não envie uma imagem de 4000px de largura para um espaço que tenha apenas 1200px de largura nas maiores telas.

Em um framework JS:

• Usar um 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 o upload de uma imagem de alta qualidade e eles entregam uma versão perfeitamente dimensionada, compactada e formatada para cada usuário por meio de um CDN rápido.
• Aproveitar ferramentas de build: Ao importar uma imagem em um componente em um framework moderno, a ferramenta de build (como Webpack ou Vite) pode gerar o hash e otimizar automaticamente o arquivo como parte do processo de build.

4. Encurtando o Element Render Delay

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

Soluções universais para Render Delay

• Adiar ou remover 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.
• Usar CSS Crítico: Uma folha de estilo grande que bloqueia a renderização pode atrasá-la. A técnica de CSS crítico envolve extrair o CSS mínimo necessário para estilizar o conteúdo acima da dobra (above-the-fold), incorporá-lo (inline) no <head> e carregar o restante dos estilos de forma assíncrona.
• Dividir tarefas longas: Um script de longa execução pode bloquear a thread principal por um período prolongado, impedindo a renderização. Esta é também uma causa primária de uma Interaction to Next Paint (INP) ruim. Divida seu código em pedaços menores e assíncronos que cedam (yield) o controle de volta para a thread principal.

Correções de Render Delay específicas da plataforma

No WordPress:

• Audite seus plugins: Muitos plugins, especialmente os pesados, como sliders ou construtores de páginas complexos, podem adicionar CSS e JS significativos que bloqueiam a thread principal. Desative os plugins um por um para identificar os devoradores de performance.
• Use um tema leve: Um tema inchado com dezenas de recursos que você não usa pode ser uma grande fonte de código que bloqueia a renderização. Escolha um tema focado em performance.
• Use gerenciadores de ativos de plugins: Ferramentas como Asset CleanUp ou Perfmatters permitem desativar condicionalmente CSS e JS de plugins específicos em páginas onde 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 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.
• Componentes com Lazy Load: Use React.lazy e Suspense para carregar componentes que não são visíveis imediatamente (por exemplo, componentes abaixo da dobra ou em modais). Isso os mantém fora do pacote inicial.

Avançado: otimizando o LCP para navegações subsequentes

Corrigir o LCP inicial é importante, mas você pode fazer com que a navegação em seu site pareça instantânea otimizando para 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 o usuário sai dela. Se ele clicar no botão voltar, a página poderá ser restaurada instantaneamente, resultando em um LCP próximo de zero. Muitas páginas não são elegíveis para esse cache devido a itens como listeners de eventos unload. Use a auditoria "bfcache" do Lighthouse para testar suas páginas e remover quaisquer recursos de bloqueio.

Usar a API Speculation Rules para Prerendering

A API Speculation Rules permite que você informe declarativamente ao navegador quais páginas um usuário provavelmente navegará em seguida. 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 de 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 links na página atual que levam a páginas de produtos e para começar a pré-renderizá-los quando um usuário passar o mouse sobre o link.

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

Próximas etapas: cada fase do LCP em detalhes

Cada fase do LCP tem seu próprio guia:

• Otimizar a Imagem 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 estrutura HTML adequada.
• Resource Load Duration: Como reduzir o tempo de download do seu recurso LCP por meio de compactaçã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 ele possa pintar o elemento LCP imediatamente após o download, cobrindo CSS crítico, adiamento de JavaScript e content-visibility.