Um guia explicativo sobre como detalhar a LCP e identificar áreas importantes para melhorar.
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. Especificamente, a LCP mede o tempo desde que o usuário começa a carregar a página até que a maior imagem ou bloco de texto seja renderizado na janela de visualização.
Para oferecer uma boa experiência ao usuário, os sites 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 carrega e renderiza uma página da Web, e atrasos em qualquer um deles podem 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, é preciso analisar todo o processo de carregamento e garantir que cada etapa esteja otimizada.
Noções básicas sobre sua métrica de LCP
Antes de otimizar a LCP, os desenvolvedores precisam entender se têm algum problema de LCP e a extensão de qualquer um.
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 uma ferramenta baseada em laboratórios, como o Lighthouse, ou os testes locais. Essas ferramentas baseadas em laboratório podem fornecer muitas informações para explicar e ajudar você a melhorar a LCP, mas esteja ciente de que os testes de laboratório por si só podem não representar completamente a experiência dos seus usuários reais.
Os dados de LCP baseados em usuários reais podem ser extraídos das ferramentas de monitoramento de usuário real (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.
Como usar dados de CrUX LCP do PageSpeed Insights
O PageSpeed Insights dá acesso aos dados do CrUX na parte superior da seção Descubra o que seus usuários reais estão experimentando. Há dados mais detalhados baseados em laboratório 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 de computador para toda a Origin
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.
A LCP de toda a origem pode ser muito diferente da LCP de uma página individual, dependendo de como ela é carregada na página em comparação com outras páginas na mesma origem. Ela também pode ser afetada pela forma como os visitantes navegam nessas páginas. As páginas iniciais tendem a ser acessadas por novos usuários e, por isso, podem ser carregadas de modo “frio”, sem nenhum conteúdo armazenado em cache, e por isso são frequentemente 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 desta 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.
Como usar as métricas complementares do PageSpeed Insights CrUX
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 momento em que o visitante começa a navegar até 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 a renderização de uma página começa, pode aparecer uma pintura inicial (por exemplo, a cor do plano de fundo) seguida do 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 a FCP pode indicar que o navegador precisa fazer o download de muitos ativos de bloqueio de renderização. Também pode ser um sinal de que é necessário fazer muito trabalho para renderizar qualquer conteúdo significativo, um sinal clássico de que um site depende muito da renderização do lado do cliente.
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á fazendo outro trabalho antes de exibir o conteúdo da LCP.
Como usar os dados do PageSpeed Insights Lighthouse
A seção Lighthouse do PageSpeed Insights oferece orientações para melhorar a LCP, mas primeiro é preciso verificar se a LCP fornecida está amplamente de acordo com os dados reais do usuário fornecidos pelo CrUX. Se o Lighthouse e o CrUX discordarem, é 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 de LCP para mostrar apenas as auditorias relevantes para LCP da seguinte maneira:
Além das Oportunidades de melhoria, existem informações de Diagnóstico que podem oferecer mais informações para ajudar a diagnosticar o problema. O diagnóstico Maior elemento de pintura de conteúdo mostra um detalhamento útil dos vários tempos que compuseram 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 uma resposta sobre como melhorar essa métrica. Com tarefas complexas, geralmente é melhor dividi-las em tarefas menores e mais gerenciáveis e abordar cada uma delas separadamente.
Nesta seção, apresentamos uma metodologia para dividir a LCP nas subpartes mais importantes e, em seguida, apresentamos recomendações específicas e práticas recomendadas para otimizar cada parte.
A maioria dos carregamentos de página geralmente inclui várias solicitações de rede. No entanto, para identificar oportunidades para melhorar a LCP, comece analisando apenas duas delas:
- O documento HTML inicial
- O recurso de LCP (se aplicável)
Embora outras solicitações na página possam afetar a LCP, as duas (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 LCP.
Para identificar o recurso da LCP, use 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 de um carregamento de página típico, em que o elemento da LCP requer uma solicitação de imagem para ser renderizado.
Para uma página bem otimizada, você quer que a solicitação de recurso da LCP comece a carregar o mais cedo possível e que o elemento da LCP seja renderizado o mais rápido possível após o carregamento do recurso. Para ajudar a visualizar se uma página específica segue ou não esse princípio, divida 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 até 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 de LCP. Se o elemento da LCP não exige uma carga de recurso para renderizar (por exemplo, se o elemento for um nó de texto renderizado com uma fonte do sistema), desta vez será 0.
- Duração do carregamento do recurso
- O tempo necessário para carregar o próprio recurso de LCP. Se a LCP elemento não requer uma carga de recurso para renderizar, agora 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.
A 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 ou lacuna entre eles. Coletivamente, elas somam o tempo total da LCP.
Ao otimizar a LCP, vale a pena tentar 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 vai melhorar a LCP, apenas mudará o tempo economizado para outra parte.
Por exemplo, na hierarquia de rede anterior, se você reduzisse o tamanho do arquivo da 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 de 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.
Este exemplo ajuda a ilustrar o ponto de que você precisa otimizar todas essas subpartes para alcançar os melhores resultados de LCP.
Períodos de subparte ideais
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.
Observe que esses detalhamentos de tempo são apenas diretrizes, não regras rígidas. Se os tempos da LCP nas suas páginas estiverem consistentemente dentro de 2,5 segundos, não importa quais sejam as proporções relativas. Mas se você estiver gastando muito tempo desnecessário em qualquer um dos "atrasos" 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 da LCP em que um desses dois recursos não estiver sendo carregado é uma oportunidade de melhoria.
Como otimizar cada parte
Agora que você entende como cada subparte da LCP precisa ser dividida em uma página bem otimizada, comece a otimizar suas próprias páginas.
As próximas quatro seções apresentarão 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 de LCP comece a ser carregado o mais cedo possível. Embora, em teoria, o primeiro tempo em que um recurso possa começar a carregar seja imediatamente após o TTFB, na prática, há sempre algum atraso até que os navegadores comecem a carregar 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 seguintes casos, o navegador pode descobrir o recurso LCP verificando a resposta do documento HTML:
- O elemento LCP é
<img>, e os atributossrcousrcsetdele estão presentes na marcação HTML inicial. - O elemento LCP requer uma imagem de plano de fundo CSS, mas essa imagem é pré-carregada usando
<link rel="preload">na marcação HTML (ou usando um cabeçalhoLink). - O elemento da 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).
Aqui estão alguns exemplos em que o recurso LCP não pode ser descoberto a partir da verificação da resposta do documento HTML:
- O elemento da LCP é uma
<img>adicionada dinamicamente à página usando JavaScript. - O elemento LCP é carregado lentamente com uma biblioteca JavaScript que oculta os atributos
srcousrcset(geralmentedata-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 e começar a carregar o recurso da LCP. 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 só é referenciado somente a partir de um arquivo CSS ou JavaScript externo, o recurso de LCP precisa ser pré-carregado com uma alta prioridade de busca, por exemplo:
<!-- Load the stylesheet that will reference the LCP image. -->
<link rel="stylesheet" href="/path/to/styles.css">
<!-- Preload the LCP image with a high fetchpriority so it starts loading with the stylesheet. -->
<link rel="preload" fetchpriority="high" as="image" href="/path/to/hero-image.webp" type="image/webp">
Otimizar a prioridade que o recurso recebe
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 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 sua imagem 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. Assim, o carregamento pode começar mais tarde do que o normal.
Mesmo sem o carregamento lento, as imagens não são inicialmente carregadas com a maior prioridade pelos navegadores, porque 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">
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 aparecem 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 alterações com ferramentas de laboratório e campo.
Depois de otimizar a prioridade do recurso de LCP e o tempo de descoberta, sua hierarquia de rede terá esta aparência (com o recurso de LCP começando ao mesmo tempo que o primeiro recurso):
2. Elimine o atraso de renderização do elemento.
O objetivo dessa etapa é garantir que o elemento da LCP seja renderizado imediatamente após o carregamento do recurso, independentemente de quando isso acontecer.
O principal motivo para o elemento da LCP não conseguir renderizar imediatamente após o carregamento do recurso é se a renderização estiver bloqueada por algum outro motivo:
- A renderização de toda a página está bloqueada devido a folhas de estilo ou scripts síncronos na
<head>que ainda estão sendo carregados. - O recurso de LCP terminou de carregar, mas o elemento da LCP ainda não foi adicionado ao DOM (está aguardando o carregamento de um código JavaScript).
- O elemento está sendo ocultado por 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 aguardar até que essas tarefas longas sejam concluídas.
As seções a seguir explicam como lidar com as causas mais comuns de atrasos de renderização de elementos desnecessários.
Reduza ou in-line as folhas de estilo que bloqueiam a renderização
Folhas de estilo carregadas a partir de marcação HTML bloquearão a renderização de todo o conteúdo que as segue, o que é bom, porque você geralmente não quer renderizar HTML sem estilo. No entanto, se a folha de estilo for tão grande que demore muito mais para carregar que o recurso da LCP, isso impedirá a renderização do elemento da LCP, mesmo após a conclusão do carregamento do recurso, como mostrado neste exemplo:
Para corrigir isso, as opções são:
- inline da folha de estilo no HTML para evitar a solicitação de rede adicional; 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 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.
Algumas recomendações para reduzir o tamanho da folha de estilo são:
- Remova o CSS não utilizado: use o Chrome DevTools para encontrar regras de CSS que não estão sendo usadas e podem ser removidas (ou adiadas).
- Adie o carregamento de páginas não essenciais: divida sua folha de estilos em estilos necessários para o carregamento inicial da página e depois aqueles que podem ser carregados lentamente.
- Reduza e compacte o CSS: para estilos críticos, reduza o tamanho de transferência 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 páginas. Fazer isso quase sempre terá 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 à espera de 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, na sigla em inglês) é 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 da LCP, a SSR tem duas vantagens principais:
- Seus recursos de imagem vão estar disponíveis na fonte HTML, conforme discutido na etapa 1.
- O conteúdo da sua página não vai precisar de solicitações JavaScript adicionais para ser concluído antes da renderização.
A principal desvantagem da SSR é que ela exige mais tempo de processamento do servidor, o que pode deixar seu TTFB mais lento. No entanto, 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.
Uma opção semelhante à SSR é chamada de geração estática de sites (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, geralmente ela é uma opção melhor em termos de desempenho.
Dividir tarefas longas
Mesmo que você tenha seguido as orientações anteriores e seu código JavaScript não bloqueie a renderização nem seja responsável pela renderização dos elementos, ele poderá atrasar a LCP.
O motivo mais comum para isso acontecer é quando as páginas carregam grandes arquivos JavaScript, 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 ele ainda tenha que esperar 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. Isso significa que tudo que bloqueia a linha de execução principal também pode levar a um atraso desnecessário de renderização do elemento.
3. Reduzir a duração do carregamento de recursos
O objetivo dessa etapa é reduzir o tempo gasto na transferência de 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.
- Reduza a distância que o recurso precisa percorrer.
- Reduza a contenção da 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
- Use formatos de imagem modernos
- Compactar imagens
- Reduzir o tamanho da fonte na 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 ao aproximar os servidores geograficamente 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 da largura de banda da rede
Mesmo que você reduza o tamanho do seu recurso e a distância que ele precisa percorrer, um recurso ainda poderá levar muito tempo para ser carregado se você carregar 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.
Caso seu recurso de LCP seja uma fonte da Web, além de reduzir o tamanho dela, considere também se é necessário bloquear a renderização no carregamento desse recurso. 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 tem 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 dessa 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, qualquer ação que você possa fazer para acelerar seu TTFB irá melhorar todas as outras métricas de carga também.
Uma causa comum de um TTFB lento para um site que era rápido é a chegada dos visitantes por meio de vários redirecionamentos, como de anúncios ou links encurtados. Sempre minimize o número de redirecionamentos que um visitante precisa aguardar.
Outra causa comum é quando o conteúdo em cache não pode ser usado de um servidor de borda da CDN e todas as solicitações precisam ser direcionadas de volta para o servidor de origem. Isso poderá acontecer se parâmetros de URL exclusivos forem usados pelos visitantes para análise, mesmo que eles não resultem em páginas diferentes.
Para orientações específicas sobre como otimizar o TTFB, consulte o guia de otimização do TTFB.
Monitorar o detalhamento de LCP em JavaScript
As informações de tempo de todas as subpartes 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 observadas junto com os acompanhamentos Rede e Linha de execução principal, porque você pode ver rapidamente o que mais está acontecendo na página durante esses períodos.
Além de visualizar as subpartes da LCP na faixa de tempo, também é possível usar JavaScript para calcular a porcentagem de cada subparte do tempo total de 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.
Monitore detalhamentos de LCP usando a extensão Web Vitals
A extensão Métricas da Web vai registrar o tempo da LCP, o elemento da LCP e essas quatro subpartes no console para facilitar a visualização desse 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:
- Verifique se o recurso de LCP começa a carregar o mais cedo possível.
- Verifique se o elemento da LCP pode ser renderizado assim que o recurso terminar de carregar.
- Reduzir o tempo de carregamento do recurso de LCP o máximo possível sem sacrificar a qualidade.
- Envie o documento HTML inicial o mais rápido possível.
Se você conseguir seguir essas etapas nas suas páginas, terá certeza de que está oferecendo uma experiência de carregamento ideal para os usuários e verá isso refletido nas pontuações reais da LCP.