Um guia explicativo sobre como detalhar a LCP e identificar áreas importantes para melhorar.
Publicado em 30 de abril de 2020
A maior exibição de conteúdo (LCP) é uma das três métricas do Core Web Vitals e representa a rapidez com que o conteúdo principal de uma página da Web é carregado. Especificamente, a LCP mede o tempo desde que o usuário começa a carregar a página até que a maior imagem ou bloco de texto seja renderizado na janela de visualização.
Para oferecer uma boa experiência ao usuário, os sites devem ter uma LCP de 2,5 segundos ou menos em pelo menos 75% das visitas à página.
Vários fatores podem afetar a rapidez com que o navegador carrega e renderiza uma página da Web, e atrasos em qualquer um deles podem ter um impacto significativo no LCP.
Geralmente, não há uma única solução Para melhorar a LCP, você precisa analisar todo o processo de carregamento e garantir que cada etapa esteja otimizada.
Como entender a métrica LCP
Antes de otimizar a LCP, os desenvolvedores precisam procurar entender se têm um problema de LCP e a extensão dele.
O LCP pode ser medido em várias ferramentas, e nem todas medem da mesma forma. Para entender a LCP de usuários reais, precisamos analisar a experiência deles, e não uma ferramenta baseada em laboratórios, como o Lighthouse, ou os testes locais. Essas ferramentas baseadas em laboratório podem fornecer muitas informações para explicar e ajudar você a melhorar a LCP, mas esteja ciente de que os testes de laboratório por si só podem não representar completamente a experiência dos seus usuários reais.
Os dados de LCP com base em usuários reais podem ser exibidos nas ferramentas de monitoramento de usuários reais (RUM, na sigla em inglês) instaladas em um site ou usando o Chrome User Experience Report (CrUX), que coleta dados anônimos de usuários reais do Chrome para milhões de sites.
Como usar os dados do LCP do CrUX no Chrome DevTools
O painel "Performance" do Chrome DevTools mostra a experiência de LCP local ao lado da LCP do CrUX da página ou da origem na visualização de métricas em tempo real.
Ao colocar dados de campo no painel "Desempenho", é possível avaliar se uma página tem problemas de LCP de usuários reais e adaptar as configurações do ambiente local para reproduzir e depurar melhor esses problemas.
Como usar os dados de LCP do CrUX no PageSpeed Insights
O PageSpeed Insights dá acesso aos dados do CrUX na parte de cima da seção Descubra o que seus usuários reais estão enfrentando. Dados mais detalhados com base em laboratório estão disponíveis na seção inferior Diagnosticar problemas de desempenho. Se os dados do CrUX estiverem disponíveis para seu site, sempre se concentre primeiro nos dados reais do usuário.
O PageSpeed Insights mostra até quatro dados diferentes do CrUX:
- Dados de dispositivos móveis para este URL
- Dados de computador para este URL
- Dados móveis para toda a origem
- Dados do computador para toda a Origem
Você pode ativar ou desativar esses controles na parte de cima e no canto superior direito desta seção. Se um URL não tiver dados suficientes para aparecer no nível do URL, mas tiver dados para a origem, o PageSpeed Insights sempre vai mostrar os dados da origem.
O LCP de toda a origem pode ser muito diferente do LCP de uma página individual, dependendo de como o LCP é carregado nessa página em comparação com outras páginas nessa origem. Isso também pode ser afetado pela forma como os visitantes navegam até essas páginas. As páginas iniciais costumam ser visitadas por novos usuários e, por isso, podem ser carregadas "a frio", sem conteúdo armazenado em cache e, portanto, são geralmente as páginas mais lentas de um site.
Analisar as quatro categorias diferentes de dados do CrUX pode ajudar a entender se um problema de LCP é específico para essa página ou mais geral em todo o site. Da mesma forma, ele pode mostrar quais tipos de dispositivos têm problemas de LCP.
Como usar as métricas complementares do PageSpeed Insights CrUX
Quem quer otimizar a LCP também precisa usar os tempos de First Contentful Paint (FCP) e Time to First Byte (TTFB), que são boas métricas de diagnóstico que podem fornecer insights valiosos sobre a LCP.
O TTFB é o tempo que o visitante leva para começar a navegar em uma página (por exemplo, clicando em um link) até que os primeiros bytes do documento HTML sejam recebidos. Um TTFB alto pode dificultar ou até impossibilitar a obtenção de um LCP de 2, 5 segundos.
Um TTFB alto pode ser causado por vários redirecionamentos do servidor, visitantes localizados longe do servidor do site mais próximo, visitantes em condições de rede ruins ou pela incapacidade de usar o conteúdo armazenado em cache devido a parâmetros de consulta.
Quando uma página começa a ser renderizada, pode haver uma pintura inicial (por exemplo, a cor de plano de fundo), seguida pelo aparecimento de algum conteúdo (por exemplo, o cabeçalho do site). A aparência do conteúdo inicial é medida pela FCP. O delta entre a FCP e outras métricas pode ser muito revelador.
Uma grande diferença entre o TTFB e a FCP pode indicar que o navegador precisa fazer o download de muitos recursos de bloqueio de renderização. Também pode ser um sinal de que é necessário fazer muito trabalho para renderizar qualquer conteúdo significativo, um sinal clássico de que um site depende muito da renderização do lado do cliente.
Uma grande diferença entre a FCP e a LCP indica que o recurso LCP não está imediatamente disponível para priorização pelo navegador (por exemplo, texto ou imagens gerenciadas por JavaScript em vez de disponíveis no HTML inicial) ou que o navegador está concluindo outro trabalho antes de exibir o conteúdo da LCP.
Como usar os dados do PageSpeed Insights Lighthouse
A seção Lighthouse do PageSpeed Insights oferece orientações para melhorar a LCP, mas primeiro é preciso verificar se a LCP fornecida está amplamente de acordo com os dados reais do usuário fornecidos pelo CrUX. Se o Lighthouse e o CrUX discordarem, o CrUX provavelmente vai fornecer uma imagem mais precisa da experiência do usuário. Verifique se os dados do CrUX são da sua página, e não da origem completa, antes de fazer alguma coisa.
Se o Lighthouse e o CrUX mostrarem valores de LCP que precisam de melhoria, a seção do Lighthouse vai fornecer orientações valiosas sobre como melhorar a LCP. Use o filtro LCP para mostrar apenas as auditorias relevantes para o LCP da seguinte maneira:
Além das oportunidades de melhoria, há informações de diagnóstico que podem ajudar a identificar o problema. O diagnóstico do elemento da maior exibição de conteúdo mostra um detalhamento útil dos vários tempos que compõem a LCP:
Vamos nos aprofundar nessas subpartes a seguir.
Detalhamento do LCP
A otimização para LCP pode ser uma tarefa mais complexa quando o PageSpeed Insights não oferece a resposta sobre como melhorar essa métrica. Com tarefas complexas, geralmente é melhor dividi-las em tarefas menores e mais gerenciáveis e abordar cada uma delas separadamente.
Esta seção apresenta uma metodologia para dividir o LCP nas subpartes mais importantes e, em seguida, apresenta recomendações específicas e práticas recomendadas para otimizar cada parte.
A maioria dos carregamentos de página normalmente inclui várias solicitações de rede, mas, para identificar oportunidades de melhorar a LCP, comece analisando apenas duas:
- O documento HTML inicial
- O recurso LCP (se aplicável)
Embora outras solicitações na página possam afetar a LCP, essas duas solicitações, especificamente os horários em que o recurso de LCP começa e termina, revelam se a página está ou não otimizada para a LCP.
Para identificar o recurso LCP, use ferramentas para desenvolvedores, como o PageSpeed Insights, o Chrome DevTools ou o WebPageTest, para determinar o elemento LCP. Em seguida, você pode corresponder o URL (novamente, se aplicável) carregado pelo elemento em uma cascata de rede de todos os recursos carregados pela página.
Por exemplo, a visualização a seguir mostra esses recursos destacados em um diagrama em cascata de rede de uma carga de página típica, em que o elemento LCP requer uma solicitação de imagem para renderização.
Para uma página bem otimizada, você quer que a solicitação de recurso da LCP comece a carregar o mais cedo possível e que o elemento da LCP seja renderizado o mais rápido possível após o carregamento do recurso. Para ajudar a visualizar se uma página específica está seguindo esse princípio, você pode dividir o tempo total de LCP nas seguintes subpartes:
- 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 (por exemplo, se o elemento for um nó de texto renderizado com uma fonte do sistema), esse tempo será 0.
- Duração do carregamento de recursos
- O tempo que leva para carregar o recurso de LCP. Se o elemento da LCP não exigir um carregamento de recurso para renderizar, 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.
O LCP de cada página consiste nessas quatro subcategorias. Não há lacuna ou sobreposição entre eles, e eles somam o tempo total de LCP.
Cada página pode ter o valor de LCP dividido em quatro partes. Não há sobreposição nem lacuna entre eles. Coletivamente, eles somam o tempo total de LCP.
Ao otimizar a LCP, é útil tentar otimizar essas partes individualmente. No entanto, também é importante lembrar que você precisa otimizar todos eles. Em alguns casos, uma otimização aplicada a uma parte não vai melhorar a LCP, apenas mudará o tempo economizado para outra parte.
Por exemplo, na hierarquia de rede anterior, se você reduzisse o tamanho do arquivo da imagem compactando-o mais ou mudando para um formato mais otimizado (como AVIF ou WebP), isso reduziria a duração de carregamento de recursos, mas não melhoraria o LCP, porque o tempo seria transferido para a subparte do atraso de renderização do elemento:
Isso acontece porque, nessa página, o elemento LCP fica oculto até que o código JavaScript termine de carregar. Depois, tudo é revelado de uma vez.
Esse exemplo ajuda a ilustrar o ponto de que você precisa otimizar todas essas subpartes para alcançar os melhores resultados de LCP.
Tempos ideais de subpartes
Para otimizar cada subparte da LCP, é importante entender qual é o detalhamento ideal dessas subpartes em uma página bem otimizada.
Das quatro subpartes, duas têm a palavra "delay" nos nomes. Isso é uma dica de que você quer que esses tempos fiquem o mais próximo possível de zero. As outras duas partes envolvem solicitações de rede que, por sua natureza, são demoradas.
Observe que esses detalhamentos de tempo são apenas diretrizes, não regras rígidas. Se os tempos da LCP nas suas páginas estiverem consistentemente dentro de 2,5 segundos, não importa quais sejam as proporções relativas. No entanto, se você estiver gastando muito tempo desnecessário em qualquer uma das partes de "atraso", será muito difícil atingir constantemente a meta de 2,5 segundos.
Uma boa maneira de pensar sobre o detalhamento do tempo de LCP é:
- A maior parte do tempo de LCP deve ser gasto carregando o documento HTML e a origem do LCP.
- Qualquer momento antes do LCP em que um desses dois recursos não está sendo carregado é uma oportunidade de melhoria.
Como otimizar cada parte
Agora que você entende como cada subparte da LCP precisa ser dividida em uma página bem otimizada, comece a otimizar suas próprias páginas.
As próximas quatro seções vão apresentar recomendações e práticas recomendadas para otimizar cada parte. Elas são apresentadas em ordem, começando pelas otimizações que provavelmente terão o maior impacto.
1. Elimine o atraso no carregamento de recursos
O objetivo desta etapa é garantir que o recurso da LCP comece a carregar o mais cedo possível. Embora, em teoria, o recurso possa começar a ser carregado imediatamente após o TTFB, na prática, sempre há algum atraso antes que os navegadores comecem a carregar os recursos.
Uma boa regra geral é que o recurso de LCP comece a carregar ao mesmo tempo que o primeiro recurso carregado por essa página. Ou, em outras palavras, se o recurso de LCP começar a carregar depois do primeiro recurso, há uma oportunidade de melhoria.
De modo geral, dois fatores afetam a rapidez do carregamento de um recurso de LCP:
- Quando o recurso é descoberto.
- Qual é a prioridade do recurso.
Otimizar quando o recurso for descoberto
Para garantir que o recurso de LCP comece a ser carregado o mais cedo possível, é fundamental que ele seja detectável na resposta inicial do documento HTML pelo scanner de pré-carregamento do navegador. Por exemplo, nos casos a seguir, o navegador pode descobrir o recurso de LCP ao verificar a resposta do documento HTML:
- O elemento LCP é um elemento
<img>, e os atributossrcousrcsetdele estão presentes na marcação HTML inicial. - O elemento LCP exige uma imagem de plano de fundo CSS, mas essa imagem é pré-carregada usando
<link rel="preload">na marcação HTML (ou usando um cabeçalhoLink). - O elemento LCP é um nó de texto que requer uma fonte da Web para renderização. A fonte é carregada usando
<link rel="preload">na marcação HTML ou um cabeçalhoLink.
Confira alguns exemplos em que o recurso LCP não pode ser descoberto ao verificar a resposta do documento HTML:
- O elemento LCP é um
<img>que é adicionado dinamicamente à página usando JavaScript. - O elemento LCP é carregado de forma lenta com uma biblioteca JavaScript que oculta os atributos
srcousrcset(geralmente comodata-srcoudata-srcset). - O elemento LCP requer uma imagem de plano de fundo CSS.
Em cada um desses casos, o navegador precisa executar o script ou aplicar a folha de estilo, o que normalmente envolve aguardar a conclusão das solicitações de rede, antes de descobrir o recurso da LCP e começar a carregá-lo. Isso nunca é o ideal.
Para eliminar atraso desnecessário no carregamento de recursos, o recurso LCP precisa ser detectável na fonte HTML. Nos casos em que o recurso só é referenciado somente a partir de um arquivo CSS ou JavaScript externo, o recurso de LCP precisa ser pré-carregado com uma alta prioridade de busca, por exemplo:
<!-- Load the stylesheet that will reference the LCP image. -->
<link rel="stylesheet" href="/path/to/styles.css">
<!-- Preload the LCP image with a high fetchpriority so it starts loading with the stylesheet. -->
<link rel="preload" fetchpriority="high" as="image" href="/path/to/hero-image.webp" type="image/webp">
Otimize a prioridade do recurso
Mesmo que o recurso LCP seja detectável na marcação HTML, ele ainda pode não começar a carregar tão cedo quanto o primeiro recurso. Isso pode acontecer se as heurísticas de prioridade do scanner de pré-carregamento do navegador não reconhecerem que o recurso é importante ou se ele determinar que outros recursos são mais importantes.
Por exemplo, é possível atrasar a imagem de LCP usando HTML se você definir loading="lazy" no elemento <img>. O uso do carregamento lento significa que o recurso não será carregado até que o layout confirme que a imagem está na janela de visualização. Portanto, o carregamento pode começar mais tarde do que o normal.
Mesmo sem o carregamento lento, as imagens não são carregadas inicialmente com a maior prioridade pelos navegadores, porque não são recursos que bloqueiam a renderização. É possível indicar ao navegador quais recursos são mais importantes usando o atributo fetchpriority para recursos que podem se beneficiar de uma prioridade maior:
<img fetchpriority="high" src="/path/to/hero-image.webp">
Recomendamos definir fetchpriority="high" em um elemento <img> se você achar que ele pode ser o elemento da LCP da sua página. No entanto, definir uma prioridade alta para mais de uma ou duas imagens não ajuda a reduzir o LCP.
Também é possível diminuir a prioridade de imagens que podem estar no início da resposta do documento, mas não estão visíveis devido ao estilo, como imagens em slides de carrossel que não estão visíveis na inicialização:
<img fetchpriority="low" src="/path/to/carousel-slide-3.webp">
A despriorização de determinados recursos pode permitir mais largura de banda para recursos que precisam mais dela, mas tenha cuidado. Sempre verifique a prioridade do recurso no DevTools e teste as alterações com ferramentas de laboratório e campo.
Depois de otimizar a prioridade e o tempo de descoberta do recurso de LCP, a hierarquia de rede vai ficar assim (com o recurso de LCP começando ao mesmo tempo que o primeiro recurso):
2. Elimine o atraso de renderização do elemento.
O objetivo dessa etapa é garantir que o elemento da LCP seja renderizado imediatamente após o carregamento do recurso, independentemente de quando isso acontecer.
O principal motivo para o elemento da LCP não conseguir renderizar imediatamente após o carregamento do recurso é se a renderização estiver bloqueada por algum outro motivo:
- A renderização de toda a página está bloqueada devido a folhas de estilo ou scripts síncronos na
<head>que ainda estão sendo carregados. - O recurso de LCP terminou de carregar, mas o elemento da LCP ainda não foi adicionado ao DOM (está aguardando o carregamento de um código JavaScript).
- O elemento está sendo ocultado por algum outro código, como uma biblioteca de testes A/B que ainda está determinando em qual experimento o usuário deve estar.
- A linha de execução principal é bloqueada devido a tarefas longas, e o trabalho de renderização precisa aguardar até que essas tarefas longas sejam concluídas.
As seções a seguir explicam como lidar com as causas mais comuns de atrasos de renderização de elementos desnecessários.
Reduza ou in-line as folhas de estilo que bloqueiam a renderização
As folhas de estilos carregadas da marcação HTML bloqueiam a renderização de todo o conteúdo que as segue, o que é bom, já que geralmente não é necessário renderizar HTML sem estilo. No entanto, se a folha de estilo for tão grande que demore muito mais para carregar que o recurso da LCP, isso impedirá a renderização do elemento da LCP, mesmo após a conclusão do carregamento do recurso, como mostrado neste exemplo:
Para corrigir isso, você pode:
- inline da folha de estilo no HTML para evitar a solicitação de rede adicional; ou
- reduz o tamanho da folha de estilo.
Em geral, a incorporação da folha de estilo só é recomendada se ela for pequena, já que o conteúdo incorporado no HTML não pode se beneficiar do armazenamento em cache em carregamentos de página subsequentes. Se uma folha de estilo for tão grande que demore mais para carregar do que o recurso LCP, é improvável que ela seja um bom candidato para inline.
Na maioria dos casos, a melhor maneira de garantir que a folha de estilo não bloqueie a renderização do elemento LCP é reduzir o tamanho dela para que seja menor que o recurso LCP. Isso garante que ele não seja um gargalo para a maioria das visitas.
Algumas recomendações para reduzir o tamanho da folha de estilo são:
- Remover CSS não utilizado: use o Chrome DevTools para encontrar regras CSS que não estão sendo usadas e podem ser removidas (ou adiadas).
- Adie o carregamento de páginas não essenciais: divida sua folha de estilos em estilos necessários para o carregamento inicial da página e depois aqueles que podem ser carregados lentamente.
- Minificar e compactar o CSS: para estilos críticos, reduza o tamanho da transferência o máximo possível.
JavaScript que bloqueia a renderização em linha ou adiado
Quase nunca é necessário adicionar scripts síncronos (scripts sem os atributos async ou defer) ao <head> das suas páginas, e fazer isso quase sempre tem um impacto negativo na performance.
Nos casos em que o código JavaScript precisa ser executado o mais cedo possível no carregamento da página, é melhor inline para que a renderização não seja atrasada aguardando outra solicitação de rede. No entanto, assim como nas folhas de estilo, você só deve inserir scripts inline se eles forem muito pequenos.
<head> <script src="/path/to/main.js"></script> </head>
<head>
<script>
// Inline script contents directly in the HTML.
// IMPORTANT: only do this for very small scripts.
</script>
</head>Usar renderização do lado do servidor
A renderização do lado do servidor (SSR) é o processo de executar a lógica do aplicativo do lado do cliente no servidor e responder às solicitações de documentos HTML com a marcação completa de HTML.
Do ponto de vista da otimização da LCP, a SSR tem duas vantagens principais:
- Seus recursos de imagem vão ser descobertos na origem HTML (conforme discutido na etapa 1 anterior).
- O conteúdo da página não vai precisar de outras solicitações de JavaScript para renderização.
A principal desvantagem do SSR é que ele requer mais tempo de processamento do servidor, o que pode diminuir o TTFB. Essa troca geralmente vale a pena porque os tempos de processamento do servidor estão sob seu controle, enquanto os recursos de rede e dispositivo dos usuários não estão.
Uma opção semelhante à SSR é chamada de geração de sites estáticos (SSG, na sigla em inglês) ou pré-renderização. Esse é o processo de geração de páginas HTML em uma etapa de build, em vez de sob demanda. Se a pré-renderização for possível com sua arquitetura, ela geralmente será a melhor escolha para performance.
Dividir tarefas longas
Mesmo que você tenha seguido as dicas anteriores e seu código JavaScript não bloqueie a renderização nem seja responsável por renderizar os elementos, ele ainda pode atrasar o LCP.
O motivo mais comum para isso acontecer é quando as páginas carregam arquivos JavaScript grandes, que precisam ser analisados e executados na linha de execução principal do navegador. Isso significa que, mesmo que o recurso de imagem seja totalmente transferido, ele ainda pode precisar esperar até que um script não relacionado termine de ser executado antes de ser renderizado.
Todos os navegadores renderizam imagens na linha de execução principal, o que significa que qualquer coisa que bloqueie a linha de execução principal também pode levar a um atraso desnecessário na renderização de elementos.
3. Reduzir a duração do carregamento de recursos
O objetivo desta etapa é reduzir o tempo gasto na transferência de bytes do recurso pela rede para o dispositivo do usuário. Em geral, há quatro maneiras de fazer isso:
- Reduza o tamanho do recurso.
- Reduza a distância que o recurso precisa percorrer.
- Reduza a contenção de largura de banda da rede.
- Elimine completamente o tempo de rede.
Reduzir o tamanho do recurso
O recurso LCP de uma página (se houver um) será uma imagem ou uma fonte da Web. Os guias a seguir detalham como reduzir o tamanho de ambos:
- Exibir o tamanho de imagem ideal
- Usar formatos de imagem modernos
- Compactar imagens
- Reduzir o tamanho da fonte da Web
Reduzir a distância que o recurso precisa percorrer
Além de reduzir o tamanho de um recurso, você também pode reduzir os tempos de carregamento, deixando os servidores o mais próximo possível dos usuários. A melhor maneira de fazer isso é usar uma rede de fornecimento de conteúdo (CDN).
As CDNs de imagens são especialmente úteis porque não apenas reduzem a distância que o recurso precisa percorrer, mas também o tamanho dele, implementando automaticamente todas as recomendações de redução de tamanho anteriores.
Reduzir a contenção de largura de banda da rede
Mesmo que você tenha reduzido o tamanho do recurso e a distância que ele precisa percorrer, um recurso ainda pode levar muito tempo para carregar se você estiver carregando muitos outros recursos ao mesmo tempo. Esse problema é conhecido como contenção de rede.
Se você deu ao recurso de LCP um fetchpriority alto e começou a carregá-lo o mais rápido possível, o navegador vai fazer o possível para evitar que os recursos de menor prioridade concorram com ele. No entanto, se você estiver carregando muitos recursos com fetchpriority alto ou se estiver carregando muitos recursos em geral, isso poderá afetar a rapidez com que o recurso LCP é carregado.
Elimine completamente o tempo de rede
A melhor maneira de reduzir a duração da carga de recursos é eliminar a rede do processo. Se você oferecer seus recursos com uma política eficiente de controle de cache, os visitantes que solicitarem esses recursos pela segunda vez vão receber o conteúdo do cache, o que praticamente elimina a duração do carregamento de recursos.
Se o recurso de LCP for uma fonte da Web, além de reduzir o tamanho da fonte da Web, você também precisará considerar se precisa bloquear a renderização no carregamento do recurso de fonte da Web. Se você definir um valor de font-display diferente de auto ou block, o texto sempre ficará visível durante o carregamento e a LCP não será bloqueada em uma solicitação de rede adicional.
Por fim, se o recurso de LCP for pequeno, pode ser interessante inlinear os recursos como um URL de dados, o que também eliminará a solicitação de rede extra. No entanto, o uso de URLs de dados vem com ressalvas, porque os recursos não podem ser armazenados em cache e, em alguns casos, podem levar a atrasos de renderização mais longos devido ao custo de decodificação adicional.
4. Reduzir o tempo para o primeiro byte
O objetivo desta etapa é entregar o HTML inicial o mais rápido possível. Essa etapa é listada por último porque é a que os desenvolvedores têm menos controle. No entanto, ela também é uma das etapas mais importantes, porque afeta diretamente todas as etapas seguintes. Nada pode acontecer no front-end até que o back-end entregue o primeiro byte de conteúdo. Portanto, tudo o que você puder fazer para acelerar o TTFB também vai melhorar todas as outras métricas de carregamento.
Uma causa comum de um TTFB lento para um site rápido é a chegada de visitantes por vários redirecionamentos, como de anúncios ou links encurtados. Sempre minimize o número de redirecionamentos que um visitante precisa aguardar.
Outra causa comum é quando o conteúdo em cache não pode ser usado de um servidor de borda da CDN e todas as solicitações precisam ser direcionadas de volta para o servidor de origem. Isso poderá acontecer se parâmetros de URL exclusivos forem usados pelos visitantes para análise, mesmo que eles não resultem em páginas diferentes.
Para orientações específicas sobre como otimizar o TTFB, consulte o guia de otimização do TTFB.
Monitorar o detalhamento de LCP em JavaScript
As informações de tempo de todas as subpartes do LCP discutidas anteriormente estão disponíveis em JavaScript usando uma combinação das seguintes APIs de performance:
O benefício de calcular esses valores de tempo no JavaScript é que você pode enviá-los a um provedor de análise ou fazer o registro deles nas ferramentas para desenvolvedores para ajudar na depuração e otimização.
Por exemplo, a captura de tela a seguir usa o método performance.measure() da API User Timing para adicionar barras à faixa "Timings" no painel Performance do Chrome DevTools.
As visualizações na faixa Tempos são particularmente úteis quando observadas junto com os acompanhamentos Rede e Linha de execução principal, porque você pode ver rapidamente o que mais está acontecendo na página durante esses períodos.
Além de visualizar as subpartes do LCP na faixa de tempo, você também pode usar o JavaScript para calcular a porcentagem de cada subparte do tempo total do LCP. Com essas informações, você pode determinar se as páginas estão atendendo aos detalhes de porcentagem recomendados descritos anteriormente.
Esta captura de tela mostra um exemplo que registra o tempo total de cada subparte da LCP, bem como a porcentagem do tempo total da LCP no console.
Ambas as visualizações foram criadas com o seguinte código:
const LCP_SUB_PARTS = [
'Time to first byte',
'Resource load delay',
'Resource load duration',
'Element render delay',
];
new PerformanceObserver((list) => {
const lcpEntry = list.getEntries().at(-1);
const navEntry = performance.getEntriesByType('navigation')[0];
const lcpResEntry = performance
.getEntriesByType('resource')
.filter((e) => e.name === lcpEntry.url)[0];
// Ignore LCP entries that aren't images to reduce DevTools noise.
// Comment this line out if you want to include text entries.
if (!lcpEntry.url) return;
// Compute the start and end times of each LCP sub-part.
// WARNING! If your LCP resource is loaded cross-origin, make sure to add
// the `Timing-Allow-Origin` (TAO) header to get the most accurate results.
const ttfb = navEntry.responseStart;
const lcpRequestStart = Math.max(
ttfb,
// Prefer `requestStart` (if TOA is set), otherwise use `startTime`.
lcpResEntry ? lcpResEntry.requestStart || lcpResEntry.startTime : 0
);
const lcpResponseEnd = Math.max(
lcpRequestStart,
lcpResEntry ? lcpResEntry.responseEnd : 0
);
const lcpRenderTime = Math.max(
lcpResponseEnd,
// Use LCP startTime (the final LCP time) because there are sometimes
// slight differences between loadTime/renderTime and startTime
// due to rounding precision.
lcpEntry ? lcpEntry.startTime : 0
);
// Clear previous measures before making new ones.
// Note: due to a bug, this doesn't work in Chrome DevTools.
LCP_SUB_PARTS.forEach((part) => performance.clearMeasures(part));
// Create measures for each LCP sub-part for easier
// visualization in the Chrome DevTools Performance panel.
const lcpSubPartMeasures = [
performance.measure(LCP_SUB_PARTS[0], {
start: 0,
end: ttfb,
}),
performance.measure(LCP_SUB_PARTS[1], {
start: ttfb,
end: lcpRequestStart,
}),
performance.measure(LCP_SUB_PARTS[2], {
start: lcpRequestStart,
end: lcpResponseEnd,
}),
performance.measure(LCP_SUB_PARTS[3], {
start: lcpResponseEnd,
end: lcpRenderTime,
}),
];
// Log helpful debug information to the console.
console.log('LCP value: ', lcpRenderTime);
console.log('LCP element: ', lcpEntry.element, lcpEntry.url);
console.table(
lcpSubPartMeasures.map((measure) => ({
'LCP sub-part': measure.name,
'Time (ms)': measure.duration,
'% of LCP': `${
Math.round((1000 * measure.duration) / lcpRenderTime) / 10
}%`,
}))
);
}).observe({type: 'largest-contentful-paint', buffered: true});
É possível usar esse código no estado em que se encontra para depuração local ou modificá-lo para enviar esses dados a um provedor de análise. Assim, você pode entender melhor qual é o detalhamento de LCP nas suas páginas para usuários reais.
Resumo
O LCP é complexo, e o tempo dele pode ser afetado por vários fatores. Mas se você considerar que a otimização da LCP é principalmente sobre otimizar a carga do recurso da LCP, isso pode simplificar significativamente as coisas.
Em um nível alto, a otimização do LCP pode ser resumida em quatro etapas:
- Verifique se o recurso de LCP começa a carregar o mais cedo possível.
- Garanta que o elemento LCP possa ser renderizado assim que o recurso terminar de carregar.
- Reduzir o tempo de carregamento do recurso de LCP o máximo possível sem sacrificar a qualidade.
- Envie o documento HTML inicial o mais rápido possível.
Se você conseguir seguir essas etapas nas suas páginas, terá certeza de que está oferecendo uma experiência de carregamento ideal para os usuários e verá isso refletido nas pontuações reais da LCP.