Como Otimizar o LCP do Seu Site: Guia Prático

O que é LCP e por que ele decide se o usuário fica ou sai

Largest Contentful Paint mede o tempo até o maior elemento visível na tela terminar de carregar. Pode ser uma imagem de capa, um banner ou um bloco de texto grande. O Google usa esse número como um dos três Core Web Vitals, junto com CLS e INP, para decidir ranking de busca. Mas o motivo real para otimizar o LCP não é o algoritmo do Google: é o usuário que fecha a aba antes de ver o conteúdo.

Se você trabalha com desenvolvimento web sabe que "site rápido" é vago demais para guiar decisão técnica. LCP dá um número. A meta do Google é 2,5 segundos ou menos para 75% das visitas. Abaixo disso, "bom". Entre 2,5 e 4 segundos, "precisa melhorar". Acima de 4 segundos, "ruim", e cada segundo a mais de LCP tende a derrubar conversão em páginas de captação.

Este artigo trata de como otimizar o LCP na prática, com as causas mais comuns e a ordem de prioridade para corrigir cada uma.

Como descobrir o que está causando o seu LCP alto

Antes de otimizar qualquer coisa, é preciso saber qual elemento é o LCP da página e o que está atrasando ele. Existem duas fontes de dado: laboratório e campo.

1. Abra o Chrome DevTools, aba Performance, grave o carregamento da página e procure o marcador "LCP" na linha do tempo. Ele aponta o elemento exato.
2. Rode o Lighthouse (integrado ao DevTools ou via npx lighthouse <url>) e leia a seção "Diagnostics". Ela lista o que atrasou o elemento: tempo de resposta do servidor, carregamento de recurso, ou renderização.
3. Para dado real de usuário, use o PageSpeed Insights ou o relatório de Core Web Vitals no Google Search Console. Esses dois puxam do CrUX, o conjunto de dados de campo do Chrome, e mostram o percentil 75 real, não uma simulação.

Na maioria dos sites que já auditamos, o elemento LCP é uma imagem hero ou um H1 com fonte customizada. Os dois têm correção conhecida.

Como otimizar o LCP quando o elemento é uma imagem

Se o elemento LCP é uma imagem, o problema quase sempre está em uma dessas três coisas: formato pesado, carregamento tardio, ou ausência de prioridade de rede.

Primeiro, o formato. JPEG e PNG perdem para AVIF e WebP em compressão para a mesma qualidade visual. Trocar o formato sozinho já reduz o peso do arquivo, sem mexer em dimensão ou qualidade percebida.

Segundo, loading="lazy" na imagem do LCP é um erro comum e caro. Lazy loading atrasa o carregamento até o navegador decidir que o elemento está perto da viewport, o que é exatamente o oposto do que se quer para o elemento mais importante da tela. A imagem do LCP deve carregar com prioridade máxima, nunca com lazy loading.

Em Next.js, o componente Image resolve isso com uma prop dedicada:

import Image from 'next/image';

<Image
  src="/hero.avif"
  alt="Descrição da imagem"
  width={1200}
  height={630}
  priority
/>

A prop priority remove o lazy loading padrão e adiciona um <link rel="preload"> para o navegador buscar o recurso assim que possível, em paralelo com o HTML, em vez de esperar o CSS terminar de carregar para descobrir que precisa da imagem.

Terceiro, dimensão. Servir uma imagem de 3000px de largura para um espaço de 600px desperdiça banda e tempo de decodificação. O srcset (ou o componente Image do Next.js, que gera isso automaticamente) entrega o tamanho certo para cada dispositivo.

Como otimizar o LCP quando o elemento é texto

Quando o LCP é um bloco de texto, o culpado costuma ser a fonte customizada. O navegador baixa o CSS, descobre que precisa de uma fonte externa, baixa a fonte, e só então renderiza o texto. Cada uma dessas etapas em sequência soma tempo ao LCP.

Três ajustes resolvem a maior parte dos casos:

1. Use font-display: swap ou optional para o navegador mostrar uma fonte de sistema enquanto a customizada carrega, em vez de deixar a tela em branco.
2. Faça preload da fonte crítica com <link rel="preload" as="font">, para o download começar antes do CSS terminar de ser interpretado.
3. Se o projeto usa Next.js, prefira next/font, que já resolve preload e font-display automaticamente e hospeda a fonte no mesmo domínio, eliminando uma conexão externa.

Suponha um site que hoje carrega em 4 segundos até o LCP por causa de uma fonte externa sem preload. Aplicar next/font com display: 'swap' costuma tirar de 300ms a 800ms desse tempo, porque elimina a etapa de descoberta tardia do recurso.

Como o CSS crítico e o servidor afetam o LCP

Nem toda causa de LCP alto está no front-end. O tempo de resposta do servidor, também chamado TTFB, entra na conta antes de qualquer recurso começar a baixar. Um TTFB de 1,5 segundo já consome mais da metade do orçamento de 2,5 segundos, antes mesmo do HTML chegar ao navegador.

Cache de página e de CDN reduz TTFB para conteúdo que não muda a cada visita. Para páginas dinâmicas, cache de aplicação nas consultas mais pesadas ao banco costuma render mais efeito do que qualquer ajuste de front-end.

Do lado do CSS, arquivos grandes bloqueiam a renderização até serem processados inteiros. Extrair o CSS crítico, o necessário para o conteúdo acima da dobra, e carregar o resto de forma assíncrona evita que o navegador espere por estilo que a primeira tela nem usa. Frameworks modernos como Next.js já fazem parte desse trabalho automaticamente, mas vale conferir no Lighthouse se ainda existe CSS de bloqueio na lista de diagnósticos.

Quanto tempo leva para ver resultado

Cada uma das mudanças acima é isolada e pode ser aplicada sem reescrever a aplicação: trocar formato de imagem, adicionar priority, ajustar font-display, configurar cache. Uma equipe com acesso ao código costuma aplicar as quatro em um dia de trabalho e já ver o LCP cair no próximo relatório do PageSpeed Insights.

O ganho maior aparece quando as correções somam: imagem otimizada com prioridade correta, fonte com preload, servidor respondendo rápido. Um site que hoje mede 4 segundos de LCP tem espaço real para chegar perto de 2 segundos só com esse conjunto, sem trocar arquitetura nem hospedagem.

Se seu site está com LCP acima de 2,5 segundos e você quer um diagnóstico específico para o seu caso, fale com a gente. Também vale conferir mais conteúdo técnico direto no blog.