Otimize o atraso de carregamento do recurso do LCP

Este guia faz parte do hub de Largest Contentful Paint (LCP). O Resource Load Delay é frequentemente o maior responsável por uma pontuação ruim de LCP, especialmente em sites SPA! 

Otimize o Resource Load Delay do LCP

O Largest Contentful Paint (LCP) é uma das 4 subfases do LCP: TTFB, Resource Load Delay, Resource Load Duration e Element Render Delay. 

Uma dica rápida: se o seu LCP for uma imagem, quase sempre será pior que texto. Você deve rastrear os tipos de elemento do seu LCP nos seus dados de RUM, caso contrário, você estará voando às cegas.

O que é Resource Load Delay?

O Resource Load Delay é o tempo entre o TTFB e quando o navegador inicia o download do recurso do LCP. Basicamente, o navegador deve colocar o recurso do LCP (a imagem do LCP, por exemplo)  na fila o mais rápido possível. Se ele não for colocado na fila o mais rápido possível, é muito provável porque o navegador não consegue descobri-lo imediatamente ou não o reconhece como importante o suficiente.

Um valor alto aqui indica um problema de arquitetura (onde o navegador não consegue encontrar a URL do recurso no payload HTML inicial. Este Resource Load Delay pode ser visto como o tempo que o navegador gasta identificando que o recurso do LCP é necessário e decidindo buscá-lo.

Também é importante entender que o Resource Load Delay acontece antes que o recurso seja de fato carregado. É por isso que não tem nada a ver com imagens responsivas ou novos formatos de imagem como WebP ou AVIF.

Para elementos do LCP baseados em texto e renderizados com uma fonte do sistema, o Resource Load Delay é tipicamente zero porque nenhum recurso externo precisa ser buscado. Valores altos de Resource Load Delay são específicos para elementos do LCP que dependem de um recurso de rede externo, como uma imagem ou arquivo de vídeo.

Como um navegador encontra o elemento do LCP?

Para reduzir o Resource Load Delay, você deve entender como os navegadores descobrem recursos (ou ao menos descobrem o elemento do LCP). Navegadores usam dois mecanismos: um caminho rápido e um caminho lento. Primeiro, você precisará garantir que o elemento do LCP esteja 'no caminho rápido'

• O Parser do DOM (Caminho Lento): Este é o parser principal do navegador e ele é um monstro. Ele constrói a página completa  lendo o HTML, as planilhas de estilo (CSS) e interagindo com JavaScript. Este é o caminho lento porque ele pode ser atrasado e pausado por outros arquivos baixando e executando primeiro, criando uma cadeia de dependências que introduz atraso.
• O Preload Scanner (O Caminho Rápido): Como o parser do DOM é (relativamente) lento, os navegadores têm um scanner secundário extremamente rápido que escaneia a página rapidamente em busca de recursos para download e não será pausado  por nada. Se ele encontrar tags <script>, <img> sem lazy loading ou <link>, ele as coloca na fila de download imediatamente, antes que o CSS seja processado ou o JavaScript seja executado. Este é o caminho ideal para qualquer recurso crítico.

Toda a estratégia para otimizar o Resource Load Delay se baseia em um princípio: garanta que a URL do recurso do LCP seja descoberta o mais cedo possível pelo preload scanner.

Isso significa 2 coisas para um elemento do LCP:

1. Garanta que o preload scanner consiga encontrá-lo usando uma tag de imagem normal que não tenha a propriedade loading="lazy".
2. Garanta que o preload scanner não priorize muitos recursos menos importantes.

Por que o Load Delay importa para os Core Web Vitals

Desenvolvedores iniciantes costumam pensar que o LCP é um problema de "tamanho de arquivo". Isso leva as equipes a focarem em compressão de imagem, formatos de imagem modernos e imagens responsivas. Isso é um erro. Nossa própria pesquisa de Core Web Vitals mostra que o maior gargalo isolado no LCP é o TTFB (48%), seguido pelo Resource Load Delay que ocupa (24%). O tempo de carregamento ocupa apenas 10%, seguido pelo Element Render Delay que ocupa 17%.

O truque é que o Load Delay é quase totalmente corrigível, enquanto o TTFB sempre existirá. Isso faz do Load Delay o elemento com o maior potencial de otimização.

Como detectar o Resource Load Delay

Para corrigir o Resource Load Delay, primeiro você precisa medi-lo com precisão. O fluxo de trabalho é sempre: verificar com o CrUX, para primeiro definir o problema com field data de usuários reais (RUM) e, só depois, passar para o Chrome DevTools para análise profunda.

Passo 1: Verifique com o CrUX.

O CrUX é o field data público de usuários reais do Google de usuários elegíveis do Chrome, apresentado como uma visão contínua de 28 dias dos seus Core Web Vitals no 75º percentil. Ele diz se um número é bom ou ruim, mas não diz quem, o quê ou por quê. Como o Google depende dos dados do CrUX, essa é sua melhor fonte da verdade como ponto de partida.

Vá até cruxvis.withgoogle.com, insira o seu site, navegue até Loading Performance e clique em  subpartes da imagem do Largest Contentful Paint (LCP)

Passo 2: Analise o Field Data (RUM)

O RUM coleta os Core Web Vitals de todos os seus usuários reais e oferece uma visão muito mais específica e detalhada. Ele diz quem e o quê, segmentado da forma que você quiser (e essa informação é ouro), mas não o porquê.

Esta captura de tela do CoreDash informa, por exemplo, quais URLs sofrem com o Resource Load Delay (em verde)

Passo 3: Diagnostique com o DevTools

Assim que seus dados de RUM identificarem uma página alvo e um elemento do LCP, você usa o Chrome DevTools para diagnosticar a causa. O objetivo aqui é reproduzir o problema e medir as subpartes do LCP para obter um valor preciso de Resource Load Delay. O DevTools também é onde você faz uma análise da main thread para ver exatamente quais tarefas estão rodando e potencialmente bloqueando o processo de renderização.

Guia passo a passo: escrevemos um tutorial completo deste fluxo de trabalho: Diagnostique o LCP com o painel de Performance do Chrome DevTools. Ele cobre a configuração de throttling, gravação de um trace e leitura do valor exato do Resource Load Delay no detalhamento do LCP.

Causas Comuns e Soluções de Alto Impacto

Um alto Resource Load Delay é causado por uma de duas coisas: o recurso do LCP é descoberto tarde ou recebe uma prioridade de busca baixa. Aqui estão os erros de arquitetura mais comuns e suas soluções.

Causa: LCP Carregado via CSS

O Problema: O preload scanner não faz parse de arquivos CSS. Quando a sua imagem do LCP é definida com um background-image em CSS, sua URL fica invisível para esse scanner de alta velocidade. O navegador só consegue descobrir a imagem após baixar o HTML, encontrar o link do arquivo CSS, baixar o arquivo CSS, construir o CSSOM e então aplicar o estilo. Essa cadeia de dependências causa diretamente um alto Resource Load Delay. Para mais detalhes sobre esse padrão, consulte nosso guia sobre como adiar background images.

A Solução: A implementação correta é evitar usar background-image para qualquer elemento crítico do LCP. Use uma tag <img> padrão em vez disso. Isso coloca a URL da imagem diretamente no HTML onde o preload scanner pode encontrá-la imediatamente. Você pode alcançar o mesmo resultado visual com CSS.

Exemplo de Implementação:

Anti-Pattern (Não Faça Isso):

    <!-- CSS -->
   .hero {
      background-image: url('hero-image.jpg');
      height: 500px;
      width: 100%;
    }

    <!-- HTML -->
    <div class="hero"></div>
    

Melhor Prática (Faça Isso em Vez Disso):

    <!-- HTML -->
    <div class="hero-container">
      <img
        src="hero-image.jpg"
        alt="A descriptive alt text for the hero image"
        fetchpriority="high"
        class="hero-background-img"
        width="1200"
        height="500"
      />
      <div class="hero-content">
        <h1>Page Title</h1>
      </div>
    </div>

    <!-- CSS -->
   .hero-container {
      position: relative;
      height: 500px;
      width: 100%;
    }

   .hero-background-img {
      position: absolute;
      inset: 0; /* Equivalent to top: 0; right: 0; bottom: 0; left: 0; */
      width: 100%;
      height: 100%;
      object-fit: cover; /* This property mimics background-size: cover */
      z-index: -1; /* Places the image behind other content */
    }
    

Essa implementação oferece o mesmo resultado visual, mas torna a imagem do LCP detectável no primeiro momento possível, o que minimiza o seu Load Delay.

Causa: Renderização no Cliente e Injeção de JavaScript

O Problema: Aplicações que usam frameworks de renderização no cliente (CSR) como React ou Vue costumam servir uma casca HTML mínima. O conteúdo real, incluindo a tag <img> do LCP, só é inserido no DOM via JavaScript após os grandes pacotes do framework serem baixados, processados e executados. Esse processo esconde fundamentalmente o recurso do LCP do preload scanner, criando uma alta latência de descoberta.

A Solução: A solução mais eficaz é mover a renderização inicial do cliente para o servidor.

• Renderização no Servidor (SSR) ou Geração de Site Estático (SSG): Padrões de arquitetura como SSR ou SSG geram o HTML completo no servidor. O navegador recebe um documento completo contendo a tag <img> e seu atributo src, tornando o recurso do LCP imediatamente detectável pelo preload scanner. Essa é a arquitetura exigida para qualquer página com desempenho crítico.
• Otimizações Específicas de Framework: Frameworks modernos também fornecem otimizações integradas. Por exemplo, o componente <Image> do Next.js tem uma propriedade priority. Definir isso como true instrui o framework a adicionar automaticamente os atributos <link rel="preload"> e fetchpriority="high" corretos, garantindo que a imagem seja descoberta e buscada com a prioridade correta.

Causa: Usando loading="lazy" na Imagem do LCP

O Problema: Esse é um erro frequente e de alto impacto. O atributo loading="lazy" é uma instrução direta para o navegador atrasar a busca de uma imagem até que ela esteja perto da viewport. Embora essa seja a otimização correta para imagens below-the-fold, aplicá-la a um elemento do LCP above-the-fold é contraproducente. O preload scanner do navegador foi projetado para ignorar imagens com loading="lazy", o que garante uma descoberta tardia e um alto Resource Load Delay.

A Solução: A solução requer diligência.

• Remova o loading="lazy" da Imagem do LCP: Qualquer imagem que tenha probabilidade de ser o elemento do LCP não deve ter o atributo loading="lazy". O comportamento padrão do navegador é loading="eager", que é a configuração correta para conteúdo crítico above-the-fold. Omitir o atributo loading totalmente tem o mesmo efeito.
• Audite e Configure Ferramentas de Terceiros: Você também deve auditar ferramentas de terceiros. Muitas plataformas de CMS como WordPress e vários plugins de otimização de imagem aplicam automaticamente lazy loading a todas as imagens. É essencial configurar essas ferramentas para excluir a imagem do LCP desse comportamento. Isso geralmente envolve criar uma regra de exclusão para as primeiras uma ou duas imagens na página.

Causa: Estrutura HTML Subótima e Documentos Grandes

O Problema: O preload scanner processa o documento HTML de cima para baixo. Se recursos não críticos, mas que consomem muita largura de banda, como ícones de cabeçalho ou scripts de widget de chat, forem colocados mais acima no <body> do que o elemento do LCP, eles serão descobertos e colocados na fila de download primeiro. Isso consome a largura de banda de rede inicial e pode atrasar o download do recurso do LCP. Um documento HTML grande também pode ser um problema; se o elemento do LCP não estiver no primeiro chunk de dados que o navegador recebe (cerca de 14KB), sua descoberta será atrasada em pelo menos um round trip de rede.

A Solução: Otimize a estrutura e a prioridade do conteúdo dentro do HTML.

• Reordene o HTML: Quando possível, garanta que a tag <img> ou o bloco de texto para o elemento do LCP apareça o mais cedo que você puder colocar dentro da tag <body>.
• Despriorize Imagens Não Críticas: Para imagens não essenciais que precisam aparecer cedo no código-fonte HTML (como ícones em um cabeçalho), aplique loading="lazy". Isso diz ao preload scanner para pulá-las, preservando a fila de download para o elemento do LCP.
• Adie Scripts Não Essenciais: Scripts de analytics, anúncios ou widgets de redes sociais raramente são críticos para a renderização inicial. Mova suas tags <script> para o final do <body> ou use o atributo defer. Isso evita que eles bloqueiem o parser ou compitam por largura de banda da rede com o recurso do LCP.

Priorização Avançada com Resource Hints

Assim que o recurso do LCP estiver detectável no HTML, você pode usar resource hints para dar ao navegador instruções mais explícitas sobre como buscá-lo. Esses hints fornecem controle granular sobre a descoberta e a priorização.

Forçando a Descoberta Antecipada com <link rel="preload">

O <link rel="preload"> não é um hint; é uma diretiva. Ele força o navegador a baixar um recurso com alta prioridade, mesmo que ele ainda não seja detectável pelo parser principal. Colocá-lo no <head> do seu HTML é a maneira mais direta de corrigir problemas de descoberta tardia para recursos como fontes, background-images do CSS ou imagens do LCP localizadas profundamente no DOM. Para detalhes de implementação completos e exemplos, consulte nosso guia dedicado sobre como fazer o preload da imagem do LCP.

Mecanismo

Quando um link de preload é colocado no <head> do documento HTML, o preload scanner o identifica e coloca o recurso especificado imediatamente na fila para download. Isso é ideal para recursos como fontes carregadas via @font-face em uma folha de estilo externa, LCPs com background-image em CSS (embora o uso de uma tag <img> seja preferido) ou uma imagem do LCP que esteja localizada profundamente em uma estrutura DOM complexa.

Preload Responsivo

Um detalhe crítico de implementação é necessário ao fazer preload de imagens responsivas. Para garantir que o navegador faça o preload da imagem no tamanho correto para a viewport do usuário e evite um desperdício de download duplo, a tag <link rel="preload"> deve incluir os atributos imagesrcset e imagesizes que espelhem perfeitamente os atributos da tag <img> correspondente.

Exemplo de Preload Responsivo:

<link rel="preload" as="image"
      href="lcp-image-large.jpg"
      imagesrcset="lcp-image-small.jpg 400w, lcp-image-medium.jpg 800w, lcp-image-large.jpg 1200w"
      imagesizes="(max-width: 600px) 400px, (max-width: 1200px) 800px, 1200px"
      fetchpriority="high">

<img src="lcp-image-large.jpg"
     srcset="lcp-image-small.jpg 400w, lcp-image-medium.jpg 800w, lcp-image-large.jpg 1200w"
     sizes="(max-width: 600px) 400px, (max-width: 1200px) 800px, 1200px"
     alt="A descriptive alt text"
     fetchpriority="high"
     width="1200" height="675">
    

Potencial Armadilha

O preload resolve o timing de busca (Load Delay e Load Duration), mas não o timing de pintura. Se a main thread estiver bloqueada por JavaScript pesado ou CSS render blocking quando a imagem do preload chegar, a imagem ainda terá que esperar para ser renderizada, o que pode transferir o gargalo de Load Delay para Element Render Delay.

fetchpriority="high" e a Fila de Prioridade do Navegador

O atributo fetchpriority é um hint que sinaliza a importância relativa do download de um recurso. Ele permite que você influencie a prioridade de um recurso dentro da fila de download do navegador.

Como a Prioridade do Navegador Funciona

Quando o navegador descobre recursos durante o carregamento da página, ele atribui a cada um deles um nível de prioridade interna. Por padrão, imagens na viewport começam com prioridade "Baixa" e são depois promovidas para "Alta" assim que o navegador conclui o layout e determina que elas estão visíveis. Essa promoção exige que o navegador baixe e faça o parse do CSS primeiro, o que cria um atraso. O atributo fetchpriority="high" ignora esse processo completamente, definindo a imagem com prioridade "Alta" a partir do momento em que é descoberta. Isso é especialmente impactante para imagens do LCP porque elimina o atraso da promoção de prioridade.

preload vs. fetchpriority

Esses dois hints servem propósitos diferentes, mas complementares. O preload afeta quando um recurso é descoberto e adicionado à fila. O fetchpriority afeta seu nível de prioridade uma vez que ele está na fila. Entender essa distinção é crítico: o preload resolve a descoberta tardia, enquanto o fetchpriority resolve a priorização baixa. Para muitas imagens do LCP que já estão no HTML, apenas o fetchpriority pode ser suficiente. Para um guia completo sobre como eles interagem, consulte nosso artigo sobre priorização de recursos.

Melhor Prática para o LCP

Para a imagem do LCP, a estratégia ideal é usá-los juntos. Primeiro, garanta a descoberta antecipada posicionando a tag <img> no início do HTML ou usando o preload. Segundo, adicione fetchpriority="high" diretamente à tag <img> (e ao link de preload, se usado). Essa combinação garante que o recurso não seja apenas descoberto cedo, mas também receba a prioridade mais alta possível para vencer a competição por largura de banda da rede contra outros recursos como planilhas de estilo ou fontes.

Exemplo:

<img src="lcp-image.jpg" fetchpriority="high" alt="A critical hero image">

Quando Usar fetchpriority="low"

O atributo fetchpriority não serve apenas para aumentar a prioridade. Você também pode usar fetchpriority="low" para despriorizar recursos não críticos que competem por largura de banda com a imagem do LCP. Candidatos comuns incluem imagens above-the-fold que não são o elemento do LCP (como pequenos ícones ou avatares no cabeçalho) e recursos em preload que são necessários, mas não urgentes. Ao reduzir explicitamente a prioridade desses recursos concorrentes, você cria mais espaço na largura de banda para a imagem do LCP.

<!-- LCP image: high priority -->
<img src="hero.jpg" fetchpriority="high" alt="Hero image" width="1200" height="600">

<!-- Non-critical above-fold image: low priority -->
<img src="avatar.jpg" fetchpriority="low" alt="Author avatar" width="48" height="48">

Impacto Comprovado

Em um estudo de caso envolvendo o Google Flights, adicionar fetchpriority="high" à imagem de background do LCP melhorou o LCP de 2,6 segundos para 1,9 segundos, uma melhoria de 700 ms.

Otimizando Conexões de Terceiros: preconnect e dns-prefetch

O Problema

Se o seu recurso do LCP estiver hospedado em um domínio de terceiros, como uma CDN de imagens ou um provedor de fontes como o Google Fonts, o navegador deve estabelecer uma nova conexão de rede com esse domínio. Esse processo envolve um DNS lookup, um handshake TCP e uma negociação TLS, os quais devem ser concluídos antes que o primeiro byte do recurso possa ser baixado. Esse tempo de configuração de conexão contribui diretamente para o Resource Load Delay em recursos cross-origin.

As Soluções

• preconnect: Esse hint instrui o navegador a executar a configuração completa da conexão (DNS, TCP e TLS) para uma origem de terceiros especificada em segundo plano, com antecedência. Quando o recurso for realmente solicitado, a conexão já estará quente, eliminando a latência de configuração. Isso é altamente eficaz e recomendado para os domínios de terceiros mais críticos que fornecem recursos do LCP.
• dns-prefetch: Esse é um hint mais leve que executa apenas o DNS lookup para um domínio. Ele economiza menos tempo que o preconnect, mas tem um suporte de navegadores mais amplo e é útil como fallback ou para domínios de terceiros menos críticos.

Melhor Prática de Implementação

Para garantir a máxima compatibilidade, forneça os dois hints. O navegador usará o preconnect se suportado e fará o fallback para dns-prefetch caso não. O atributo crossorigin é essencial para recursos buscados usando CORS, como fontes.

<link rel="preconnect" href="https://my-image-cdn.com" crossorigin>
<link rel="dns-prefetch" href="https://my-image-cdn.com">

<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>    

Tabela: Comparação de Resource Hints para Otimização de LCP

Para evitar o uso indevido e esclarecer as funções distintas desses hints poderosos, a tabela a seguir fornece um resumo comparativo.

Estratégias Holísticas e Focadas no Futuro

Além dos resource hints, decisões de arquitetura mais amplas podem reduzir o Resource Load Delay ainda mais.

O Papel de uma CDN Moderna

Uma Content Delivery Network (CDN) é uma tecnologia fundamental para a performance web que reduz o Resource Load Delay indiretamente, mas significativamente, especialmente para recursos do LCP.

• Reduzindo o Overhead de Conexão: Ao distribuir ativos por uma rede global de servidores, uma CDN coloca o conteúdo geograficamente mais perto do usuário. Isso reduz inerentemente o tempo de ida e volta (RTT) necessário para o DNS lookup, handshake TCP e negociação TLS, que são todos componentes do tempo de configuração da conexão. Para uma imagem do LCP hospedada em uma CDN, isso reduz diretamente o seu Load Delay.
• CDNs de Imagem: CDNs especializadas em imagens oferecem um benefício duplo. Elas fornecem a vantagem de proximidade de uma CDN padrão, além de automatizar diversas otimizações complexas que reduzem o Resource Load Duration, como redimensionamento de imagem on-the-fly, compressão e conversão para formatos modernos como AVIF e WebP.
• Protocolos Avançados: Muitas CDNs modernas usam o HTTP/3, que usa QUIC no lugar de TCP. O HTTP/3 reduz o tempo de configuração de conexão e mitiga o bloqueio head-of-line, resultando em uma entrega de recursos mais rápida e eficiente no geral.

Eliminando o Atraso Totalmente com as Speculation Rules

A Speculation Rules API pode eliminar o atraso do LCP completamente em navegações subsequentes.

Mecanismo

Essa API permite que desenvolvedores informem declarativamente o navegador sobre quais URLs o usuário tem maior probabilidade de acessar a seguir. Com base nessas regras, o navegador pode escolher pré-renderizar uma página de destino em uma aba oculta em segundo plano antes mesmo que o usuário clique no link.

Impacto no LCP

Quando o usuário clica em um link para uma página pré-renderizada, a navegação é virtualmente instantânea. A página já foi totalmente carregada e renderizada em segundo plano. Para essa navegação, o TTFB, o Resource Load Delay, o Resource Load Duration e o Element Render Delay são efetivamente reduzidos para quase zero na perspectiva do usuário.

Exemplo de Caso de Uso

Em uma página de categoria de e-commerce, as Speculation Rules poderiam ser usadas para pré-renderizar as páginas de detalhes dos primeiros produtos da lista. Quando um usuário clica em um desses produtos, a página aparece instantaneamente.

Síntese de Estudo de Caso: Da Teoria à Prática

Essas otimizações têm impacto mensurável no mundo real.

• Caso 1: O Poder Transformador do Preload: Um experimento conduzido pelo DebugBear em uma página com alto Load Delay fornece um exemplo drástico. A imagem do LCP estava oculta em uma cadeia de solicitações, fazendo com que o Resource Load Delay representasse impressionantes 75% do tempo total do LCP. Ao implementar um único hint <link rel="preload"> para tornar a imagem detectável cedo, o Resource Load Delay foi reduzido para apenas 2% do tempo do LCP. Isso mostra como uma simples correção de arquitetura pode resolver um enorme gargalo de performance.
• Caso 2: O Anti-Pattern do loading="lazy" no Mundo Real: Um desenvolvedor no Stack Overflow relatou um LCP no desktop com um incompreensível Load Delay de 1.430 ms, apesar de uma rede rápida. A causa foi rastreada até um plugin de otimização de imagem que estava aplicando incorretamente o lazy loading à imagem do LCP, substituindo seu atributo src por um SVG transparente como placeholder. A solução definitiva foi desabilitar esse comportamento para o elemento do LCP, permitindo que ele fosse descoberto e carregado imediatamente (eagerly). Isso ilustra como ferramentas de terceiros podem introduzir inadvertidamente atrasos severos de carregamento.
• Caso 3: O Aumento de Performance do fetchpriority: O estudo de caso do Google Flights fornece evidências claras do impacto da priorização explícita. Ao simplesmente adicionar fetchpriority="high" à imagem de background do LCP da página, a pontuação do LCP melhorou em 700 ms, caindo de 2,6 segundos para 1,9 segundos. Isso demonstra que, mesmo quando um recurso é detectável, sinalizar sua alta importância para o navegador é um passo crítico para vencer a corrida por largura de banda da rede.

Inspeção de Rede no Chrome DevTools: Use o atalho Ctrl + Shift + I para abrir o Developer Tools do Chrome, selecione a aba "Network" e recarregue a página. Observe a sequência de carregamento. O seu recurso do LCP deve ser um dos primeiros itens na fila para download. Se ele estiver ficando atrás de outros elementos, há um problema de Resource Load Delay. Abaixo está um exemplo de um site onde o Resource Load Delay não foi otimizado.

Use Dados de Real User Monitoring (RUM): Ferramentas de Real User Monitoring geralmente registram dados de atribuição do LCP. Com RUM, você pode visualizar o detalhamento das subpartes do LCP (ao longo do tempo ou por página), fornecendo uma visão clara do Load Delay para elementos do LCP em todo o seu site ou por página. O exemplo abaixo mostra um detalhamento global do LCP junto com o Load Delay correspondente.

Como Melhorar o Load Delay

Um Resource Load Delay acontece quando a ordem de download e o tempo dos recursos não são ideais. Existem, essencialmente, duas maneiras diretas de corrigir isso: priorizar o recurso do LCP ou despriorizar os recursos não LCP. Vamos explorar alguns padrões comuns:

Dica do LCP: Entenda o Preload Scanner: Navegadores modernos usam um mecanismo chamado preload scanner, que faz o scan rápido do HTML e coloca recursos na fila para download. Se um recurso não puder ser colocado na fila pelo preload scanner, ele terá que esperar pelo parser do DOM que é mais lento, resultando em atrasos. Garantir que seus recursos do LCP sejam detectáveis pelo preload scanner pode fazer uma grande diferença na redução do Load Delay.

1. Otimize a Estrutura HTML

O navegador (ou o preload scanner) processa o seu HTML de cima para baixo, colocando os recursos na fila na ordem em que aparecem. Isso significa que quanto mais alto o recurso do LCP aparecer no HTML, mais cedo ele será colocado na fila. Para otimizar isso, remova ou adie os recursos desnecessários do topo do HTML:

• Use Lazy Loading em Imagens Sem Importância ou Ocultas: Às vezes as imagens (por exemplo, bandeiras para versões de idioma específicas do seu site ou imagens no menu) ficam no topo do HTML do seu site. Essas imagens não são tão importantes quanto o elemento do LCP. Ao usar o lazy loading nessas imagens, o preload scanner as ignora e elas são colocadas na fila um pouco mais tarde durante o processo de carregamento.
• Mova scripts sem importância para o final da página: Mova scripts que não são importantes para o carregamento inicial para o final da página para impedir que atrasem recursos críticos. Por exemplo, um widget de chat. Ninguém na história da internet precisou conversar antes que a página ficasse visível!

2. Evite Background Images

Background images são invisíveis para o preload scanner, o que significa que sempre serão colocadas na fila pelo parser do DOM, que é muito mais lento. Para evitar esse atraso, use uma tag <img> normal em vez disso, combinada com a propriedade CSS object-fit: cover para imitar a aparência de uma background image. Desta forma, o preload scanner pode detectar e colocar a imagem na fila imediatamente.

3. Use Fetch Priority

Adicione o atributo fetchpriority="high" ao seu elemento do LCP para sugerir ao navegador que ele deve priorizar esse recurso desde o início. Normalmente, as imagens carregam com uma prioridade padrão baixa ou média. Durante a fase de layout, o navegador promove os elementos visíveis para alta prioridade. Ao definir fetchpriority="high", o download começa imediatamente com alta prioridade, garantindo um LCP mais rápido.

O fetchpriority geralmente é menos intrusivo (e menos eficaz) do que o preload porque ele define a prioridade relativa de um elemento (neste caso, a imagem é relativamente mais importante que outras imagens), mas não a torna mais importante do que planilhas de estilo ou scripts não bloqueantes.

<img src="hero-image.jpg" alt="Hero Image" fetchpriority="high">

4. Implemente Preload

O preload altera a ordem em que o preload scanner coloca arquivos na fila. Coloque a tag <link rel="preload"> na tag head da página para instruir o navegador a buscar recursos críticos, como a imagem do LCP, o mais cedo possível. Preloads podem ser usados para fazer o preload de recursos que são referenciados mais adiante no HTML (e portanto, são colocados na fila mais tarde) ou até mesmo fazer o preload de recursos que ainda não estão referenciados no HTML (como em alguns sliders). Para máxima eficácia, é recomendado colocar os preloads após as planilhas de estilo e antes dos scripts na head da página.

<link rel="preload" as="image" href="hero-image.jpg">

5. Otimize Estilos

As planilhas de estilo (CSS) normalmente entram na fila antes do recurso do LCP e com razão. Sem planilhas de estilo, o navegador não saberá a aparência da página e não poderá iniciar a fase de renderização. No entanto, um tamanho excessivo de CSS e um número excessivo de planilhas de estilo irão competir com o recurso do LCP por largura de banda inicial.

6. Implemente um Lazy Loading Eficiente

O atributo loading pode ser uma faca de dois gumes. Use loading="eager" (ou simplesmente omita o atributo, já que "eager" é o padrão do navegador) para o seu recurso do LCP, enquanto aplica loading="lazy" para imagens fora da tela.

• Faça o Eager Load do Elemento do LCP: Se o elemento do LCP usar lazy loading, não será colocado na fila pelo preload scanner e o carregamento ocorrerá muito mais tarde, impactando negativamente a performance.
• Use Lazy Loading em Imagens da Viewport: Para imagens na viewport visível que não são recursos do LCP, use loading="lazy" para que entrem na fila de download um pouco depois. Isso reduz a competição por largura de banda com o recurso do LCP.
• Evite Lazy Loading em Imagens Fora da Tela: Imagens que não estão na viewport visível não irão acionar um download de forma alguma, eliminando completamente a competição por largura de banda.

7. Browser Caching

O browser caching permite que você pule solicitações de rede para recursos que já foram armazenados localmente no dispositivo do usuário. Embora não acelere a primeira visualização de página, ele vai melhorar os tempos de carregamento para pageviews subsequentes e visitantes retornando. Veja como o browser caching ajuda com o Resource Load Delay:

• Faça Cache de Recursos Concorrentes: Embora fazer cache do próprio recurso do LCP seja uma ótima estratégia, o browser caching melhora os Resource Load Delays do LCP armazenando recursos de rede que podem competir ou atrasar o recurso do LCP, como scripts, planilhas de estilo e imagens.
• Reduza a Carga do Servidor: O cache diminui o número de solicitações enviadas ao seu servidor, o que pode melhorar a performance de outros recursos liberando largura de banda e reduzindo os ciclos de CPU do servidor.

8. Use Speculation Rules

A Speculation Rules permite que navegadores façam prefetch ou prerender de páginas web com base na navegação prevista do usuário. O prefetch elimina efetivamente a subparte de Time to First Byte do LCP e não tem nenhum impacto sobre o Resource Load Delay. O prerender renderiza a próxima página em uma aba oculta e baixa todos os recursos da página. Isso elimina todos os atrasos de carregamento do elemento do LCP, como mostrado neste detalhamento de LCP de exemplo de uma página pré-renderizada.

9. Evite Client-Side Rendering

Próximos Passos: Continue Otimizando o LCP

O Resource Load Delay é uma das quatro fases do LCP. Uma vez que você minimizou a latência de descoberta, continue com estes guias:

• Corrija &amp;amp; Identifique Problemas do LCP: A metodologia de diagnóstico completa para encontrar e corrigir todos os problemas do LCP.
• Otimize a Imagem do LCP: Seleção de formato de imagem, imagens responsivas, preload e erros comuns de imagem.
• Resource Load Duration: Depois que o navegador descobre o recurso, reduza o tempo que leva para fazer o download por meio de compressão, formatos modernos e otimização de CDN.
• Element Render Delay: Após o download do recurso, garanta que o navegador possa pintá-lo imediatamente limpando a main thread.