Pular para o conteudo principal

Como Otimizar LCP sem Adivinhar o que é Lento

Um jeito mais sério de melhorar Largest Contentful Paint sem sair comprimindo arquivo aleatório.

Andrews Ribeiro

Andrews Ribeiro

Founder & Engineer

Trilha

Trilha para entrevistas de senior frontend

Etapa 12 / 15

O problema

LCP ruim costuma produzir conselho ruim.

A página parece lenta e logo aparece a sequência clássica:

  • comprime a imagem
  • divide mais o bundle
  • troca framework
  • liga CDN

Alguma dessas coisas pode ajudar.

Mas fazer tudo sem entender o caminho até o conteúdo principal aparecer é só uma forma cara de adivinhação.

Modelo mental

LCP não mede “quanto pesa sua página”.

Ele mede quanto tempo levou até o principal conteúdo visível aparecer.

Então a pergunta certa é:

O que precisa acontecer para esse elemento existir na tela?

Essa cadeia normalmente envolve:

  1. resposta inicial
  2. descoberta do recurso
  3. download do recurso principal
  4. CSS e renderização necessárias
  5. CPU livre para pintar

Se uma dessas etapas está atrasada, o LCP sofre.

Quebrando o problema

Primeiro descubra qual elemento é o LCP

Sem isso, o resto vira chute.

Pode ser:

  • a imagem hero
  • um bloco grande de texto
  • banner principal

Se você está otimizando um recurso que nem participa do LCP, está gastando energia no lugar errado.

Depois mapeie o caminho até ele aparecer

Pergunte:

  • esse elemento já está no HTML inicial ou depende de JS?
  • o recurso foi descoberto cedo?
  • ele foi baixado com prioridade correta?
  • CSS bloqueou a renderização?
  • o main thread estava ocupado demais para pintar?

Essa decomposição costuma separar muito rápido o que é rede, o que é render e o que é CPU.

Causas comuns de LCP ruim

Recurso principal descoberto tarde

O navegador nem começa a baixar cedo o que importa.

Isso acontece quando:

  • a imagem aparece só depois de JS montar a árvore
  • o HTML atrasa a descoberta
  • a prioridade do recurso está ruim

Recurso pesado demais

Esse é o caso mais óbvio.

Imagem grande, formato ruim, dimensão acima do necessário.

Mas mesmo aqui vale cuidado.

Às vezes o problema não é só o peso bruto.

É baixar tarde um arquivo que poderia ter sido priorizado cedo.

CSS ou fonte bloqueando visualização

O recurso principal chegou, mas o navegador ainda não consegue exibir corretamente.

Aí entram:

  • CSS crítico atrasado
  • fonte alterando layout
  • dependência de estilo que empurra a pintura

Main thread ocupada

Esse é o caso menos intuitivo para muita gente.

O recurso está pronto, mas o navegador está processando JavaScript demais, hidratando interface ou fazendo trabalho caro antes de pintar.

Exemplo simples

Imagine uma página de marketing com:

  • imagem hero em alta resolução
  • carrossel montado por JS
  • CSS grande carregado cedo
  • scripts de tracking entrando antes do principal

O time diz:

“O problema é a imagem.”

Talvez seja.

Mas a leitura melhor é:

  • a hero só aparece depois do JS montar o componente?
  • o navegador descobre essa imagem cedo?
  • a prioridade desse download está certa?
  • o CSS necessário chega antes?
  • o main thread está preso em script de terceiros?

Perceba como a pergunta muda.

Você sai de “qual arquivo comprimir?” para “qual etapa está atrasando o elemento principal?”.

Erros comuns

  • Assumir que LCP ruim sempre é culpa da imagem.
  • Não identificar qual elemento está sendo medido.
  • Otimizar bundle sem saber se o bottleneck está em rede ou renderização.
  • Carregar recurso crítico tarde por causa da forma como o componente é montado.
  • Tentar consertar LCP com conselho genérico de checklist.

Como um senior pensa

Quem pensa melhor sobre esse problema costuma seguir o caminho crítico com calma.

Algo como:

  • qual é o elemento de LCP?
  • quando ele é descoberto?
  • o recurso vem cedo ou tarde?
  • o navegador consegue pintar assim que ele chega?
  • há CPU sobrando para isso?

Essa ordem importa porque evita trocar uma explicação conveniente por uma explicação correta.

Senioridade aqui é isolar o gargalo dominante em vez de espalhar otimizações cosméticas por todo o app.

O que o entrevistador quer ver

Ele quer ver se você:

  • entende que LCP é sobre o principal conteúdo visível
  • sabe decompor o caminho crítico desse conteúdo
  • consegue propor investigação antes de propor remédio
  • diferencia atraso de descoberta, atraso de rede e atraso de render/CPU

Se sua resposta soar como “primeiro eu identificaria o elemento de LCP e quebraria o caminho até ele aparecer”, você já saiu na frente de muita resposta decorada.

LCP melhora quando o conteúdo principal chega mais cedo e consegue aparecer mais cedo.

O trabalho maduro não é listar dicas. É descobrir qual etapa está segurando a tela.

Resumo rápido

O que vale manter na cabeça

Checklist de pratica

Use isto ao responder

Você concluiu este artigo

Parte da trilha: Trilha para entrevistas de senior frontend (12/15)

Próximo artigo Renderização, rede e CPU Artigo anterior Onde está o gargalo

Continue explorando

Artigos relacionados