Entender como seu site carrega é crucial para manter os visitantes engajados e satisfeitos. O Largest Contentful Paint (LCP) é uma métrica vital que mede a velocidade com que o conteúdo principal de uma página se torna visível. Se o seu site está lento, isso pode prejudicar a experiência do usuário e afetar negativamente o ranqueamento no Google. Recentemente, o Google introduziu as LCP subparts, que ajudam a identificar as causas dos atrasos no carregamento.
O Que São LCP Subparts?
As LCP subparts dividem a métrica Largest Contentful Paint em quatro componentes principais, permitindo que você entenda melhor onde estão os gargalos no carregamento da sua página. Essa análise detalhada facilita a otimização e melhora a performance do seu site.
- Time to First Byte (TTFB): Mede a rapidez com que o servidor responde à solicitação do documento.
- Resource Load Delay: Tempo gasto antes que a imagem LCP comece a ser baixada.
- Resource Load Time: Tempo necessário para baixar a imagem LCP.
- Element Render Delay: Tempo que leva para o elemento LCP ser exibido.
É importante notar que os tempos de carregamento de recursos se aplicam principalmente se o elemento principal da página for uma imagem. Para elementos de texto, os componentes de Load Delay e Load Time são geralmente zero.
Como Medir as LCP subparts
Uma forma eficaz de medir a contribuição de cada componente para a pontuação LCP do seu site é usar ferramentas de teste de velocidade de sites. Ao analisar os dados fornecidos, você pode identificar quais áreas precisam de mais atenção e otimização.
Por exemplo, se o TTFB e a duração do carregamento da imagem juntos representam uma grande parte da pontuação LCP, esses são os pontos de partida mais impactantes para otimizar. Para entender melhor o que acontece em cada etapa, um waterfall de requisição de rede pode ser muito útil.
A visualização de descoberta de imagem LCP filtra o waterfall para mostrar apenas os recursos relevantes para exibir a imagem Largest Contentful Paint. Cada um dos três primeiros estágios contém uma requisição, e o estágio final termina rapidamente, sem novos recursos carregados.
Detalhes de Cada Componente da LCP
Vamos explorar cada um dos quatro componentes das LCP subparts para entender melhor como otimizar cada um deles e melhorar o desempenho geral do seu site.
Time To First Byte (TTFB)
O primeiro passo para exibir o elemento principal da página é obter o HTML do documento. O TTFB mede a rapidez com que o servidor responde a essa solicitação. Se o TTFB for alto, pode indicar que o servidor está lento para gerar o HTML da página.
Para melhorar o TTFB, você pode acelerar o processo de geração de HTML ou usar cache para evitar a geração repetida do HTML. No exemplo analisado, a maior parte do tempo é gasto esperando o servidor gerar o HTML, então otimizar esse processo é crucial.
Resource Load Delay
O “recurso” que queremos carregar é a imagem LCP. Idealmente, você deve ter uma tag <img> perto do topo do HTML para que o navegador encontre e comece a carregar a imagem imediatamente. No entanto, às vezes, ocorre um Load Delay.
Em vez de carregar a imagem diretamente, a página usa lazysize.js, uma biblioteca de lazy loading de imagens que só carrega a imagem LCP quando detecta que ela aparecerá na área de visualização. Parte do Load Delay é causado pelo tempo necessário para baixar essa biblioteca JavaScript.
O navegador também precisa completar o layout da página e começar a renderizar o conteúdo antes que a biblioteca saiba que a imagem está na área de visualização. Após completar a requisição, há uma tarefa da CPU que leva ao First Contentful Paint, quando a página começa a renderizar. Só então a biblioteca dispara a requisição da imagem LCP.
Para otimizar, você pode usar o atributo nativo loading="lazy" na tag <img>, eliminando a dependência do JavaScript. Além disso, a imagem LCP não deve ser carregada com lazy loading, permitindo que o navegador comece a carregá-la assim que o HTML estiver pronto. Segundo o Google, o objetivo é eliminar completamente o resource load delay.
Resources Load Duration
O componente Load Duration é bastante direto: você precisa baixar a imagem LCP antes de exibi-la. Se a imagem demorar muito para carregar, isso afetará negativamente a pontuação LCP.
No exemplo, a imagem é carregada do mesmo domínio do HTML, o que é positivo porque o navegador não precisa se conectar a um novo servidor. Outras técnicas para reduzir o load delay incluem:
- Usar um formato de imagem moderno que ofereça melhor compressão.
- Carregar imagens em um tamanho que corresponda ao tamanho em que são exibidas.
- Despriorizar outros recursos que possam competir com a imagem LCP.
Element Render Delay
O quarto e último componente, Render Delay, pode ser o mais confuso. O recurso já foi carregado, mas por alguma razão o navegador ainda não está pronto para mostrá-lo ao usuário.
Felizmente, no exemplo que estamos analisando, a imagem LCP aparece rapidamente após ser carregada. Uma causa comum para o render delay é quando o elemento LCP não é uma imagem. Nesse caso, o atraso é causado por scripts e folhas de estilo que bloqueiam a renderização.
O texto só pode aparecer após esses recursos serem carregados e o navegador completar o processo de renderização. Outra razão para o render delay é quando o site pré-carrega a imagem LCP. Pré-carregar é uma boa prática, pois praticamente elimina qualquer load delay e garante que a imagem seja carregada cedo.
No entanto, se a imagem terminar de baixar antes que a página esteja pronta para renderizar, você verá um aumento no render delay. Isso não é necessariamente ruim, pois você melhorou a velocidade geral do seu site e apenas revelou um novo gargalo para focar.
LCP subparts em Dados Reais do CrUX
Analisar as LCP subparts em testes de laboratório pode fornecer insights valiosos sobre onde otimizar. No entanto, muitas vezes o LCP no laboratório não corresponde ao que acontece com usuários reais. É por isso que, em fevereiro de 2025, o Google começou a incluir dados de LCP subparts no relatório de dados do CrUX.
Esses dados ainda não estão incluídos no PageSpeed Insights, mas podem ser visualizados na aba “Web Vitals”. Uma informação muito útil é o tipo de recurso LCP: ele indica quantos visitantes viram o elemento LCP como texto ou imagem.
Mesmo para a mesma página, diferentes visitantes verão conteúdos ligeiramente diferentes, dependendo do tamanho do dispositivo ou se visualizam um banner de cookies. Para facilitar a interpretação dos dados, o Google só reporta dados de LCP subparts para imagens.
Se o elemento LCP for geralmente texto na página, as informações das LCP subparts não serão muito úteis, pois não se aplicarão à maioria dos seus visitantes. No entanto, quebrar o LCP de texto é relativamente fácil: tudo o que não faz parte da pontuação TTFB é atraso na renderização.
Monitore as LCP subparts no Seu Site com Real User Monitoring
Os dados de laboratório nem sempre correspondem à experiência dos usuários reais. Os dados do CrUX são superficiais, reportados apenas para páginas de alto tráfego e levam pelo menos 4 semanas para atualizar após uma mudança.
É por isso que uma ferramenta de real-user monitoring é útil ao corrigir suas pontuações LCP. Você pode rastrear pontuações em todas as páginas do seu site ao longo do tempo e obter dashboards dedicados para cada LCP subparts.
Você também pode revisar experiências de visitantes específicos, ver qual era a imagem LCP para eles, inspecionar um waterfall de requisição e verificar os tempos das LCP subparts.
Primeira: Este conteúdo foi auxiliado por Inteligência Artificiado, mas escrito e revisado por um humano.
Segunda: Via Smashing Magazine