Como melhorar o LCP: as quatro partes do tempo

O LCP (Largest Contentful Paint) mede quanto tempo o maior elemento visível da tela, normalmente uma imagem ou um bloco de texto, leva para aparecer depois que o usuário abre a página. O Google considera bom um LCP de até 2,5 segundos no percentil 75 das visitas, e ruim acima de 4 segundos (web.dev). Para baixar o número, divida o tempo em quatro partes (TTFB, atraso para começar a baixar o recurso, duração do download e atraso de renderização), descubra qual delas está grande e corrija aquela. Otimizar a parte errada costuma só empurrar o tempo para outra.

Este texto segue o guia Optimize Largest Contentful Paint do web.dev (atualizado em março de 2025). Para o contexto das três métricas, veja o guia de Core Web Vitals.

O que o LCP mede e quais elementos contam

O tempo do LCP começa quando o usuário inicia a navegação. Por isso ele já inclui redirecionamentos, abertura de conexão e o tempo até o primeiro byte do HTML (web.dev). Os elementos que podem ser o "maior conteúdo" são:

• <img> (em imagens animadas, vale o primeiro quadro);

• <image> dentro de um <svg>;

• <video> (vale o que aparecer antes: a imagem de pôster ou o primeiro quadro);

• elementos com imagem de fundo carregada por url() no CSS (gradientes não contam);

• elementos de bloco que contêm texto.

O Chrome ignora alguns casos para não premiar o elemento errado: elementos com opacidade 0, elementos que cobrem a tela inteira (provavelmente um fundo) e imagens de baixa entropia, como placeholders. Só a parte visível na tela conta para o tamanho, e numa imagem redimensionada vale o menor valor entre o tamanho exibido e o tamanho real do arquivo (web.dev).

O elemento de LCP pode ser diferente em cada dispositivo: no celular, o título; no desktop, a foto do banner. Vale conferir nos dois antes de decidir o que otimizar.

As quatro partes do tempo de LCP

O web.dev divide o LCP em quatro subpartes. Somadas, elas dão o LCP inteiro:

As porcentagens são do próprio guia e servem como referência, não como regra (web.dev). A leitura útil é comparativa: se as duas partes de "atraso" somam boa parte do LCP, o problema não é o tamanho da imagem, e comprimir mais o arquivo vai mudar pouco.

Como medir cada parte

Comece pelos dados de campo, de usuários reais, e só depois vá para o laboratório. A diferença entre essas fontes está explicada em Lighthouse, CrUX e RUM. As ferramentas que mostram as quatro partes são estas:

1. A biblioteca web-vitals, na versão de atribuição, calcula as quatro partes na visita de cada usuário e diz qual foi o elemento e a URL do recurso (GitHub GoogleChrome/web-vitals). É o jeito de saber o que acontece no aparelho de quem visita o site.

2. O painel Performance do Chrome DevTools mostra o LCP local ao lado do LCP de campo do CrUX, e os Insights da gravação trazem o tempo de cada parte (web.dev).

3. O PageSpeed Insights mostra os dados do CrUX da URL ou da origem, separados em celular e desktop. O diagnóstico do Lighthouse inclui a divisão do elemento de LCP.

Um exemplo mínimo com a web-vitals, que registra as quatro partes no console:

import {onLCP} from 'web-vitals/attribution';

onLCP(({value, attribution}) => {
  console.log('LCP', value, attribution.target, attribution.url);
  console.log('TTFB', attribution.timeToFirstByte);
  console.log('Atraso de carregamento', attribution.resourceLoadDelay);
  console.log('Duração do carregamento', attribution.resourceLoadDuration);
  console.log('Atraso de renderização', attribution.elementRenderDelay);
});

Em produção, troque o console.log por um envio para o seu sistema de análise. Dois indicadores ajudam no diagnóstico rápido: um intervalo grande entre TTFB e FCP (First Contentful Paint, a primeira pintura de conteúdo) costuma indicar CSS ou JavaScript bloqueando a renderização, ou renderização pesada no cliente; um intervalo grande entre FCP e LCP indica que o recurso do LCP não está disponível cedo (web.dev).

Como reduzir o TTFB: servidor, CDN e cache

