15 de Abril de 2025
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
Founder & Engineer
4 min Intermediario Sistemas
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:
- resposta inicial
- descoberta do recurso
- download do recurso principal
- CSS e renderização necessárias
- 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
- LCP melhora quando você encurta o caminho até o conteúdo principal, não quando otimiza qualquer recurso por reflexo.
- Imagem hero pesada é causa comum, mas não é a única nem sempre a principal.
- Prioridade de recurso, bloqueio de render e JavaScript no caminho crítico costumam pesar tanto quanto o tamanho do arquivo.
- Em entrevista, explicar a cadeia de dependências do LCP mostra mais maturidade do que listar dicas genéricas.
Checklist de pratica
Use isto ao responder
- Consigo apontar qual elemento está sendo medido como LCP?
- Sei decompor rede, HTML, CSS, imagem e CPU no caminho até esse elemento aparecer?
- Consigo diferenciar gargalo de prioridade errada versus gargalo de peso real do recurso?
- Sei sugerir melhorias em ordem, da mais provável para a mais invasiva?
Você concluiu este artigo
Parte da trilha: Trilha para entrevistas de senior frontend (12/15)
Próximo passo
Como Pensar Segurança em SPA, SSR e APIs Próximo passo →Compartilhar esta página
Copie o link manualmente no campo abaixo.