Um guia detalhado sobre como dividir a LCP e identificar as principais áreas a serem melhoradas.
Publicado em 30 de abril de 2020
A Maior exibição de conteúdo (LCP) é uma das três métricas das Core Web Vitals e representa a rapidez com que o conteúdo principal de uma página da Web é carregado. Mais especificamente, o LCP mede o tempo desde o início do carregamento da página até a renderização da maior imagem ou bloco de texto na janela de visualização.
Para oferecer uma boa experiência ao usuário, os sites precisam ter uma LCP de 2,5 segundos ou menos para pelo menos 75% das visitas à página.
Vários fatores podem afetar a rapidez com que o navegador pode carregar e renderizar uma página da Web, e atrasos em qualquer um deles podem ter um impacto significativo no 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 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.
A LCP pode ser medida em várias ferramentas, e nem todas medem a LCP da mesma maneira. Para entender a LCP de usuários reais, precisamos analisar a experiência deles, e não o que uma ferramenta baseada em laboratório, como o Lighthouse, ou testes locais mostram. Essas ferramentas de laboratório podem fornecer muitas informações para explicar e ajudar a melhorar o LCP, mas os testes de laboratório por si só não são totalmente representativos da experiência dos 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 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 no seu site, concentre-se sempre nos dados reais dos usuários.
O PageSpeed Insights mostra até quatro dados CrUX diferentes:
- Dados de dispositivos móveis para este URL
- Dados de computador para este URL
- Dados de dispositivos móveis para toda a Origin
- Dados do computador para toda a Origem
Você pode alternar esses controles nos controles no canto superior e direito desta seção. Se um URL não tiver dados suficientes para ser exibido no nível do URL, mas tiver dados da origem, o PageSpeed Insights sempre mostrará os dados de 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 na 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 CrUX do PageSpeed Insights
Quem quiser 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é mesmo tornar impossível uma LCP de 2, 5 segundos.
Um TTFB alto pode ser devido a vários redirecionamentos do servidor, visitantes localizados muito longe do servidor do site mais próximo, visitantes em más condições de rede ou a incapacidade de usar 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 pela 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.
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 ele precisa fazer 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 grande delta entre a FCP e a LCP indica que o recurso da LCP não está imediatamente disponível para o navegador priorizar (por exemplo, texto ou imagens gerenciadas por JavaScript em vez de estarem disponíveis no HTML inicial) ou que o navegador está realizando outro trabalho antes de exibir o conteúdo da LCP.
Como usar os dados do PageSpeed Insights Lighthouse
A seção do Lighthouse no PageSpeed Insights oferece algumas orientações para melhorar o LCP, mas primeiro você precisa verificar se o LCP fornecido está em geral de acordo com os dados reais do usuário 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 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 de 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 fáceis de gerenciar 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.
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 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 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, é importante que a solicitação de recurso da LCP comece a ser carregada o mais cedo possível e que o elemento da LCP seja renderizado o mais rápido possível após o término do 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 quando o navegador começa a carregar o recurso de 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 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 carregamento do recurso da LCP e o momento em que o elemento da LCP a renderização completa.
O LCP de cada página consiste nessas quatro subcategorias. Não há lacuna ou sobreposição entre elas e somam o tempo total da LCP.
O valor de LCP de cada página pode ser dividido nessas quatro subpartes. Não há sobreposição nem lacuna entre eles. Coletivamente, elas somam o tempo total da LCP.
Ao otimizar a LCP, é útil tentar otimizar essas partes 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 o LCP, apenas transfere o tempo economizado para outra parte.
Por exemplo, na hierarquia de rede anterior, se você reduzisse o tamanho do arquivo da nossa imagem comprimindo ou mudando para um formato mais ideal (como AVIF ou WebP), isso reduziria a duração do carregamento do recurso, mas não melhoraria a LCP porque o tempo simplesmente mudaria para a subparte atraso de renderização do elemento:
Isso acontece porque, nesta página, o elemento da LCP fica oculto até o código JavaScript terminar de carregar, e então 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 pista de que você quer chegar o mais próximo possível de zero. As outras duas partes envolvem solicitações de rede que, por sua natureza, são demoradas.
Essas divisões de tempo são 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 da LCP deve ser gasta carregando o documento HTML e a origem da 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 um dos tempos das subpartes da LCP deve ser dividido em uma página bem otimizada, é possível começar 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 vão ter 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 seu 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.
- A prioridade que o recurso recebe.
Otimizar quando o recurso for descoberto
Para garantir que o recurso de LCP comece a carregar 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 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 requer uma imagem de plano de fundo do 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 exige uma fonte da Web para renderizar. 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 geralmente 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 atrasos desnecessários no carregamento de recursos, o recurso LCP precisa ser detectável na fonte HTML. Nos casos em que o recurso é referenciado apenas em um arquivo CSS ou JavaScript externo, o recurso LCP precisa ser pré-carregado com uma prioridade de busca alta, 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 da LCP seja detectável na marcação HTML, é possível que ele ainda não comece 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 bloqueadores de 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 em mais de uma ou duas imagens torna essa configuração inútil para reduzir a 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">
Diminuir a prioridade de determinados recursos pode aumentar a largura de banda para os recursos que precisam mais dela, mas tenha cuidado. Sempre verifique a prioridade do recurso no DevTools e teste as mudanças com ferramentas de laboratório e de 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 pelo qual o elemento LCP não pode ser renderizado imediatamente após o carregamento do recurso é se a renderização for 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.
Reduzir ou inlinear folhas de estilo que impedem 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 você não quer renderizar HTML sem estilo. No entanto, se a folha de estilo for tão grande que demore muito mais para carregar do que o recurso LCP, ela impedirá a renderização do elemento LCP, mesmo depois que o recurso terminar de carregar, como mostrado neste exemplo:
Para corrigir isso, as opções são:
- inline a folha de estilo no HTML para evitar a solicitação de rede adicional; ou
- reduz 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 inline 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 ser carregada do que o recurso da LCP, provavelmente ela não será uma boa opção para inserção in-line.
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 dele para que fique menor do que o recurso da LCP. Isso deve garantir que não seja um gargalo para a maioria das visitas.
Confira algumas recomendações para reduzir o tamanho da folha de estilo:
- 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 CSS não crítico: divida sua folha de estilo em estilos necessários para o carregamento inicial da página e estilos que podem ser carregados de forma lenta.
- Minificar e compactar o CSS: para estilos críticos, reduza o tamanho de transferência deles o máximo possível.
Adiar ou in-line o JavaScript de bloqueio de renderização
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 acontece com as folhas de estilo, você só deverá 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 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 HTML completa.
Do ponto de vista da otimização do LCP, há duas vantagens principais do SSR:
- 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 renderizar.
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 gerar suas páginas HTML em uma etapa de criação e não 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 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.
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 dos bytes do recurso pela rede para o dispositivo do usuário. Em geral, há três 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 de LCP de uma página (se houver) será uma imagem ou uma fonte da Web. Os guias a seguir detalham como reduzir o tamanho de ambos:
- Veicular 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. E a melhor maneira de fazer isso é usando uma rede de fornecimento de conteúdo (CDN).
As CDNs de imagem, em particular, são especialmente úteis porque reduzem a distância que o recurso precisa percorrer, mas geralmente também reduzem o tamanho do recurso, implementando automaticamente todas as recomendações de redução de tamanho mencionadas anteriormente.
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 apenas carregando muitos recursos em geral, isso poderá afetar a velocidade de carregamento do recurso da LCP.
Elimine completamente o tempo de rede
A melhor maneira de reduzir a duração do carregamento de recursos é eliminar totalmente a rede do processo. Se você disponibilizar seus recursos com uma política de controle de cache eficiente, os visitantes que solicitarem esses recursos uma segunda vez os veicularão a partir do cache, levando a duração do carregamento de recursos a praticamente zero.
Se o recurso de LCP for uma fonte da Web, além de reduzir o tamanho da fonte, 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, talvez faça sentido in-line os recursos como um URL de dados, o que também eliminará a solicitação de rede adicional. 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. Reduza o tempo inicial de carregamento
O objetivo desta etapa é entregar o HTML inicial o mais rápido possível. Essa etapa está 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 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 em um servidor de borda do CDN e todas as solicitações precisam ser direcionadas de volta ao 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 a divisão do LCP no JavaScript
As informações de tempo de todas as subpartes da LCP discutidas anteriormente estão disponíveis em JavaScript por uma combinação das seguintes APIs de desempenho:
A vantagem de calcular esses valores de tempo em JavaScript é que você pode enviá-los a um provedor de análises ou registrá-los nas ferramentas de desenvolvedor 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 analisadas com as faixas Rede e Principal, porque você pode conferir rapidamente o que mais está acontecendo na página durante esses períodos.
Além de visualizar as subpartes da LCP na faixa de tempo, também é possível usar JavaScript para calcular a porcentagem de cada subparte do tempo total da LCP. Com essas informações, é possível 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 de LCP para o console.
Essas duas 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.
Monitorar falhas de LCP usando o Chrome DevTools
O Chrome DevTools registra o tempo e o elemento da LCP, além dessas quatro subpartes, em tempo real para que você possa conferir esse detalhamento.
Resumo
A LCP é complexa, e o tempo dela 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.
De modo geral, a otimização da LCP pode ser resumida em quatro etapas:
- Garanta que o recurso da LCP comece 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, pode ter certeza de que está oferecendo uma experiência de carregamento ideal para os usuários, e isso vai aparecer nos seus resultados de LCP reais.