Se o HTML demora a chegar, nada mais começa. O guia de otimização de TTFB do web.dev aponta estas frentes:

• Hospedagem com memória e capacidade para o tráfego que o site recebe.

• CDN, para servir o conteúdo de um servidor mais perto do usuário.

• Cache na borda da CDN com cabeçalhos Cache-Control, inclusive do HTML quando ele não é personalizado. Parâmetros únicos na URL (de campanha, por exemplo) podem impedir que a página saia do cache.

• Menos redirecionamentos. Os mais comuns são os da mesma origem, como falta de https:// ou barra final inconsistente. O HSTS evita o redirecionamento de HTTP para HTTPS.

• HTML enviado em partes (streaming) ou páginas estáticas quando não há personalização.

• 103 Early Hints, para o navegador começar a baixar recursos críticos enquanto o servidor monta a resposta.

Para saber onde o servidor gasta tempo, o cabeçalho Server-Timing expõe cada etapa do backend e aparece no DevTools e na API de Navigation Timing:

Server-Timing: db;desc="Database";dur=121.3, ssr;desc="Server-side Rendering";dur=212.2

Os nomes e números acima são o exemplo do web.dev; cada backend informa as próprias etapas.

Como reduzir o atraso de carregamento do recurso

O objetivo aqui é o navegador começar a baixar a imagem do LCP logo depois de receber o HTML.

Deixe a imagem visível no HTML inicial

O navegador tem um leitor antecipado (preload scanner) que procura recursos no HTML antes mesmo de montar a página. Ele só encontra a imagem se ela estiver no markup com src ou srcset. Imagem inserida por JavaScript, carregada por biblioteca de lazy loading ou definida só no CSS fica escondida dele (web.dev).

Se a imagem do LCP precisa vir de um CSS externo, como um fundo de banner, faça o preload dela no <head>:

<link rel="stylesheet" href="/css/estilos.css">
<link rel="preload" fetchpriority="high" as="image"
      href="/img/banner.webp" type="image/webp">

Dê prioridade alta para a imagem do LCP

O atributo fetchpriority="high" pede ao navegador que baixe a imagem antes das outras. O web.dev recomenda usar em uma ou duas imagens no máximo, e fetchpriority="low" em imagens que começam fora da tela, como os slides seguintes de um carrossel:

<img src="/img/banner.webp" fetchpriority="high"
     width="1200" height="600" alt="Descrição do banner">

<img src="/img/slide-3.webp" fetchpriority="low"
     width="1200" height="600" alt="Descrição do slide">

Pelos dados de compatibilidade do MDN, o fetchpriority funciona no Chrome 101, no Firefox 132 e no Safari 17.2 em diante (MDN browser-compat-data). Navegadores antigos ignoram o atributo sem quebrar nada.

Não use lazy loading na imagem do LCP

loading="lazy" faz o navegador esperar o layout para decidir se baixa a imagem, e isso atrasa justamente o recurso mais importante. O web.dev recomenda carregar normalmente as imagens da área visível inicial e manter o lazy loading só para as de baixo (web.dev). Temas e plugins de CMS às vezes aplicam loading="lazy" em todas as imagens; confira o HTML gerado.

<!-- Evite na imagem do LCP -->
<img src="/img/banner.webp" loading="lazy" alt="...">

<!-- Prefira -->
<img src="/img/banner.webp" fetchpriority="high" alt="...">

Quando possível, sirva a imagem do LCP na mesma origem do HTML, para reaproveitar a conexão já aberta.

Como reduzir a duração do carregamento

O guia lembra que, na maioria das vezes, a duração do download não é o maior gargalo. Confira os dados antes de investir aqui (web.dev). Quando é, as correções são:

• Formatos modernos, como AVIF e WebP, e compressão adequada.

• Imagem no tamanho em que ela aparece, com srcset e sizes para o navegador escolher a versão certa.

• CDN, de preferência uma CDN de imagens.

• Poucos recursos com prioridade alta ao mesmo tempo, para não disputarem banda.

• Cache eficiente, para a visita seguinte não baixar de novo.

Um exemplo de imagem responsiva, adaptado do MDN (MDN):

