Porque é que o Seu LCP Está Lento
O LCP é uma corrida entre o navegador a pedir a sua página e esse elemento maior a terminar a sua renderização. Quase todo o LCP lento remonta a uma de quatro coisas que atrapalham essa corrida:
- Time to First Byte lento. Se o servidor demora 2 segundos apenas a responder, o LCP não pode começar a contar mais cedo do que isso - tudo o que vem a seguir herda o atraso.
- Uma imagem hero não otimizada. Um PNG de 4MB servido no tamanho de exibição em vez de um formato comprimido e devidamente dimensionado é a causa individual mais comum que observamos.
- CSS ou JS bloqueadores de renderização no
<head>. O navegador não consegue pintar nada, incluindo o elemento LCP, até terminar de descarregar e processar os recursos bloqueadores de renderização. - Descoberta tardia de recursos. Se a imagem LCP só é referenciada no interior de um
background-imageCSS ou carregada por JavaScript após a hidratação, o navegador nem sequer sabe que deve começar a obtê-la até muito mais tarde do que poderia.
Como Identificar o Seu Elemento LCP
Adivinhar qual elemento é o seu LCP não é fiável - muda com o tamanho do viewport e o conteúdo. O Website Audit do Scanverra executa uma passagem real do Lighthouse tanto num perfil desktop como num viewport mobile de 375px e reporta o valor e o tempo de LCP diretamente dessa execução, não uma estimativa, pelo que está a olhar para a mesma métrica que os dados de campo do Google acabarão por refletir, não um proxy para ela.
No Chrome DevTools também pode abrir o painel Performance, gravar o carregamento de uma página e procurar o marcador "LCP" na faixa de tempos - realça o elemento exato na página renderizada quando passa o rato sobre ele.
Como Corrigir
1. Pré-carregue o recurso LCP real
Se o navegador só consegue descobrir a sua imagem hero depois de processar CSS ou executar JS, informe-o sobre a imagem antecipadamente:
1export default function RootLayout() {
2 return (
3 <html lang="en">
4 <head>
5 <link
6 rel="preload"
7 as="image"
8 href="/hero.webp"
9 fetchPriority="high"
10 />
11 </head>
12 <body>{/* ... */}</body>
13 </html>
14 );
15}2. Marque a imagem LCP como prioritária
Se está a renderizar a imagem hero através de uma tag de imagem ao nível de componente, marque-a como recurso prioritário para que não seja carregada de forma preguiçosa e compita primeiro pela largura de banda:
1<img
2 src="/hero.webp"
3 alt="Product dashboard overview"
4 width={1200}
5 height={630}
6 fetchPriority="high"
7 loading="eager"
8/>3. Comprima e dimensione corretamente a própria imagem
Sirva AVIF ou WebP em vez de PNG/JPEG onde o navegador o suportar, e nunca envie uma imagem maior do que o maior tamanho em que será realmente exibida - uma imagem de origem com 3000px de largura reduzida com CSS continua a custar o download completo.
4. Resolva primeiro o TTFB
Pré-carregar uma imagem de carregamento lento não corrige um servidor lento. Se o TTFB representa uma parte significativa do seu orçamento de LCP, corrija isso primeiro - veja o guia de TTFB abaixo - já que todas as outras otimizações de LCP estão limitadas por quão tarde o navegador consegue sequer começar.
5. Remova recursos bloqueadores de renderização do caminho crítico
Adie ou torne assíncrono o JavaScript não crítico, coloque em linha a pequena quantidade de CSS necessária para o conteúdo acima da dobra, e carregue o resto da sua folha de estilos sem bloquear a primeira renderização.
Como o Scanverra Deteta Problemas de LCP
As verificações de desempenho do Scanverra executam uma auditoria genuína do Lighthouse contra o seu URL em produção, tanto em desktop como num viewport mobile de 375px, e reportam o tempo real de LCP dessa execução juntamente com os outros Core Web Vitals - isto não é uma estimativa sintética nem um número de terceiros em cache.