LCP: como otimizar o Largest Contentful Paint

O Largest Contentful Paint (LCP) é a métrica dos Core Web Vitals que influencia o ranqueamento no Google desde 2021. Não é só um número técnico: ele mostra com que rapidez o usuário percebe a página como carregada. Um LCP ruim significa que o visitante vê uma tela em branco ou uma imagem principal que não carregou, e sai antes de o conteúdo aparecer.

zoom_in

O que é LCP e por que ele importa

O LCP mede o tempo entre o início da navegação e o momento em que o maior elemento de conteúdo (texto ou imagem) fica visível na área de visualização. Esse é o limite que o Google usa para considerar o carregamento “concluído” do ponto de vista da experiência do usuário.

Diferente do FCP (First Contentful Paint), que é registrado no primeiro pixel, o LCP acompanha especificamente o conteúdo relevante. Uma página pode mostrar um indicador de carregamento em 0,3 s, mas, se a imagem principal aparecer em 5 s, o LCP será de 5 s.

Quais elementos o navegador considera candidatos a LCP

O navegador não acompanha todos os elementos da página. Ele observa tipos específicos e, quando o carregamento termina, escolhe o maior deles por área dentro da área visível.

Elementos <img>

Imagens comuns. É o candidato a LCP mais frequente na maioria das páginas. O tempo é o momento em que a imagem decodificada aparece na área visível.

<image> dentro de SVG

Imagens dentro de elementos SVG. Para fins de LCP, são tratadas do mesmo jeito que os elementos img comuns.

background-image no CSS

Imagens de fundo definidas via CSS. Ponto importante: o navegador não começa a carregar um background-image antes de construir o CSSOM. Essa é uma das principais fontes de atraso do LCP.

Blocos de texto

Elementos <p>, <h1>–<h6>, <div> e outros com conteúdo de texto. Se um bloco de texto for maior que qualquer imagem, ele se torna o LCP.

<video> com poster

O quadro de pôster de um elemento de vídeo (atributo poster). Se o vídeo ocupa a maior parte da tela, o poster precisa carregar o mais rápido possível.

Como o tempo de LCP se divide

O Google divide o LCP em 4 subcomponentes. Entender cada um é essencial para diagnosticar corretamente e definir a prioridade das otimizações.

Regra: ataque o componente com a maior participação. Se o TTFB ocupa 3 dos 5 s do LCP, otimizar imagens terá efeito mínimo. Primeiro, melhore o tempo de resposta do servidor.

Principais causas de LCP lento

90% dos LCP ruins têm as mesmas causas principais. O diagnóstico leva 15 minutos no DevTools ou no PageSpeed Insights.

Como otimizar o LCP: um plano passo a passo

A otimização do LCP não é um truque único, e sim um conjunto de melhorias interligadas. Trabalhe em sequência, começando pelos itens de maior impacto.

Passo 1: reduza o TTFB para 200–400 ms

O TTFB é a base. Se o servidor for lento, todas as outras otimizações esbarram nesse limite.

1. Configure o cache HTTP: Cache-Control: max-age=31536000 para arquivos estáticos e s-maxage para proxies de CDN.
2. Ative a compressão: Brotli (preferido) ou gzip para HTML, CSS e JS. O Brotli gera arquivos 15–25% menores que o gzip.
3. Conecte uma CDN: Cloudflare, Fastly, BunnyCDN. Em sites estáticos, o cache na borda reduz o TTFB para 20–50 ms.
4. Otimize o banco de dados: índices nos campos mais consultados e cache de consultas via Redis ou Memcached.
5. Use HTTP/2 ou HTTP/3: várias requisições por uma única conexão, sem head-of-line blocking.

Passo 2: otimize a imagem do LCP

Se o elemento do LCP for uma imagem (banner principal, foto de produto), esta é uma otimização de alto retorno.

• Converta para formatos modernos: WebP (economia de 25–35% em relação ao JPEG) ou AVIF (40–55% em relação ao JPEG). Use <picture> com um fallback.
• Adicione fetchpriority="high" à imagem do LCP: o navegador vai carregá-la com prioridade máxima.
• Remova loading="lazy" do elemento do LCP. O lazy load só é indicado para imagens abaixo da primeira dobra da tela.
• Adicione <link rel="preload" as="image"> no <head> para a imagem do LCP: o navegador começa o carregamento antes de o body ser analisado.
• Defina os atributos width e height para evitar CLS. O navegador reserva o espaço antes de a imagem carregar.
• Configure srcset e sizes para carregamento responsivo: no celular, a imagem será de 400 px em vez de 1600 px.

