A maior exibição de conteúdo (LCP) de uma página pode ser complicada de melhorar, muitas vezes envolvendo várias partes móveis e compensações. Esta postagem analisa dados de campo de carregamentos de página reais na Web para determinar onde os desenvolvedores devem concentrar os esforços de otimização.
Conselho clássico de LCP: reduza o tamanho das suas imagens.
Na maioria das páginas da Web, o elemento LCP é uma imagem. É natural supor que a melhor maneira de melhorar a LCP é otimizar a imagem dela.
Nos cinco anos desde a introdução da LCP, esse é o conselho principal. Verifique se as imagens têm o tamanho e a compactação adequados e use um formato de imagem do século 21. O Lighthouse tem até três diferentes auditorias para fazer essas sugestões.
Uma das razões para esse conselho ser tão comum é que bytes em excesso são fáceis de medir e ferramentas de compactação de imagens são fáceis de sugerir. Dependendo dos seus pipelines de build e implantação, a implementação também pode ser fácil.
Se sim, faça isso. Enviar menos bytes para os usuários quase sempre é uma vitória. Há muitos sites na Web que ainda veiculam imagens grandes desnecessariamente, que até mesmo uma compactação básica corrigiria.
No entanto, quando começamos a analisar os dados de desempenho de campo dos usuários no Chrome para saber onde o tempo para LCP geralmente é gasto, descobrimos que o tempo de download de imagens quase nunca é o gargalo.
Em vez disso, outras partes da LCP são um problema muito maior.
Detalhamento da subparte do LCP
Para entender quais eram as maiores oportunidades de melhorar a LCP, analisamos os dados das subpartes da LCP, conforme descrito em Otimizar a LCP.
Embora cada página e framework possa ter uma abordagem diferente para carregar e exibir o que se torna o elemento LCP da página, cada um pode ser dividido em estas partes:
- Tempo até o primeiro byte (TTFB)
- O tempo desde o início do carregamento da página pelo usuário até que o navegador receba o primeiro byte da resposta do documento HTML.
- Atraso no carregamento de recursos
- O tempo entre o TTFB e o momento em que o navegador começa a carregar o recurso LCP. Se
o elemento LCP não exigir um carregamento de recursos para renderização, esse tempo será
0. - Duração do carregamento de recursos
- O tempo que leva para carregar o recurso de LCP. Se o elemento LCP
não exigir um carregamento de recursos para renderização, esse tempo será
0. - Atraso na renderização do elemento
- O tempo entre o término do carregamento do recurso LCP e a renderização completa do elemento LCP.
Dados de performance de navegação real
| Classificação do LCP | TTFB (ms) | Atraso no carregamento de imagens (ms) | Duração do carregamento da imagem (ms) | Atraso de renderização (ms) |
|---|---|---|---|---|
| Boa | 600 | 350 | 160 | 230 |
| Precisa melhorar | 1.360 | 720 | 270 | 310 |
| Ruim | 2.270 | 1.290 | 350 | 360 |
Para este post, usamos dados de navegações de página com um LCP de imagem de subrecurso no Chrome para analisar as subpartes do LCP. Já analisamos esse tipo de dados antes, mas nunca com dados de campo para saber onde os usuários reais passam o tempo enquanto aguardam o LCP de uma página.
Assim como nas Core Web Vitals, usamos o percentil 75 (p75) de cada subparte da LCP para cada origem no conjunto de dados do CrUX, resultando em quatro distribuições de valores de p75 (uma para cada subparte). Para resumir essas distribuições, calculamos a mediana desses valores em todas as origens para cada uma das quatro subpartes do LCP.
Por fim, dividimos as origens em grupos com base no LCP"bom", "melhorias necessárias" ou "ruim" no 75º percentil. Isso ajuda a mostrar o que diferencia uma origem com um bom LCP de uma origem com um LCP ruim.
Reduzir o tamanho da imagem do LCP? Desta vez com dados
A duração do carregamento é a medida do tempo que leva para buscar o recurso LCP, neste caso, uma imagem. Esse tempo geralmente é proporcional ao número de bytes na imagem. Por isso, todos os conselhos de performance visam reduzir esse número.
Ao analisar o tempo gasto nos gráficos anteriores, uma coisa que se destaca é que não há muito tempo gasto na duração do carregamento de imagens. Na verdade, é a menor subparte do LCP em todos os buckets. A duração do carregamento é maior para origens com LCP ruim em comparação com as de LCP boa, mas ainda não é onde o tempo é gasto em grande parte.
A maioria das origens com LCP ruim gasta menos de 10% do tempo de LCP p75 para fazer o download da imagem da LCP.
Sim, você precisa garantir que suas imagens estejam otimizadas, mas isso é apenas uma parte da melhoria da LCP. E fica claro com esses dados que, para a origem típica na Web, os ganhos potenciais de milissegundos para o LCP em geral são pequenos, não importa o quão sofisticado seja o esquema de compactação.
Uma última surpresa: as durações de carregamento lentas costumavam ser atribuídas a dispositivos móveis e à qualidade das redes móveis. Talvez você já tenha esperado que um smartphone comum levasse muito mais tempo para fazer o download da mesma imagem que uma máquina desktop em uma conexão com fio. Os dados sugerem que isso não é mais o caso. Para origens com LCP ruim, a duração média de carregamento de imagem p75 é apenas 20% mais lenta em dispositivos móveis do que em computadores.
Tempo até o primeiro byte (TTFB)
Para navegações que fazem uma solicitação de rede, o TTFB sempre leva algum tempo. Fazer uma pesquisa DNS e iniciar uma conexão leva tempo. E não é possível vencer a física: uma solicitação precisa viajar pelo mundo real por fios e cabos ópticos para chegar a um servidor, e a resposta precisa fazer a viagem de volta. Mesmo a origem mediana com um bom LCP gasta mais de meio segundo no TTFB no percentil 75.
No entanto, a disparidade de TTFB entre as origens de LCP boas e ruins mostra a oportunidade de melhoria. Para pelo menos metade das origens com LCP ruim, o TTFB p75 de 2.270 milissegundos sozinho quase garante que o LCP p75 não pode ser mais rápido do que o limite "bom" de 2,5 segundos. Mesmo uma redução percentual moderada desse tempo significaria uma melhoria significativa na LCP.
Talvez você não consiga vencer a física, mas há coisas que podem ser feitas. Por exemplo, se os usuários estiverem em um local muito diferente dos servidores, um CDN pode aproximar o conteúdo deles.
Para mais informações, consulte o Guia de otimização do TTFB.
Atraso no carregamento de recursos, o culpado pela LCP lenta que ninguém percebe
Se o TTFB puder ser melhorado, mas as melhorias forem limitadas pela física, o atraso de carregamento de recursos poderá ser eliminado, na prática, apenas limitado pela sua arquitetura de veiculação.
Essa subparte mede o tempo entre a chegada do primeiro byte da resposta HTML (TTFB) e o momento em que o navegador inicia uma solicitação para a imagem do LCP. Há anos, nos concentramos no tempo necessário para fazer o download de imagens de LCP, mas muitas vezes ignoramos o tempo desperdiçado antes mesmo de o navegador receber a instrução de iniciar o download.
O site mediano com LCP ruim leva quase quatro vezes mais tempo para começar a fazer o download da imagem do que para fazer o download dela, esperando 1,3 segundo entre o TTFB e a solicitação de imagem. Isso significa que mais da metade do orçamento de LCP de 2,5 segundos foi usado em uma única subparte.
As cadeias de dependência são um motivo comum para atrasos longos de carregamento. No extremo mais simples, há uma página que carrega uma folha de estilo que, depois que o navegador faz o layout, define uma imagem de plano de fundo que acaba se tornando a LCP. Todas essas etapas precisam acontecer antes mesmo que o navegador saiba que precisa começar a fazer o download da imagem do LCP.
Usando os dados de rastreamento público do HTTP Archive, que registra a cadeia de solicitações de rede "iniciador" do documento HTML para uma imagem de LCP, é possível observar a correlação clara do comprimento da cadeia de solicitações com um LCP mais lento.
O mais importante é informar ao navegador o mais rápido possível qual será a LCP para que ele possa começar a carregá-la, mesmo antes de haver um lugar para ela no layout da página. Há algumas ferramentas disponíveis para fazer isso, como uma tag <img> clássica no HTML para que o verificador de pré-carregamento possa encontrá-la rapidamente e começar a fazer o download ou uma tag <link rel="preload"> (ou cabeçalho HTTP) para imagens que não serão <img>s.
Também é importante ajudar o navegador a determinar quais recursos priorizar. Isso é especialmente verdadeiro se a página estiver fazendo muitas solicitações durante o carregamento, já que o navegador geralmente não sabe qual será o elemento do LCP até que muitos desses recursos sejam carregados e o layout ocorra. A inclusão de anotações no elemento LCP provável com um atributo fetchpriority="high" (e evitando loading="lazy") deixa claro para o navegador que ele precisa começar a carregar o recurso imediatamente.
Leia mais dicas sobre como otimizar o atraso de carregamento.
Atraso na renderização
O atraso de renderização mede o tempo entre o momento em que o navegador tem a imagem da LCP carregada e pronta e o momento em que ela é mostrada na tela. Às vezes, essa é uma tarefa demorada que bloqueia a linha de execução principal quando a imagem está pronta. Em outros casos, pode ser uma escolha de interface para revelar um elemento oculto.
Para a origem típica na Web, não parece haver uma grande oportunidade de atraso de renderização, mas, durante a otimização, às vezes é possível criar atraso de renderização com o tempo gasto anteriormente em outras subpartes. Por exemplo, se uma página começar a pré-carregar a imagem do LCP para que ela fique disponível rapidamente, não haverá mais um longo atraso de carregamento. No entanto, se a página não estiver pronta para mostrar a imagem, como uma folha de estilo de bloqueio de renderização grande ou um app de renderização do lado do cliente que precisa terminar de carregar todo o JavaScript antes que algo seja exibido, o LCP ainda será mais lento do que deveria, e o tempo gasto na espera vai aparecer como atraso de renderização. É por isso que a renderização do servidor ou o HTML estático geralmente tem uma vantagem em relação ao LCP.
Se o seu conteúdo for afetado, leia mais dicas sobre como otimizar o atraso de renderização.
Verifique todas essas subpartes
É claro que, para otimizar o LCP de maneira eficaz, os desenvolvedores precisam analisar o carregamento da página de forma holística, e não apenas se concentrar na otimização de imagens. Verifique cada parte do tempo para a LCP, porque provavelmente há oportunidades muito maiores de melhoria.
Para coletar esses dados no campo, o build de atribuição da biblioteca de web vitals inclui tempos para as subpartes do LCP. O Chrome User Experience Report (CrUX) ainda não inclui todos esses dados, mas tem entradas para TTFB e LCP, então é um começo. Esperamos incluir os dados usados para esta postagem no CrUX no futuro. Fique de olho para mais novidades.
Para testar as subpartes do LCP localmente, use a extensão das Core Web Vitals ou o snippet de JavaScript neste artigo. O Lighthouse também inclui a decomposição na auditoria "Elemento de maior exibição de conteúdo". Procure mais conselhos sobre subpartes de LCP no painel de desempenho das DevTools, em breve.