<img
  srcset="/img/banner-480.webp 480w, /img/banner-800.webp 800w"
  sizes="(width <= 600px) 480px, 800px"
  src="/img/banner-800.webp"
  width="800" height="400"
  fetchpriority="high"
  alt="Descrição do banner">

O navegador lê o sizes, usa a primeira condição verdadeira para saber a largura do espaço e escolhe no srcset a imagem que atende. Os atributos width e height não mudam o LCP, mas evitam que a página pule quando a imagem chega (veja como corrigir o CLS).

Como reduzir o atraso de renderização

Aqui a imagem já foi baixada, mas algo impede o navegador de mostrá-la. As causas mais comuns, segundo o web.dev:

CSS que bloqueia a renderização

O navegador não pinta nada enquanto não termina de baixar as folhas de estilo do <head>. Se o CSS chega depois da imagem, a imagem espera. As saídas são remover CSS não usado, adiar o que não é necessário na primeira tela, minificar e comprimir. Colocar o CSS direto no HTML (inline) só compensa quando ele é pequeno.

JavaScript síncrono no head

Script sem defer ou async no <head> trava o processamento do HTML até ser baixado e executado:

<!-- Bloqueia -->
<head>
  <script src="/js/main.js"></script>
</head>

<!-- Não bloqueia: executa depois de processar o HTML -->
<head>
  <script src="/js/main.js" defer></script>
</head>

Conteúdo montado no navegador

Quando a página depende de JavaScript para gerar o HTML (renderização no cliente), a imagem do LCP só passa a existir depois que o script baixa e roda. Mesmo com preload, o elemento ainda espera o código. O web.dev recomenda renderização no servidor e, quando a arquitetura permite, páginas pré-renderizadas ou geradas de forma estática. Tarefas longas de JavaScript na thread principal também atrasam a pintura; dividir essas tarefas ajuda o LCP e o INP (veja como melhorar o INP).

Fontes, quando o LCP é texto

Se o elemento de LCP é um título, a fonte web pode segurar o texto invisível enquanto carrega. A propriedade font-display controla isso: com block o texto pode ficar invisível por 2 a 3 segundos; com swap ele aparece na hora com a fonte reserva; com optional o navegador espera no máximo 100 ms e, se a fonte não chegou, segue com a reserva (web.dev). Para o LCP, o guia recomenda qualquer valor diferente de auto e block. Arquivos em WOFF2, subconjuntos de caracteres e menos famílias de fonte também reduzem o tempo de download. O swap pode causar deslocamento quando a fonte troca, assunto do artigo sobre CLS.

Como confirmar a correção nos dados de campo

O Lighthouse e o DevTools mostram o efeito da mudança na hora, no seu computador. O resultado que conta é o dos usuários reais, e ele demora a aparecer. Para acompanhar isso em vários sites de uma vez, veja como monitorar a performance de vários sites.

1. Publique a correção e anote a data.

2. Se tiver RUM (medição de usuários reais) com a web-vitals, compare o percentil 75 do LCP antes e depois, separado por celular e desktop. As quatro partes mostram se a fatia que você atacou diminuiu.

3. No CrUX, pelo PageSpeed Insights ou pela API, o valor é uma média móvel de 28 dias (Chrome for Developers). A melhora entra aos poucos, conforme os dias antigos saem da janela; espere o ciclo completo antes de concluir.

4. Confira se a fatia que você reduziu não reapareceu em outra parte. Remover o lazy loading, por exemplo, pode transformar atraso de carregamento em duração de carregamento se a imagem for pesada.

Lembre que o CrUX reúne dados só de usuários do Chrome que aceitaram compartilhar estatísticas, no desktop e no Android; Chrome no iOS fica de fora (Chrome for Developers). Páginas com pouco tráfego podem não ter dados próprios no CrUX.

Como verificar o seu site

No WebVyze, o diagnóstico de LCP usa o Google PageSpeed para apontar o elemento e o que atrasa a página, e o teste de Core Web Vitals mostra os dados do CrUX dos últimos 28 dias, no celular e no desktop, para até 10 URLs. As duas ferramentas são grátis. Nos planos pagos, um script de visitantes reais baseado na biblioteca web-vitals registra o LCP de cada visita com a causa.