Passo 3: elimine recursos que bloqueiam a renderização

Cada recurso que bloqueia a renderização adiciona atraso ao LCP. A meta: nenhum recurso bloqueante no caminho crítico.

Passo 4: otimize as fontes, se o LCP for um texto

Quando o elemento do LCP é um bloco de texto (título, lead), o problema costuma ser o atraso na renderização da fonte.

1. Adicione font-display: swap ou optional no @font-face. O navegador mostra a fonte do sistema na hora e troca pela personalizada quando ela carregar.
2. Use <link rel="preload" as="font" type="font/woff2" crossorigin> para as fontes críticas no <head>.
3. Limite o conjunto de caracteres: use subsetting para carregar apenas os glifos necessários (latino, cirílico).
4. Hospede as fontes no próprio servidor, em vez de carregá-las do Google Fonts. Isso elimina uma consulta DNS e uma conexão extras.
5. Configure size-adjust, ascent-override e descent-override no @font-face para reduzir o CLS na troca da fonte.

Passo 5: SSR/SSG para frameworks JavaScript

Se o site roda em React, Vue ou Next.js sem SSR, o LCP tende a ser alto por padrão: o navegador precisa baixar e executar o JavaScript e só então renderizar o conteúdo.

Server-Side Rendering (SSR)

O HTML é gerado no servidor a cada requisição. O navegador recebe o HTML pronto, faz a análise e o elemento do LCP aparece sem esperar pelo JS. É a melhor opção para conteúdo dinâmico.

Static Site Generation (SSG)

O HTML é gerado no momento do build. O servidor entrega um arquivo pronto, com TTFB e LCP no máximo de velocidade. Ideal para blogs, landing pages e páginas sem personalização.

Incremental Static Regeneration (ISR)

SSG com regeneração periódica (Next.js). Combina a velocidade dos arquivos estáticos com a atualidade dos dados. Ótimo para a maioria dos conteúdos de CMS.

Streaming SSR

O servidor começa a enviar o HTML antes de terminar a renderização, e o navegador exibe o conteúdo progressivamente. React 18 + Next.js 13+ oferecem isso e funcionam sem configuração adicional.

Passo 6: background-image em CSS como LCP

Se o elemento do LCP usa background-image via CSS, o navegador não consegue começar a carregá-lo antes de construir o CSSOM. É uma das causas mais traiçoeiras de LCP lento.

• Troque o background-image do CSS por <img fetchpriority="high">: o navegador a descobre durante a análise do HTML.
• Se a troca não for possível, use <link rel="preload" as="image"> para iniciar o carregamento manualmente.
• Para fundos responsivos, use imagesrcset e imagesizes na tag de preload.
• Mova o CSS que contém o background-image do LCP para um <style> inline. Isso elimina uma requisição de rede.

Ferramentas para medir e diagnosticar o LCP

Diagnóstico correto importa mais do que otimizar às cegas. Use os dois tipos de ferramenta: Lab (testes sintéticos) e Field (usuários reais).

Como diagnosticar o LCP no Chrome DevTools

O DevTools é a ferramenta mais precisa para entender o que está atrasando o LCP em uma página específica.

1. Abra o DevTools → Performance → clique em Record, recarregue a página e pare a gravação.
2. Em Timings, encontre o marcador de LCP: ele mostra o tempo exato e o elemento.
3. Analise o waterfall: encontre o recurso do elemento do LCP e veja quando o carregamento dele começou em relação ao TTFB.
4. Observe as barras vermelhas: são recursos que bloqueiam a renderização. Elas aparecem logo antes do LCP.
5. Na aba Network, filtre por tipo Image, encontre a imagem do LCP e confira a prioridade (deve ser High).
6. Na aba Coverage, veja o CSS e o JS não utilizados. Muito código não utilizado = atraso no LCP.

Perguntas frequentes