O LCP (Largest Contentful Paint) mede o tempo até o maior elemento de conteúdo visível na viewport inicial ser renderizado. Na prática, quando falamos em “conteúdo acima da dobra”, estamos falando do que o usuário vê sem rolar a página: geralmente o herói (hero), título principal, banner, imagem de destaque, card principal ou um bloco grande de texto. Otimizar LCP com foco acima da dobra significa garantir que esse conteúdo crítico seja entregue, decodificado e pintado o mais cedo possível, com o mínimo de bloqueios por CSS/JS, fontes e imagens.
Este capítulo foca em estratégias diretamente ligadas ao caminho crítico de renderização do conteúdo acima da dobra: como escolher e estabilizar o elemento que vira LCP, como priorizar recursos essenciais (HTML, CSS crítico, imagem do herói, fontes), como reduzir trabalho no main thread antes do primeiro paint relevante e como evitar que o LCP “mude” para um elemento mais tardio.
O que “acima da dobra” muda na estratégia de LCP
O LCP não é “o tempo de carregamento da página inteira”. Ele é influenciado por uma cadeia de eventos que, para o conteúdo acima da dobra, costuma envolver:
- TTFB e entrega do HTML: o navegador precisa receber o HTML inicial para descobrir o que renderizar.
- Descoberta e carregamento de CSS: CSS bloqueia renderização; sem estilos, o navegador pode atrasar a pintura do layout final.
- Descoberta e carregamento do recurso do herói (imagem/vídeo/poster): se o LCP for uma imagem, o tempo de download e decodificação pesa muito.
- Fontes: se o LCP for texto grande, a estratégia de carregamento de fontes pode atrasar a pintura (ou causar troca de fonte).
- Execução de JS: scripts podem atrasar parsing, bloquear o thread principal e impedir que o navegador finalize layout/paint.
Como o LCP é medido na viewport inicial, otimizações “globais” que não afetam o caminho crítico (por exemplo, otimizar imagens abaixo da dobra) podem não mover o ponteiro do LCP. O foco aqui é: tudo que atrasa o primeiro render do herói deve ser priorizado; o restante deve ser adiado.
Escolhendo e “fixando” o elemento que será o LCP
Uma armadilha comum é o LCP variar entre sessões: às vezes é o título, às vezes é a imagem, às vezes é um card que aparece depois. Isso dificulta a otimização porque você melhora um elemento e o LCP “migra” para outro.
Continue em nosso aplicativo
Você poderá ouvir o audiobook com a tela desligada, ganhar gratuitamente o certificado deste curso e ainda ter acesso a outros 5.000 cursos online gratuitos.
ou continue lendo abaixo...Baixar o aplicativo
Boas práticas para estabilizar o LCP
- Defina um herói claro: um elemento principal acima da dobra (imagem + título) com dimensões previsíveis.
- Evite inserir conteúdo acima da dobra tardiamente (ex.: banners de consentimento que empurram layout, promoções injetadas por JS, carrosséis que só aparecem após hidratação).
- Evite trocar o elemento do herói após o carregamento (ex.: renderizar um placeholder e depois substituir por outro componente maior).
- Reserve espaço para o herói com width/height ou aspect-ratio, para evitar reflow e atrasos de pintura.
Se o herói é uma imagem, garanta que ela seja realmente a maior área visível e que carregue cedo. Se o herói é texto (headline grande), garanta que o CSS e as fontes não atrasem a pintura.
Estratégia 1: Priorizar o recurso do herói (imagem) sem “furar” o resto
Quando o LCP é uma imagem acima da dobra, o objetivo é reduzir o tempo entre o HTML chegar e a imagem estar baixada e decodificada. Isso envolve: descoberta rápida, prioridade alta, tamanho adequado e formato eficiente.
Passo a passo prático: tornar a imagem do herói “descoberta cedo”
1) Garanta que a imagem esteja no HTML inicial. Se a imagem só aparece após renderização client-side (hidratação), o navegador só vai descobri-la tarde. Prefira SSR/SSG ou ao menos render inicial com a tag <img> presente.
2) Evite background-image para o herói quando possível. Imagens em CSS (background) são descobertas após o CSS ser baixado e processado, o que pode atrasar o início do download. Se precisar de background por design, considere alternativas: usar <img> com object-fit: cover ou pré-carregar a URL.
3) Use fetchpriority e/ou preload para elevar a prioridade do herói.
<img src="/img/hero-1280.avif" alt="Produto em destaque" width="1280" height="720" fetchpriority="high" decoding="async" />Se você usa srcset, o preload deve apontar para o recurso correto (ou usar imagesrcset):
<link rel="preload" as="image" href="/img/hero-1280.avif" />Em cenários responsivos:
<link rel="preload" as="image" imagesrcset="/img/hero-640.avif 640w, /img/hero-1280.avif 1280w" imagesizes="100vw" />4) Não use lazy-loading no herói. Evite loading="lazy" para imagens acima da dobra; isso pode atrasar o download. Use o padrão (eager) para o herói.
5) Dimensione corretamente. Enviar uma imagem muito maior do que o necessário aumenta tempo de download e decodificação. Gere variantes e use srcset + sizes adequados.
<img src="/img/hero-640.avif" alt="Produto em destaque" width="1280" height="720" fetchpriority="high" srcset="/img/hero-640.avif 640w, /img/hero-960.avif 960w, /img/hero-1280.avif 1280w" sizes="(max-width: 768px) 100vw, 1200px" />6) Use formatos modernos e compressão eficiente. AVIF/WebP tendem a reduzir bytes. Mas valide custo de decodificação em dispositivos fracos: às vezes um JPEG bem comprimido pode ser competitivo dependendo do caso. O alvo é reduzir bytes sem aumentar demais o tempo de decode.
Checklist rápido para imagem LCP
- Está no HTML inicial?
- Não é lazy?
- Tem
fetchpriority="high"? - Tem dimensões definidas (width/height ou aspect-ratio)?
- Tem
srcset/sizescorretos? - Não depende de CSS para ser descoberta?
Estratégia 2: CSS crítico acima da dobra (sem bloquear o que não importa)
CSS é um dos maiores influenciadores do LCP porque o navegador geralmente espera CSS essencial para renderizar com layout e estilos finais. O objetivo é: entregar rapidamente o CSS necessário para o herói e adiar o resto.
Passo a passo prático: extrair e injetar CSS crítico
1) Identifique os estilos necessários para o herói: layout do header, grid do herói, tipografia básica, espaçamentos, cores, botões primários.
2) Injete CSS crítico inline no HTML inicial para evitar round-trip adicional.
<style>/* CSS crítico acima da dobra */ .hero{display:grid;grid-template-columns:1fr;gap:16px;padding:24px} .hero__title{font-size:40px;line-height:1.1;margin:0} .btn-primary{display:inline-block;padding:12px 16px;background:#111;color:#fff;border-radius:8px;text-decoration:none}</style>3) Carregue o CSS completo de forma não bloqueante (com fallback). Uma abordagem comum:
<link rel="preload" href="/assets/app.css" as="style" /><link rel="stylesheet" href="/assets/app.css" media="print" onload="this.media='all'" />4) Reduza o tamanho do CSS removendo estilos não usados e dividindo por rota (route-based splitting). Mesmo sem entrar em ferramentas específicas, a regra é: cada página deve carregar o mínimo de CSS necessário para o que aparece acima da dobra.
5) Evite dependências de CSS tardio para o herói. Se o herói depende de uma classe que só existe num bundle carregado depois, o navegador pode pintar algo incompleto e repintar depois, atrasando o LCP ou gerando instabilidade visual.
Armadilhas comuns com CSS e LCP
- Framework CSS gigante carregado em todas as páginas, mesmo quando o herói usa poucos componentes.
- @import em CSS, que pode criar cascata de downloads.
- Fontes declaradas em CSS sem estratégia de preload, atrasando texto grande.
Estratégia 3: Fontes e LCP de texto (headline como maior elemento)
Em muitas páginas, o maior elemento acima da dobra é texto (um H1 grande). Nesse caso, o LCP pode ser atrasado por carregamento de fontes web, especialmente se o navegador esperar a fonte para pintar ou se houver troca de fonte que altera métricas.
Práticas recomendadas para fontes com foco em LCP
- Preload da fonte principal usada no herói (apenas as necessárias). Evite preloads de muitas variações.
- Use
font-display: swapou estratégia equivalente para permitir pintura com fallback e troca posterior, reduzindo atraso de render. - Subconjuntos (subsetting): reduza o arquivo de fonte para conter apenas glifos necessários (por exemplo, Latin básico) quando aplicável.
- Evite múltiplas famílias/pesos acima da dobra. Um peso para título e um para texto já costuma ser suficiente.
Exemplo de preload de fonte (ajuste o tipo conforme o arquivo):
<link rel="preload" href="/fonts/Inter-roman.var.woff2" as="font" type="font/woff2" crossorigin />Exemplo de CSS com swap:
@font-face{font-family:'Inter';src:url('/fonts/Inter-roman.var.woff2') format('woff2');font-display:swap;}Se o LCP é texto, o objetivo é que o H1 seja pintado imediatamente com fallback aceitável e que a troca para a fonte final não cause mudanças grandes de layout. Para isso, além de swap, considere ajustar métricas (por exemplo, escolhendo uma fallback com métricas próximas) e manter line-height consistente.
Estratégia 4: Reduzir bloqueios de JavaScript antes do herói aparecer
Mesmo quando o recurso do herói está correto, o LCP pode atrasar porque o main thread está ocupado executando JavaScript, impedindo o navegador de concluir layout e paint. A regra prática: o que não é necessário para renderizar o conteúdo acima da dobra não deve rodar antes do LCP.
Passo a passo prático: adiar o que não é crítico
1) Marque scripts como defer quando possível, para não bloquear parsing do HTML.
<script src="/assets/app.js" defer></script>2) Evite inicializações pesadas no carregamento (carrosséis, animações complexas, bibliotecas de analytics, A/B testing, chat). Inicialize após o primeiro paint relevante ou após interação.
3) Divida o bundle: carregue apenas o JS necessário para o herói ser funcional. Se o herói é majoritariamente estático, talvez ele nem precise de JS para aparecer.
4) Hidratação seletiva/adiada (quando aplicável): componentes abaixo da dobra ou não essenciais podem ser hidratados depois. O importante para LCP é que o HTML/CSS do herói esteja pronto sem depender de JS.
5) Evite render condicional do herói via JS. Exemplo ruim: renderizar o herói apenas após buscar dados no client. Prefira render no servidor ou enviar dados essenciais no HTML inicial.
Estratégia 5: Servir HTML e recursos críticos com prioridade e cache adequados
Para conteúdo acima da dobra, latência e cache fazem diferença direta. O objetivo é reduzir o tempo até o navegador ter o que precisa para pintar o herói.
Práticas que impactam diretamente o LCP acima da dobra
- Cache eficiente para assets estáticos (CSS, JS, fontes, imagens do herói versionadas): permite que visitas repetidas tenham LCP muito menor.
- Evitar redirecionamentos antes da página final: cada redirect adiciona latência e atrasa descoberta do herói.
- Pré-conexão (preconnect) quando realmente necessário: se o herói depende de CDN de imagens ou fontes em outro domínio, preconnect pode reduzir handshake.
Exemplo de preconnect (use com parcimônia):
<link rel="preconnect" href="https://cdn.seudominio.com" crossorigin>Se a imagem do herói vem de um domínio externo, isso pode aumentar o tempo de conexão e atrasar o LCP. Quando possível, hospede o herói no mesmo domínio ou em um CDN bem próximo do usuário, com cache agressivo.
Estratégia 6: Evitar que o herói “espere” por dados
Acima da dobra, qualquer dependência de dados que só chegam depois pode atrasar o LCP, especialmente em SPAs ou páginas com renderização client-side. A ideia é: o herói deve ser renderizável com o mínimo de dependências.
Padrões para não atrasar o herói
- Renderize um herói estático com conteúdo padrão e refine depois (desde que não troque o elemento LCP para algo maior e tardio).
- Inclua dados essenciais no HTML inicial (por exemplo, título, preço, imagem principal) para evitar uma requisição extra antes do paint.
- Evite skeletons gigantes como LCP: se o skeleton é o maior elemento e depois é substituído, você pode “ganhar” um LCP rápido artificial, mas piorar a percepção. Prefira que o LCP seja o conteúdo real.
Um bom compromisso é usar placeholders pequenos (ou shimmer discreto) sem ocupar a maior área, enquanto o conteúdo real do herói já está disponível no HTML inicial.
Estratégia 7: Otimizações específicas para imagens acima da dobra (além do óbvio)
Decodificação e renderização
Mesmo após o download, imagens precisam ser decodificadas. Em dispositivos mais fracos, isso pode ser relevante. Boas práticas:
- Evite imagens com dimensões excessivas (pixels demais) para o tamanho exibido.
- Prefira imagens progressivas/otimizadas e valide custo de decode do formato escolhido.
- Use
decoding="async"para permitir que o navegador decodifique sem bloquear tanto o main thread (não é garantia, mas ajuda em alguns casos).
Evitar carrossel pesado no herói
Carrosséis acima da dobra frequentemente pioram LCP: múltiplas imagens competem por banda e JS de slider roda cedo. Se o design exigir carrossel:
- Carregue apenas o primeiro slide com prioridade alta.
- Adie os demais slides (lazy) e o JS do slider até depois do primeiro paint.
- Garanta que o primeiro slide tenha dimensões fixas e seja o candidato a LCP.
Estratégia 8: Layout previsível para o herói (sem reflow que atrasa paint)
Embora instabilidade visual seja mais associada a CLS, reflows e mudanças de layout também podem atrasar o momento em que o navegador considera o maior elemento “pronto” para pintar. Para o herói acima da dobra:
- Defina dimensões de imagens e containers (width/height, aspect-ratio).
- Evite inserir barras, banners e avisos acima do herói após o carregamento.
- Evite medir layout com JS no início (leituras de layout seguidas de escritas podem causar thrashing).
Exemplo com aspect-ratio para reservar espaço:
.hero__media{aspect-ratio:16/9;overflow:hidden;border-radius:16px} .hero__media img{width:100%;height:100%;object-fit:cover;display:block}Roteiro prático: otimização de LCP acima da dobra em 60–90 minutos
Este roteiro assume que você já sabe identificar o elemento LCP e medir; aqui o foco é executar mudanças típicas que movem o LCP quando o problema está no herói.
1) Confirme qual é o elemento LCP acima da dobra
- Se for imagem, siga o bloco de priorização de imagem.
- Se for texto, foque em CSS crítico e fontes.
- Se for um container (div grande), investigue: pode ser um wrapper que só fica “cheio” depois; tente tornar o conteúdo real o candidato.
2) Garanta descoberta imediata do herói
- Imagem no HTML inicial (evitar depender de JS).
- Evitar background-image para o herói (ou adicionar preload).
- Adicionar
fetchpriority="high"no<img>do herói.
3) Ajuste o carregamento de CSS para priorizar acima da dobra
- Inline do CSS crítico do herói.
- Carregamento não bloqueante do CSS completo.
- Remover dependências de CSS tardio para o herói.
4) Ajuste fontes se o LCP for texto
- Preload da fonte usada no H1 (uma ou poucas).
font-display: swap.- Reduzir pesos e variações acima da dobra.
5) Adie JS não essencial
- Adicionar
deferem scripts. - Postergar widgets e bibliotecas não críticas.
- Evitar que o herói dependa de hidratação para aparecer.
6) Verifique se o herói está com tamanho correto e sem desperdício
srcset/sizescorretos.- Formato e compressão adequados.
- Dimensões fixas para evitar reflow.
Exemplo integrado: herói otimizado para LCP
Abaixo um exemplo que combina várias estratégias: CSS crítico inline, preload de CSS e fonte, e imagem do herói com alta prioridade e responsividade.
<!-- no head --> <style> .hero{display:grid;gap:16px;padding:24px;max-width:1200px;margin:0 auto} .hero__title{font-family:Inter,system-ui,sans-serif;font-size:40px;line-height:1.1;margin:0} .hero__media{aspect-ratio:16/9;border-radius:16px;overflow:hidden} .hero__media img{width:100%;height:100%;object-fit:cover;display:block} </style> <link rel="preload" href="/assets/app.css" as="style"> <link rel="stylesheet" href="/assets/app.css" media="print" onload="this.media='all'"> <link rel="preload" href="/fonts/Inter-roman.var.woff2" as="font" type="font/woff2" crossorigin> <!-- no body --> <section class="hero"> <h1 class="hero__title">Entrega rápida com qualidade garantida</h1> <div class="hero__media"> <img src="/img/hero-640.avif" srcset="/img/hero-640.avif 640w, /img/hero-960.avif 960w, /img/hero-1280.avif 1280w" sizes="(max-width: 768px) 100vw, 1200px" width="1280" height="720" alt="Caixa de entrega em ambiente moderno" fetchpriority="high" decoding="async"> </div> <a class="btn-primary" href="/produtos">Ver produtos</a> </section>Esse padrão tende a melhorar LCP porque: o herói é renderizável imediatamente (CSS crítico inline), a imagem é descoberta cedo e priorizada (fetchpriority e presença no HTML), e fontes essenciais são antecipadas (preload), reduzindo o risco de o título atrasar a pintura.
Quando o LCP acima da dobra é um vídeo ou elemento “rico”
Se o herói é um vídeo, o LCP pode virar o poster (imagem) ou o próprio elemento dependendo do comportamento. Para não atrasar:
- Use poster otimizado e trate o poster como a imagem LCP (preload/fetchpriority).
- Não auto-carregue o vídeo pesado antes do LCP; carregue metadados primeiro e inicie download completo após interação ou após o primeiro paint.
- Evite bibliotecas de player pesadas no carregamento inicial; inicialize depois.
Exemplo com poster priorizado:
<link rel="preload" as="image" href="/img/hero-poster-1280.webp"> <video controls preload="metadata" poster="/img/hero-poster-1280.webp" width="1280" height="720"> <source src="/video/hero.mp4" type="video/mp4"> </video>Heurísticas rápidas para decidir o que priorizar
- Se o LCP é imagem: priorize descoberta + prioridade + bytes (srcset/formato) + evitar background-image.
- Se o LCP é texto: priorize CSS crítico + fontes (preload + swap) + evitar JS bloqueante.
- Se o LCP varia: estabilize o herói (evitar injeções tardias) e reserve espaço.
- Se o herói depende de dados: renderize com dados essenciais no HTML inicial ou forneça fallback que não substitua o maior elemento tardiamente.