Um guia explicativo sobre como analisar a LCP e identificar as principais áreas de melhoria.
A Maior exibição de conteúdo (LCP) é uma das três métricas Core Web Vitals e representa a velocidade de carregamento do conteúdo principal de uma página da Web. Especificamente, a LCP mede o tempo decorrido entre o início do carregamento da página e a renderização da maior imagem ou bloco de texto na janela de visualização.
Para oferecer uma boa experiência do usuário, os sites precisam 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 o atraso em qualquer um deles pode ter um impacto significativo na LCP.
É raro que uma correção rápida em uma única parte de uma página resulte em uma melhoria significativa para a LCP. Para melhorar a LCP, você precisa analisar todo o processo de carregamento e garantir que todas as etapas estejam otimizadas.
Noções básicas sobre a métrica de LCP
Antes de otimizar a LCP, os desenvolvedores precisam tentar entender se têm um problema de LCP e a extensão do problema.
A LCP pode ser medida em várias ferramentas, mas nem todas medem a LCP da mesma forma. Para entender a LCP dos usuários reais, devemos analisar a experiência deles, em vez do que uma ferramenta baseada em laboratório como o Lighthouse ou de testes locais mostra. Essas ferramentas baseadas em laboratório podem fornecer muitas informações para explicar e ajudar a melhorar a LCP, mas saiba que os testes de laboratório por si só podem não representar completamente a experiência dos usuários.
Os dados de LCP baseados em usuários reais podem ser gerados por ferramentas de monitoramento de usuários reais (RUM, na sigla em inglês) instaladas em um site ou pelo Chrome User Experience Report (CrUX, na sigla em inglês), que coleta dados anônimos de usuários reais do Chrome para milhões de sites.
Usar dados da LCP do CrUX do PageSpeed Insights
O PageSpeed Insights fornece acesso aos dados do CrUX na seção superior chamada Descubra a experiência dos seus usuários reais. Dados mais detalhados baseados em laboratório estão disponíveis na seção inferior chamada Diagnosticar problemas de desempenho. Se os dados do CrUX estiverem disponíveis para seu site, sempre concentre-se primeiro nos dados reais dos usuários.
O PageSpeed Insights mostra até quatro dados do CrUX diferentes:
- Dados móveis para Este URL
- Dados de computador para This URL
- Dados de dispositivos móveis para toda a Origin
- Dados de computador para toda a Origin
Você pode alternar entre eles usando os controles no canto superior direito desta seção. Se um URL não tiver dados suficientes para exibição no nível do URL, mas tiver dados para a origem, o PageSpeed Insights sempre mostrará esses dados.
A LCP de toda a origem pode ser muito diferente da LCP de uma página individual, dependendo de como a LCP é carregada em uma página em comparação com outras páginas na mesma origem. Ela também pode ser afetada pela forma como os visitantes navegam para essas páginas. As páginas iniciais tendem a ser acessadas por novos usuários e, com frequência, podem ser carregadas "frias", sem nenhum conteúdo em cache. Portanto, são frequentemente as páginas mais lentas de um site.
Analisar as quatro categorias diferentes de dados do CrUX pode ajudar você a entender se um problema de LCP é específico da página ou um problema mais geral em todo o site. Da mesma forma, ele pode mostrar quais tipos de dispositivos têm problemas de LCP.
Uso das métricas complementares do CrUX do PageSpeed Insights
Aqueles que querem otimizar a LCP também precisam usar os tempos de Primeira exibição de conteúdo (FCP) e Tempo até o primeiro byte (TTFB, na sigla em inglês), que são boas métricas de diagnóstico que podem fornecer insights valiosos sobre a LCP.
TTFB é o tempo em que o visitante começa a navegar para uma página (por exemplo, clicando em um link) até que os primeiros bytes do documento HTML sejam recebidos. Um TTFB alto pode tornar difícil ou até impossível atingir uma LCP de 2, 5 segundos.
Um TTFB alto pode ocorrer devido a vários redirecionamentos de servidor, visitantes localizados longe do servidor do site mais próximo, visitantes em condições de rede ruins ou a incapacidade de usar conteúdo em cache devido a parâmetros de consulta.
Quando uma página inicia a renderização, pode haver uma pintura inicial (por exemplo, a cor do plano de fundo) seguida da exibição 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.
Um grande delta entre o TTFB e o FCP pode indicar que o navegador precisa fazer o download de muitos recursos de bloqueio de renderização. Isso também pode ser um sinal de que precisa concluir muito trabalho para renderizar qualquer conteúdo significativo, um sinal clássico de um site que depende muito da renderização do lado do cliente.
Um delta grande entre a FCP e a LCP indica que o recurso da LCP não está imediatamente disponível para ser priorizado pelo navegador (por exemplo, texto ou imagens gerenciados por JavaScript em vez de estarem disponíveis no HTML inicial) ou que o navegador está concluindo outro trabalho antes de exibir o conteúdo da LCP.
Usar os dados do PageSpeed Insights Lighthouse
A seção do Lighthouse no PageSpeed Insights oferece orientações para melhorar a LCP, mas primeiro verifique se a LCP fornecida está amplamente de acordo com os dados de usuários reais fornecidos pelo CrUX. Se o Lighthouse e o CrUX discordarem, é provável que o CrUX ofereça uma imagem mais precisa da experiência do usuário. Verifique se os dados CrUX são para sua página, não para a origem completa, antes de agir.
Se o Lighthouse e o CrUX mostrarem valores de LCP que precisam de melhorias, a seção do Lighthouse poderá fornecer orientações valiosas sobre como aprimorar a LCP. Use o filtro de LCP para mostrar apenas auditorias relevantes para LCP da seguinte maneira:
Além das oportunidades de melhoria, há informações de diagnóstico que podem ajudar a diagnosticar o problema. O diagnóstico de Maior elemento da exibição de conteúdo mostra um detalhamento dos vários tempos que compõe a LCP:
Vamos nos aprofundar nessas subpartes a seguir.
Detalhamento de LCP
A otimização para LCP pode ser uma tarefa mais complexa quando o PageSpeed Insights não fornece 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 separadamente.
Esta seção apresenta uma metodologia para dividir a LCP nas subpartes mais importantes e, em seguida, apresenta recomendações específicas e práticas recomendadas para otimizar cada parte.
Geralmente, a maioria dos carregamentos de página 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 de 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 da LCP começa e termina) revelam se a página está ou não otimizada para LCP.
Para identificar o recurso da LCP, é possível usar ferramentas para desenvolvedores (como o PageSpeed Insights discutidos acima, o Chrome DevTools ou o WebPageTest) para determinar o elemento da LCP. A partir daí, é possível fazer a correspondência do URL (novamente, se aplicável) carregado pelo elemento em uma hierarquia de rede de todos os recursos carregados pela página.
Por exemplo, a visualização a seguir mostra esses recursos destacados em um diagrama de cascata de rede a partir de um carregamento de página típico, em que o elemento da LCP exige uma solicitação de imagem para ser renderizado.
Para uma página bem otimizada, é recomendável que a solicitação de recurso de LCP comece a ser carregada o mais cedo possível e que o elemento da LCP seja renderizado o mais rápido possível depois que o recurso da LCP terminar de carregar. Para ajudar a visualizar se uma página específica segue esse princípio, divida o tempo total de LCP nas seguintes subpartes:
- Tempo para primeiro byte (TTFB)
- O tempo entre o momento em que o usuário inicia o carregamento da página e o momento em que o navegador recebe o primeiro byte da resposta do documento HTML.
- Atraso no carregamento de recursos
- O tempo entre o TTFB e quando o navegador começa a carregar o recurso da LCP. Se o elemento da LCP não exigir um carregamento de recurso para renderizar (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 necessário para carregar o próprio recurso da 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 fim do carregamento do recurso da LCP e a renderização completa do elemento da LCP.
A LCP de cada página é composta por quatro subcategorias. Não há lacunas ou sobreposições entre eles, e eles são somados ao tempo total da LCP.
Cada página pode ter o valor de LCP dividido nessas quatro subpartes. Não há sobreposição ou lacuna entre eles. Ao todo, elas somam todo o tempo de LCP.
Ao otimizar a LCP, vale a pena otimizar essas subpartes individualmente. Mas também é importante ter em mente que você precisa otimizar todos eles. Em alguns casos, uma otimização aplicada a uma parte não melhora a LCP, ela apenas muda o tempo economizado para outra parte.
Por exemplo, na hierarquia de rede anterior, se você reduzisse o tamanho do arquivo da nossa imagem compactando-o ou mudando para um formato mais adequado (como AVIF ou WebP), isso reduziria a duração do carregamento do recurso, mas não melhoraria a LCP porque o tempo apenas mudaria para a subparte Atraso na renderização do elemento:
Isso acontece porque, nessa página, o elemento da LCP fica oculto até que o código JavaScript termine de carregar, e tudo é revelado de uma vez.
Este exemplo ajuda a ilustrar que você precisa otimizar todas essas subpartes para alcançar os melhores resultados de LCP.
Horários de subparte ideais
Para otimizar cada subparte da LCP, é importante entender qual é a divisão ideal dessas subpartes em uma página bem otimizada.
Das quatro subpartes, duas têm a palavra "atraso" no nome. Isso é uma pista de que você deve obter esses tempos o mais próximo possível de zero. As outras duas partes envolvem solicitações de rede, que, pela própria natureza, levam tempo.
Esses detalhamentos de tempo são diretrizes, não regras rígidas. Se os tempos de LCP aparecem consistentemente em 2,5 segundos nas suas páginas, não importa quais são as proporções relativas. No entanto, se você passar muito tempo desnecessário em qualquer uma das partes do "atraso", será muito difícil atingir constantemente a meta de 2,5 segundos.
Uma boa maneira de pensar no detalhamento do tempo de LCP é:
- A grande maioria do tempo da LCP deve ser gasta carregando o documento HTML e a origem da LCP.
- Qualquer momento antes da LCP em que um desses dois recursos não esteja carregando é uma oportunidade de melhorar.
Como otimizar cada parte
Agora que você entende como cada subparte da LCP deve ser detalhada em uma página bem otimizada, comece a otimizar suas próprias páginas.
As próximas quatro seções apresentam recomendações e práticas recomendadas sobre como otimizar cada parte. Elas são apresentadas em ordem, começando com as otimizações que provavelmente terão o maior impacto.
1. Elimine o atraso de carregamento de recursos.
O objetivo nesta etapa é garantir que o recurso da LCP comece a ser carregado o mais rápido possível. Embora, em teoria, o primeiro recurso poderia começar a ser carregado é imediatamente após o TTFB, na prática, sempre há um atraso até que os navegadores comecem a carregar os recursos.
Uma boa regra prática é que o recurso de LCP deve começar a ser carregado ao mesmo tempo que o primeiro recurso carregado por essa página. Em outras palavras, se o recurso da LCP começar a ser carregado depois do primeiro recurso, você poderá melhorar.
De modo geral, há dois fatores que afetam a rapidez com que um recurso de LCP pode ser carregado:
- Quando o recurso é descoberto.
- 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 verificador de pré-carregamento do navegador. Por exemplo, nos seguintes casos, o navegador pode descobrir o recurso LCP verificando a resposta do documento HTML:
- O elemento da 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 um cabeçalhoLink). - O elemento LCP é um nó de texto que requer uma fonte da Web para renderizar, e a fonte é carregada usando
<link rel="preload">na marcação HTML (ou usando um cabeçalhoLink).
Veja alguns exemplos em que o recurso de LCP não pode ser descoberto pela verificação da resposta do documento HTML:
- O elemento da LCP é um
<img>que é adicionado dinamicamente à página usando JavaScript. - O elemento da LCP é carregado lentamente 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 um atraso desnecessário no carregamento de recursos, o recurso de LCP precisa ser detectável pelo código-fonte HTML. Nos casos em que o recurso é referenciado apenas de um arquivo CSS ou JavaScript externo, o recurso LCP deve 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">
Otimizar a prioridade que o recurso recebe
Mesmo que o recurso de LCP seja detectável na marcação HTML, é possível que ele ainda não comece a ser carregado logo que o primeiro recurso. Isso poderá acontecer se a heurística de prioridade do verificador de pré-carregamento do navegador não reconhecer que o recurso é importante ou se determinar que outros recursos são mais importantes.
Por exemplo, é possível atrasar a imagem LCP usando HTML se você definir loading="lazy" no seu 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, ele pode começar a carregar depois do que seria.
Mesmo sem o carregamento lento, as imagens não são carregadas inicialmente com a prioridade mais alta pelos navegadores, já que não são recursos que bloqueiam a renderização. Você pode indicar ao navegador quais recursos são mais importantes usando o atributo fetchpriority para recursos que podem se beneficiar de uma prioridade mais alta:
<img fetchpriority="high" src="/path/to/hero-image.webp">
É recomendável definir fetchpriority="high" em um elemento <img> se você achar que ele provavelmente é o elemento da LCP da sua página. No entanto, definir uma prioridade alta em mais de uma ou duas imagens faz com que isso não ajude na redução da LCP.
Também é possível diminuir a prioridade de imagens que podem estar no início da resposta do documento, mas que não são visíveis devido ao estilo, como imagens em slides de carrossel que não são visíveis na inicialização:
<img fetchpriority="low" src="/path/to/carousel-slide-3.webp">
Diminuir a prioridade de determinados recursos pode resultar em mais largura de banda para aqueles que precisam mais, mas tenha cuidado. Sempre verifique a prioridade de recursos no DevTools e teste as alterações com ferramentas de laboratório e de campo.
Depois de otimizar a prioridade de recursos da LCP e o tempo de descoberta, a hierarquia de rede ficará assim (com o recurso da LCP começando ao mesmo tempo que o primeiro):
2. Elimine o atraso de renderização do elemento.
O objetivo desta etapa é garantir que o elemento da LCP possa ser renderizado imediatamente após o carregamento do recurso, independentemente de quando isso acontecer.
O principal motivo pelo qual o elemento da LCP não poderia ser renderizado imediatamente após o fim do 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 no
<head>que ainda estão sendo carregados. - O recurso da LCP foi carregado, mas o elemento da LCP ainda não foi adicionado ao DOM (ele está aguardando o carregamento de algum código JavaScript).
- O elemento está sendo ocultado por outro código, como uma biblioteca de testes A/B que ainda está determinando em qual experimento o usuário deve participar.
- A linha de execução principal é bloqueada devido a tarefas longas, e o trabalho de renderização precisa esperar até que essas tarefas longas sejam concluídas.
As seções a seguir explicam como abordar as causas mais comuns de atraso desnecessário na renderização de elementos.
Reduzir ou inline folhas de estilo de bloqueio de renderização
As folhas de estilo carregadas a partir da marcação HTML bloquearão a renderização de todo o conteúdo que as segue, o que é bom, pois você geralmente não quer renderizar HTML sem estilo. No entanto, se a folha de estilo for tão grande que leva muito mais tempo para carregar do que o recurso de LCP, ela vai impedir a renderização do elemento da LCP, mesmo após o carregamento do recurso, como mostrado neste exemplo:
Para corrigir isso, você tem as seguintes opções:
- inserir a folha de estilo no HTML para evitar solicitações de rede adicionais; ou
- reduzir o tamanho da folha de estilo.
Em geral, a inserção in-line da folha de estilo só é recomendada se ela for pequena, já que o conteúdo in-line no HTML não pode se beneficiar do armazenamento em cache nos carregamentos de página subsequentes. Se uma folha de estilo for tão grande que demora mais para carregar do que o recurso de LCP, é pouco provável que ela seja uma boa candidata para uso em linha.
Na maioria dos casos, a melhor maneira de garantir que a folha de estilo não bloqueie a renderização do elemento da LCP é reduzir o tamanho dela para que ela fique menor do que o recurso da LCP. Isso deve garantir que não haja um gargalo para a maioria das visitas.
Algumas recomendações para reduzir o tamanho da folha de estilo são:
- Remover CSS não usado: 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 CSS não essencial: divida sua folha de estilo em estilos necessários para o carregamento inicial da página e depois aqueles que podem ser carregados lentamente.
- Minifique e compacte CSS: para estilos que são críticos, certifique-se de reduzir ao máximo o tamanho da transferência deles.
Adiar ou inserir JavaScript de bloqueio de renderização em linha
Quase nunca é necessário adicionar scripts síncronos (scripts sem os atributos async ou defer) à <head> das suas páginas. Isso quase sempre tem um impacto negativo no desempenho.
Nos casos em que o código JavaScript precisa ser executado o mais cedo possível no carregamento da página, é melhor in-line para que a renderização não atrase a espera por outra solicitação de rede. No entanto, assim como nas folhas de estilo, você só deve inserir scripts in-line 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 a renderização do lado do servidor
A renderização do lado do servidor (SSR, na sigla em inglês) é o processo de executar a lógica do aplicativo do lado do cliente no servidor e responder a solicitações de documentos HTML com a marcação HTML completa.
Ao otimizar a LCP, há duas principais vantagens da SSR:
- Seus recursos de imagem serão detectáveis no código-fonte HTML, conforme discutido na etapa 1 antes.
- Não é necessário concluir outras solicitações JavaScript para que o conteúdo da sua página possa ser renderizado.
A principal desvantagem da SSR é que ela exige mais tempo de processamento do servidor, o que pode deixar seu TTFB lento. No entanto, isso 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 site estático (SSG, na sigla em inglês) ou pré-renderização. Esse é o processo de gerar suas páginas HTML em uma etapa de criação, e não sob demanda. Se a pré-renderização é possível com sua arquitetura, ela geralmente é uma escolha melhor em termos de desempenho.
Dividir tarefas longas
Mesmo que você tenha seguido as recomendações anteriores e seu código JavaScript não bloqueie a renderização nem seja responsável por renderizar os elementos, ainda é possível que a LCP atrasa.
O motivo mais comum para isso acontecer é quando as páginas carregam grandes arquivos JavaScript, que precisam ser analisados e executados na thread principal do navegador. Isso significa que, mesmo que o download do recurso de imagem tenha sido concluído, talvez seja necessário aguardar até que um script não relacionado termine a execução antes de ser renderizado.
Atualmente, todos os navegadores renderizam imagens na linha de execução principal, o que significa que qualquer elemento que bloqueie a linha de execução principal também pode levar a um atraso desnecessário na renderização do elemento.
3. Reduzir a duração da carga de recursos
O objetivo desta etapa é reduzir o tempo gasto na transferência dos bytes do recurso pela rede para o dispositivo do usuário. Em geral, existem três maneiras de fazer isso:
- Reduza o tamanho do recurso.
- Reduzir a distância que o recurso tem que percorrer.
- Reduza a contenção da largura de banda da rede.
- Elimine completamente o tempo de rede.
Reduzir o tamanho do recurso
O recurso LCP de uma página (se tiver uma) será uma imagem ou uma fonte da Web. Os guias a seguir trazem muitos detalhes sobre 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 tem que percorrer
Além de reduzir o tamanho de um recurso, você também pode reduzir os tempos de carregamento colocando os servidores o mais próximo possível dos usuários. A melhor forma de fazer isso é usando uma rede de fornecimento de conteúdo (CDN).
As CDNs de imagem são especialmente úteis porque não apenas reduzem a distância que o recurso tem que percorrer, mas também reduzem o tamanho do recurso, implementando automaticamente todas as recomendações de redução de tamanho anteriores para você.
Reduza a contenção da largura de banda da rede
Mesmo que você tenha reduzido o tamanho do recurso e a distância que ele precisa percorrer, o carregamento de um recurso pode levar muito tempo se você estiver carregando muitos outros ao mesmo tempo. Esse problema é conhecido como contenção de rede.
Se você tiver dado ao seu recurso de LCP um fetchpriority alto e começar a carregá-lo o mais rápido possível, o navegador vai fazer o possível para impedir que recursos de menor prioridade concorram com ele. No entanto, se você estiver carregando muitos recursos com alta fetchpriority ou apenas carregando muitos recursos em geral, isso pode afetar a velocidade de carregamento do recurso de LCP.
Eliminar completamente o tempo de rede
A melhor maneira de reduzir a duração da carga de recursos é eliminar a rede do processo. Se você exibir seus recursos com uma política de controle de cache eficiente, os visitantes que solicitarem esses recursos uma segunda vez terão esses recursos veiculados a partir do cache, diminuindo a duração do carregamento de recursos em praticamente zero.
Se o recurso de LCP for uma fonte da Web, além de reduzir o tamanho da fonte da Web, considere também se é necessário bloquear a renderização no carregamento do recurso de fonte da Web. Se você definir um valor 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 outra solicitação de rede.
Por fim, se o recurso de LCP for pequeno, talvez faça sentido in-line como um URL de dados, o que também eliminará a solicitação adicional de rede. No entanto, o uso de URLs de dados tem ressalvas, porque os recursos não podem ser armazenados em cache e, em alguns casos, podem levar a atrasos mais longos de renderização devido ao custo de decodificação adicional.
4. Reduzir o tempo para o primeiro byte
A meta desta etapa é entregar o HTML inicial o mais rápido possível. Esta etapa é listada por último, porque geralmente é a que os desenvolvedores têm menos controle. No entanto, é também uma das etapas mais importantes, porque afeta diretamente cada etapa seguinte. Nada pode acontecer no front-end até que o back-end entregue esse primeiro byte de conteúdo. Portanto, tudo o que você puder fazer para acelerar seu TTFB também melhorará todas as outras métricas de carregamento.
Uma causa comum de um TTFB lento para um site que seria rápido é o fato de os visitantes chegarem por meio de vários redirecionamentos, como a partir de anúncios ou links encurtados. Sempre minimize o número de redirecionamentos pelos quais um visitante deve aguardar.
Outra causa comum é quando o conteúdo em cache não pode ser usado de um servidor de borda do CDN, e todas as solicitações devem 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 de TTFB.
Monitorar o detalhamento da LCP em JavaScript
As informações de tempo de todas as subpartes da LCP discutidas anteriormente estão disponíveis em JavaScript por meio de uma combinação das seguintes APIs de desempenho:
A vantagem de computar esses valores de tempo em JavaScript é que você pode enviá-los a um provedor de análise ou registrá-los nas ferramentas de desenvolvedor para ajudar na depuração e na 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 de desempenho do Chrome DevTools.
As visualizações na faixa Tempos são particularmente úteis quando observadas junto com as faixas 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 da LCP na faixa de marcação de tempo, também é possível usar o JavaScript para calcular a porcentagem de cada subparte do tempo total da LCP. Com essas informações, você pode determinar se as páginas estão atendendo aos detalhamentos 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 é a divisão da LCP nas suas páginas para os usuários reais.
Monitorar detalhamentos de LCP usando a extensão Web Vitals
A extensão Métricas da Web registrará o tempo da LCP, o elemento da LCP e essas quatro subpartes no console, para facilitar a visualização do detalhamento.
Resumo
A LCP é complexa, e o tempo dela pode ser afetado por vários fatores. Mas, se você considerar que otimizar a LCP é principalmente otimizar a carga do recurso de LCP, isso pode simplificar significativamente as coisas.
De modo geral, a otimização da LCP pode ser resumida em quatro etapas:
- Verifique se o recurso da LCP começa a ser carregado o mais cedo possível.
- Verifique se o elemento da LCP pode ser renderizado assim que o recurso terminar de carregar.
- Reduza o tempo de carregamento do recurso de LCP o máximo possível sem sacrificar a qualidade.
- Entregar o documento HTML inicial o mais rápido possível.
Se você consegue seguir essas etapas nas suas páginas, pode garantir que a experiência de carregamento está sendo ideal para os usuários e que isso será refletido nas suas pontuações de LCP reais.