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 do Core Web Vitals e representa a rapidez com que o conteúdo principal de uma página da Web é carregado. Mais especificamente, a LCP mede o tempo desde o início do carregamento da página pelo usuário 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 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 pode carregar e renderizar 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 o LCP, os desenvolvedores precisam entender se têm um problema de LCP e qual é 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 o que uma ferramenta baseada em laboratório, como o Lighthouse, ou testes locais mostram. Essas ferramentas 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 do LCP do CrUX no Chrome DevTools
O painel Performance do Chrome DevTools mostra sua experiência de LCP local ao lado do LCP do CrUX da página ou da origem na visualização de métricas em tempo real.
Ao sobrepor os dados de campo no painel "Performance", você pode 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 oferece acesso aos dados do CrUX na seção superior chamada 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 dispositivo têm problemas de LCP.
Como usar as métricas complementares do CrUX do PageSpeed Insights
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 que bloqueiam a 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.
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 Lighthouse no PageSpeed Insights
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, 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, não da origem completa, antes de agir.
Se o Lighthouse e o CrUX mostrarem valores de LCP que precisam de melhoria, a seção do Lighthouse pode 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 fáceis de gerenciar e abordar cada uma 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, é importante que a solicitação de recurso da LCP comece a ser carregada o mais cedo possível e que o elemento 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 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 LCP não exigir um carregamento de recursos para renderização, esse tempo será 0.
- Atraso na renderização do elemento
- O tempo entre o término do carregamento do recurso LCP e a renderização completa do elemento LCP.
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 subpartes 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 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 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 natureza, levam tempo.
Essas divisões de tempo são diretrizes, não regras rígidas. Se os tempos de LCP nas suas páginas forem consistentemente de 2,5 segundos, não importa muito quais são 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 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 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. Em outras palavras, se o recurso de LCP começar a carregar depois do primeiro, há uma oportunidade de melhoria.
De modo geral, há dois fatores que afetam a rapidez com que um recurso LCP pode ser carregado:
- 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 atributossrc
ousrcset
dele 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 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
src
ousrcset
(geralmente comodata-src
oudata-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 esperar o término das solicitações de rede, antes de descobrir o recurso LCP e começar a carregá-lo. Isso nunca é ideal.
Para eliminar o atraso desnecessário no carregamento de recursos, o recurso LCP precisa ser detectável na origem 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 LCP seja detectável pela 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 só será carregado depois que o layout confirmar que a imagem está na viewport. Por isso, 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">
É recomendável definir fetchpriority="high"
em um elemento <img>
se você achar que ele é o elemento de 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 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. Eliminar o atraso na renderização do elemento
O objetivo desta etapa é garantir que o elemento LCP possa ser renderizado imediatamente após o carregamento do recurso, não importa quando isso aconteça.
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 é bloqueada devido a folhas de estilo ou scripts síncronos no
<head>
que ainda estão sendo carregados. - O recurso LCP terminou de carregar, mas o elemento LCP ainda não foi adicionado ao DOM. Ele está aguardando o carregamento de algum 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 está bloqueada devido a tarefas longas, e o trabalho de renderização precisa esperar até que essas tarefas sejam concluídas.
As seções a seguir explicam como resolver as causas mais comuns de atraso desnecessário na renderização de elementos.
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, você pode:
- 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 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.
Confira algumas recomendações para reduzir o tamanho da folha de estilo:
- 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 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 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 a renderização pelo 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 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 dos 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.
- Reduzir a contenção de largura de banda da rede.
- Elimine o tempo de rede por completo.
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 dos dois:
- 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 imagem, em particular, são especialmente úteis porque não apenas reduzem a distância que o recurso precisa percorrer, mas também reduzem o tamanho do recurso, implementando automaticamente todas as recomendações de redução de tamanho anteriores para você.
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ê tiver dado ao recurso LCP um fetchpriority
alto e começar a carregá-lo o mais rápido possível, o navegador vai fazer o possível para evitar que recursos de prioridade mais baixa compitam 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.
Eliminar totalmente 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, você também precisará 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 vai ficar visível durante o carregamento, e o LCP não será bloqueado em uma solicitação de rede adicional.
Por fim, se o recurso de LCP for pequeno, pode ser útil inlinear 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. 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 esperar.
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 pode acontecer se os visitantes usarem parâmetros de URL exclusivos para análises, mesmo que 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 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 de desempenho 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 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});
Você pode usar esse código como está para depuração local ou modificá-lo para enviar esses dados a um provedor de análise e entender melhor o que é o detalhamento do LCP nas suas páginas para usuários reais.
Resumo
O LCP é complexo, e o tempo dele pode ser afetado por vários fatores. No entanto, se você considerar que otimizar a LCP significa principalmente otimizar a carga do recurso LCP, isso pode simplificar bastante as coisas.
Em um nível alto, a otimização do LCP pode ser resumida em quatro etapas:
- O recurso da LCP precisa começar a carregar o mais cedo possível.
- Garanta que o elemento LCP possa ser renderizado assim que o recurso terminar de carregar.
- Reduza o tempo de carregamento do recurso 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.