O relatório móvel do PageSpeed pode mostrar o Largest Contentful Paint em amarelo ou vermelho mesmo quando o computador parece rápido. Isso acontece porque a simulação móvel considera uma combinação mais exigente de rede, processamento e tamanho da tela. A correção começa pela identificação do elemento medido, não por uma lista aleatória de otimizações.
O LCP representa o momento em que o maior bloco de texto, imagem ou vídeo visível na área inicial termina de aparecer. Para uma boa experiência, a referência recomendada é até 2,5 segundos no percentil 75 das visitas. Entre 2,5 e 4 segundos há espaço para melhoria; acima disso o resultado é considerado ruim.
Primeiro: descubra qual é o elemento LCP
Abra o PageSpeed Insights ou o Lighthouse e procure a seção de diagnóstico do LCP. Em muitas páginas, o elemento será a imagem principal da matéria. Em outras, poderá ser o título, um banner ou um bloco de destaque. Saber isso evita otimizar recursos que não participam do caminho crítico.
Também compare os dados de laboratório com os dados de campo. O laboratório reproduz uma visita controlada e ajuda na depuração. Os dados de campo mostram o que usuários reais experimentaram ao longo do tempo. Um teste isolado pode variar; a tendência é mais importante.
As quatro partes do tempo do LCP
O tempo total pode ser dividido em quatro partes:
- Tempo até o primeiro byte: quanto o servidor demora para começar a entregar o HTML.
- Atraso até o recurso começar a carregar: tempo perdido antes de o navegador descobrir e solicitar a imagem ou outro recurso do LCP.
- Duração do carregamento: tempo gasto transferindo o recurso.
- Atraso de renderização: intervalo entre o fim do download e a exibição na tela.
Os dois atrasos deveriam ficar próximos de zero. Quando a imagem principal só é descoberta depois de um CSS, JavaScript ou atributo de carregamento tardio, o navegador fica esperando sem necessidade.
Quando a imagem é o problema
- Converta a capa para WebP ou AVIF com qualidade visual adequada.
- Entregue dimensões próximas ao tamanho realmente exibido.
- Informe width e height para reservar espaço e evitar mudanças de layout.
- Não aplique lazy loading à imagem que aparece imediatamente na primeira tela.
- Considere preload somente quando o recurso for realmente crítico e não puder ser descoberto cedo pelo HTML.
Preload não reduz o peso da imagem. Ele apenas muda a prioridade e o momento da solicitação. Usá-lo em muitos arquivos pode disputar banda com recursos mais importantes.
Quando texto, CSS ou fontes atrasam o LCP
Se o maior elemento for um título, o navegador pode estar esperando CSS ou fonte. Mantenha o CSS crítico pequeno, hospede fontes localmente quando fizer sentido, utilize font-display e carregue apenas pesos realmente usados. Uma folha de estilo de poucos quilobytes ainda bloqueia a renderização, mas o custo pode ser aceitável quando a conexão e o cache funcionam bem.
Quando o servidor domina o resultado
Se o TTFB ocupa grande parte do LCP, comprimir imagens não resolverá tudo. Verifique cache de página, consultas ao banco de dados, tempo de aplicação, redirecionamentos e distância até o servidor. O HTML precisa começar a chegar cedo para que o navegador descubra os demais recursos.
Uma ordem prática de correção
- Identifique o elemento e repita o teste para confirmar.
- Verifique se o recurso começa a ser solicitado cedo.
- Reduza o peso e ajuste as dimensões da imagem.
- Elimine bloqueios desnecessários de CSS, fontes e scripts.
- Investigue o servidor se o primeiro byte continuar lento.
- Valide novamente em celular e acompanhe os dados de campo.
Nosso guia de Core Web Vitals explica como o LCP se relaciona com INP e CLS. A otimização mais eficiente é aquela guiada pelo componente que realmente consome o tempo, não pela cor isolada de uma auditoria.
Fonte: web.dev
