Otimize o Resource Load Delay do LCP

Este guia faz parte do hub do Largest Contentful Paint (LCP). O Resource Load Delay é frequentemente o maior contribuinte para uma pontuação ruim de LCP. A maioria das equipes foca em comprimir imagens quando o verdadeiro problema é que o navegador encontrou a imagem tarde demais.

Otimize o Resource Load Delay do LCP

O Largest Contentful Paint (LCP) é composto por quatro fases: TTFB, Resource Load Delay, Resource Load Duration e Element Render Delay. Os esforços de desenvolvimento frequentemente focam em reduzir a duração do carregamento (Load Duration) através da compressão de arquivos, mas isso ignora o atraso no carregamento de recursos (Resource Load Delay), que é frequentemente uma fonte maior de latência. Esse atraso antes do início do download pode adicionar centenas de milissegundos ao seu LCP, fazendo com que exceda o limite de 2,5 segundos para 'Bom'.

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

Definição Precisa: A Espera Crítica Antes do Download

O Resource Load Delay é o tempo entre o TTFB e quando o navegador inicia o download do recurso do LCP. Não é o tempo de download; é a latência de descoberta que ocorre antes do início da busca. Um valor alto aqui indica um problema arquitetural onde o navegador não consegue encontrar a URL do recurso no payload HTML inicial. Esse atraso no carregamento de recursos pode ser visto como o tempo que o navegador gasta identificando que o recurso do LCP é necessário e decidindo buscá-lo.

Para elementos do LCP que são baseados em texto e renderizados usando uma fonte do sistema, esse resource load delay é tipicamente zero porque nenhum recurso externo precisa ser buscado. Valores mais altos de atraso no carregamento de recursos são específicos para elementos do LCP que dependem de um recurso de rede externo, como uma imagem ou um arquivo de vídeo.

O Motor de Descoberta: Preload Scanner vs. DOM Parser

Para reduzir o Resource Load Delay, você precisa entender como os navegadores descobrem recursos. A eficiência desse processo de descoberta é o fator principal que determina a latência. Os navegadores usam dois mecanismos: um caminho rápido e um caminho lento.

• O Preload Scanner (O Caminho Rápido): Este é um parser secundário de alta velocidade que escaneia o HTML bruto em busca de URLs de recursos, como aquelas nas tags <img> ou <link>. Ele as coloca na fila para download imediatamente, antes que o CSS seja analisado ou o JavaScript seja executado. Este é o caminho ideal para qualquer recurso crítico.
• O DOM Parser (O Caminho Lento): Este é o parser principal que constrói o Document Object Model (DOM) e o CSS Object Model (CSSOM) completos. Recursos não encontrados no HTML inicial, como um background-image do CSS ou um elemento injetado por JavaScript, são descobertos apenas por este parser. Este é o caminho lento porque depende de outros arquivos sendo baixados e executados primeiro, criando uma cadeia de dependências que introduz alta latência.

Toda a estratégia para otimizar o Resource Load Delay baseia-se em um princípio: garantir que a URL do recurso do LCP seja descobrível pelo preload scanner. Qualquer padrão que esconda a URL do documento HTML inicial força o navegador a usar o caminho de descoberta lento. Esse período de espera se traduz diretamente no Resource Load Delay. Toda otimização eficaz trata de arquitetar seu HTML para colocar o recurso do LCP no caminho rápido. Para um guia completo sobre a priorização de recursos do navegador, veja nosso artigo sobre priorização de recursos.

Por Que o Atraso no Carregamento Importa

Um equívoco comum é achar que um LCP lento é um problema de "tamanho de arquivo". Isso leva as equipes a focarem apenas na compressão de imagens para reduzir a Duração do Carregamento do Recurso (Resource Load Duration). Embora a otimização de assets seja um fator, a análise de dados de campo do mundo real mostra que, para muitos sites com LCP ruim, o Resource Load Delay é o principal gargalo de performance, e não o Resource Load Duration.

Dados de campo mostram que o site mediano com uma pontuação ruim de LCP tem um Resource Load Delay de 1,3 segundos. Isso é mais da metade de todo o orçamento de 2,5 segundos para uma pontuação 'Boa' de LCP, totalmente consumido antes mesmo que o download do recurso do LCP comece. Os dados indicam que esses sites passam quase quatro vezes mais tempo esperando o download começar do que gastam no próprio download.

Esses dados expõem um desvio frequente no esforço de desenvolvimento. As equipes podem passar semanas removendo kilobytes de imagens para encurtar o Load Duration em alguns milissegundos, enquanto um problema de arquitetura causando um Load Delay de 1,5 segundos permanece sem solução. O LCP é um processo sequencial; um atraso em uma fase inicial não pode ser recuperado otimizando uma fase posterior. Se uma busca é atrasada em mais de um segundo, uma diferença de 100ms no tempo de download é irrelevante para a pontuação final do LCP. As otimizações de maior impacto envolvem mudanças arquiteturais, como melhorar a capacidade de descoberta dos recursos, e não apenas a compressão de assets. O foco deve mudar de tornar os assets menores para garantir que sejam descobertos mais cedo.

Como Detectar o Resource Load Delay

Para consertar o Resource Load Delay, primeiro você tem que medi-lo com precisão. O fluxo de trabalho profissional é primeiro definir o problema com dados reais de usuários (RUM), e só então passar para o Chrome DevTools para uma análise profunda.

Passo 1: Analisar os Dados de Campo (RUM)

Os dados de campo, ou Real User Monitoring (RUM), são coletados de sessões de usuários reais. Ferramentas de RUM, como o relatório público Chrome User Experience Report (CrUX) ou a minha própria ferramenta, o CoreDash, respondem à pergunta: O que está acontecendo no mundo real? Uma ferramenta de RUM completa também fornecerá um detalhamento das subpartes do LCP, mostrando o Resource Load Delay mediano entre os seus usuários. Esses dados validam que existe um problema de LCP, mostram quais URLs são afetadas e revelam os elementos comuns do LCP que seus usuários estão realmente vendo. Você deve começar por aqui para confirmar que está resolvendo um problema real.

Passo 2: Diagnosticar com o DevTools

Uma vez que os seus dados de RUM identificaram uma página alvo e um elemento de 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 é o lugar onde você realiza uma Análise da Thread Principal para ver exatamente quais tarefas estão em execução e possivelmente bloqueando o processo de renderização.

Um Guia Passo a Passo para o Painel de Performance do Chrome DevTools

O painel de Performance no Chrome DevTools é uma ferramenta indispensável para dissecar o LCP e quantificar o atraso no carregamento.

1. Configuração e Ajustes:

• Abra o Chrome DevTools clicando com o botão direito na página e selecionando "Inspecionar" ou usando o atalho Ctrl+Shift+I (Windows/Linux) ou Cmd+Option+I (Mac).
• Navegue até a aba Performance.
• Garanta que a caixa de seleção Web Vitals esteja ativada nas configurações de captura. Isso irá sobrepor as informações do Core Web Vitals na linha do tempo de performance.
• Para simular condições realistas de usuário, aplique o throttling de CPU e de Rede. Uma "desaceleração de 4x" (4x slowdown) para a CPU e um perfil de rede "Fast 3G" ou "Slow 4G" são pontos de partida comuns para testes em dispositivos móveis.

2. Gravando um Perfil de Performance:

• Clique no botão "Gravar e recarregar a página" (um ícone de seta circular) no painel de Performance. Isso iniciará uma gravação, recarregará a página e, em seguida, interromperá a gravação assim que a página estiver totalmente carregada.

3. Análise e Interpretação:

• Trilha de Timings: Na visualização principal da linha do tempo, localize a trilha de Timings. Você verá um marcador rotulado LCP. Passar o mouse sobre este marcador destacará o elemento do LCP correspondente na captura de tela da viewport principal e exibirá o tempo total do LCP.
• Detalhamento do LCP por Fase: Clique no marcador do LCP na trilha de Timings. Na aba Summary (Resumo) na parte inferior do painel, você encontrará um detalhamento do tempo do LCP. Este detalhamento mostra explicitamente a duração de cada uma das quatro subpartes, incluindo o Load delay, medido em milissegundos. Este valor é a medição mais direta e precisa do Resource Load Delay para aquele carregamento de página específico.
• Análise da Thread Principal: Ao examinar a linha do tempo, observe a trilha Main em busca de quaisquer tarefas longas (blocos de atividade sinalizados com um triângulo vermelho). Se essas tarefas longas ocorrerem depois que o recurso do LCP terminar de carregar, mas antes do marcador LCP, elas provavelmente estão contribuindo para o Element Render Delay, um problema relacionado, mas distinto.

Causas Comuns e Soluções de Alto Impacto

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

Causa: LCP Carregado via CSS

O Problema: O preload scanner não faz o parse de arquivos CSS. Quando a sua imagem do LCP é definida com um background-image do CSS, a URL dela 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 Resource Load Delay alto. Para mais informações sobre esse padrão, veja nosso guia sobre como adiar background images.

A Solução: A implementação correta é evitar o uso de background-image para qualquer elemento crítico do LCP. Em vez disso, use uma tag <img> padrão. 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:

Antipadrão (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 */
    }
    

Esta implementação fornece o mesmo resultado visual, mas torna a imagem do LCP descobrível no momento mais cedo possível, o que minimiza seu atraso no carregamento.

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

O Problema: Aplicações que usam frameworks de renderização no lado do cliente (CSR), como React ou Vue, frequentemente entregam um shell HTML mínimo. O conteúdo real, incluindo a tag <img> do LCP, só é inserido no DOM pelo JavaScript depois que grandes pacotes do framework são baixados, analisados e executados. Esse processo fundamentalmente esconde 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.

• Server-Side Rendering (SSR) ou Static Site Generation (SSG): Padrões arquiteturais 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 descobrível pelo preload scanner. Esta é a arquitetura necessária para qualquer página crítica para performance.
• Otimizações Específicas de Frameworks: 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: Usar loading="lazy" na Imagem do LCP

O Problema: Este é 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 abaixo da dobra, aplicá-la a um elemento de LCP acima da dobra é contraproducente. O preload scanner do navegador foi projetado para ignorar imagens com loading="lazy", o que garante uma descoberta tardia e um Resource Load Delay alto.

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

• Remova o loading="lazy" da Imagem do LCP: Qualquer imagem que provavelmente seja 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 acima da dobra. Omitir totalmente o atributo de carregamento tem o mesmo efeito.
• Auditar e Configurar Ferramentas de Terceiros: Você também deve auditar ferramentas de terceiros. Muitas plataformas CMS como o WordPress e vários plugins de otimização de imagens aplicam automaticamente o lazy loading a todas as imagens. É essencial configurar essas ferramentas para excluir a imagem do LCP desse comportamento. Isso geralmente envolve a criação de uma regra de exclusão para a primeira ou as duas primeiras imagens da 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 exigem 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 para 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 fragmento de dados que o navegador recebe (cerca de 14KB), sua descoberta é atrasada por pelo menos uma ida e volta na rede.

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

• Reordene o HTML: Quando possível, certifique-se de que a tag <img> ou o bloco de texto para o elemento do LCP apareça o mais cedo que você puder colocá-lo dentro da tag <body>.
• Despriorize Imagens Não Críticas: Para imagens não essenciais que devem 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 análises, anúncios ou widgets de mídias 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 pela largura de banda da rede com o recurso do LCP.

Priorização Avançada com Resource Hints

Uma vez que o recurso do LCP seja descobrível no HTML, você pode usar resource hints (dicas de recursos) para dar ao navegador instruções mais explícitas sobre como buscá-lo. Essas dicas fornecem um controle refinado sobre a descoberta e a priorização.

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

O <link rel="preload"> não é uma dica; é uma diretiva. Ele força o navegador a baixar um recurso com alta prioridade, mesmo se ele ainda não for descobrí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 de LCP localizadas profundamente no DOM. Para detalhes completos de implementação e exemplos, veja nosso guia dedicado sobre como fazer o preload da imagem do LCP.

Mecanismo

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

Preload Responsivo

Um detalhe de implementação crítico é necessário ao fazer o 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 download duplo desnecessário, a tag <link rel="preload"> deve incluir os atributos imagesrcset e imagesizes que espelham perfeitamente os atributos na 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">
    

Armadilha Potencial

O preload resolve o tempo de busca (Load Delay e Load Duration), mas não o tempo de pintura (paint timing). Se a thread principal estiver bloqueada por JavaScript pesado ou CSS que bloqueia a renderização quando a imagem em preload chegar, a imagem ainda terá que esperar para ser renderizada, o que pode mudar o gargalo de Load Delay para Element Render Delay.

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

O atributo fetchpriority é uma dica 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 um nível de prioridade interno. Por padrão, imagens na viewport começam com prioridade "Baixa" e depois são atualizadas para "Alta" assim que o navegador conclui o layout e determina que elas são visíveis. Essa atualização exige que o navegador baixe e analise o CSS primeiro, o que cria um atraso. O atributo fetchpriority="high" ignora esse processo completamente, definindo a imagem para a prioridade "Alta" a partir do momento em que é descoberta. Isso é especialmente impactante para imagens do LCP porque elimina o atraso na atualização da prioridade.

preload vs. fetchpriority

Estas duas dicas servem a propósitos diferentes, mas complementares. O preload afeta quando um recurso é descoberto e adicionado à fila. O fetchpriority afeta o seu nível de prioridade uma vez que ele já está na fila. Entender essa distinção é crítico: o preload resolve a descoberta tardia, enquanto o fetchpriority resolve a baixa priorização. Para muitas imagens do LCP que já estão no HTML, apenas o fetchpriority pode ser suficiente. Para um guia completo sobre como esses dois interagem, veja 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 uma descoberta antecipada, seja colocando 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 utilizado). 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 pela largura de banda da rede contra outros recursos, como folhas 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 acima da dobra 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" à background image do LCP melhorou o tempo do LCP de 2,6 segundos para 1,9 segundos, uma melhoria de 700ms.

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 um CDN de imagens ou um provedor de fontes como o Google Fonts, o navegador deve estabelecer uma nova conexão de rede para esse domínio. Esse processo envolve uma busca de DNS, um handshake TCP e uma negociação TLS, todos os quais devem ser concluídos antes que o primeiro byte do recurso possa ser baixado. Esse tempo de configuração da conexão é um contribuinte direto para o Resource Load Delay para assets cross-origin.

As Soluções

• preconnect: Essa dica 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 é realmente solicitado, a conexão já está quente, eliminando a latência da configuração. Isso é altamente eficaz e recomendado para os um ou dois domínios de terceiros mais críticos que servem os recursos do LCP.
• dns-prefetch: Essa é uma dica mais leve que realiza apenas a busca de DNS para um domínio. Economiza menos tempo do que o preconnect, mas tem um suporte mais amplo nos navegadores e é útil como um fallback ou para domínios de terceiros menos críticos.

Melhor Prática de Implementação

Para garantir compatibilidade máxima, forneça ambas as dicas. O navegador usará preconnect se suportado e fará o fallback para dns-prefetch se não for. O atributo crossorigin é essencial para recursos buscados usando CORS, como as 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 do LCP

Para evitar o uso indevido e esclarecer as funções distintas destas dicas poderosas, a tabela a seguir fornece um resumo comparativo.

Estratégias Holísticas e Orientadas para o Futuro

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

O Papel de um CDN Moderno

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

• Redução da Sobrecarga de Conexão: Ao distribuir os assets 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) exigido para a busca de DNS, 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 atraso de carregamento.
• CDNs de Imagem: CDNs de Imagem especializadas oferecem um duplo benefício. Elas fornecem a vantagem de proximidade de uma CDN padrão, enquanto também automatizam muitas 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 HTTP/3, que usa QUIC em vez de TCP. O HTTP/3 reduz o tempo de configuração da conexão e atenua o bloqueio head-of-line, levando a uma entrega de recursos mais rápida e eficiente no geral.

Eliminando Totalmente o Atraso com Speculation Rules

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

Mecanismo

Esta API permite que desenvolvedores informem declarativamente ao navegador sobre quais URLs é provável que um usuário navegue em seguida. Com base nestas regras, o navegador pode optar por fazer o prerender de uma página alvo 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 com prerender, 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 todos efetivamente reduzidos a quase zero na perspectiva do usuário.

Exemplo de Caso de Uso

Em uma página de categorias de e-commerce, as speculation rules poderiam ser usadas para fazer o prerender das páginas de detalhes de produtos para os primeiros itens da lista. Quando um usuário clicar em um desses produtos, a página aparecerá instantaneamente.

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

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

• Caso 1: O Poder Transformador do Preloading: Um experimento conduzido pelo DebugBear em uma página com um load delay alto fornece um exemplo dramático. A imagem do LCP estava escondida em uma cadeia de requisições, fazendo com que o Resource Load Delay representasse impressionantes 75% do tempo total do LCP. Ao implementar uma única dica <link rel="preload"> para tornar a imagem descobrível logo cedo, o Resource Load Delay foi reduzido a apenas 2% do tempo do LCP. Isso mostra como uma correção arquitetural simples pode solucionar um gargalo de performance massivo.
• Caso 2: O Antipadrão loading="lazy" no Mundo Real: Um desenvolvedor no Stack Overflow relatou um LCP em desktop com um atraso de carregamento surpreendente de 1.430ms, 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 o seu atributo src por um SVG placeholder transparente. A solução definitiva foi desativar este comportamento para o elemento do LCP, permitindo que ele fosse descoberto e carregado antecipadamente (eagerly). Isso ilustra como ferramentas de terceiros podem introduzir inadvertidamente atrasos severos no carregamento.
• Caso 3: O Impulso de Performance com fetchpriority: O estudo de caso do Google Flights fornece evidências claras sobre o impacto da priorização explícita. Ao simplesmente adicionar fetchpriority="high" à background image do LCP da página, a pontuação do LCP melhorou em 700ms, caindo de 2,6 segundos para 1,9 segundos. Isso demonstra que, mesmo quando um recurso é descobrível, sinalizar a sua alta importância ao navegador é um passo crítico para vencer a corrida pela 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, depois selecione a aba "Network" (Rede) e recarregue a página. Observe a sequência de carregamento. O seu recurso do LCP deve ser um dos primeiros itens colocados 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 atraso no carregamento do recurso não foi otimizado.

Use Dados de Real User Monitoring (RUM): Ferramentas de Real User Monitoring frequentemente registram dados de atribuição do LCP. Com o RUM, você pode visualizar o detalhamento das subpartes do LCP (ao longo do tempo ou por página), dando a você uma visão clara do atraso no carregamento para os elementos do LCP em todo o seu site ou por página. O exemplo abaixo mostra um detalhamento global do LCP junto com o respectivo load delay.

Como Melhorar o Load Delay

Um resource load delay acontece quando a ordem de download e o timing dos recursos não são ideais. Existem, em essência, duas formas diretas de corrigir isso: priorizar o recurso do LCP ou despriorizar recursos que não são do LCP. Vamos explorar alguns padrões comuns:

Dica de LCP: Entenda o Preload Scanner: Navegadores modernos usam um mecanismo chamado preload scanner, que escaneia o HTML rapidamente e enfileira recursos para download. Se um recurso não puder ser enfileirado pelo preload scanner, ele terá que esperar pelo parser DOM mais lento, resultando em atrasos. Garantir que os seus recursos do LCP sejam descobrí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, enfileirando recursos na ordem em que aparecem. Isso significa que quanto mais alto o recurso do LCP aparecer no HTML, mais cedo ele é colocado na fila. Para otimizar isso, remova ou adie recursos desnecessários do topo do HTML:

• Faça o Lazy-Load de Imagens sem Importância ou Ocultas: Às vezes as imagens (por exemplo, bandeiras para versões de idiomas específicos do seu site ou imagens no menu) são encontradas bem no topo do HTML do seu site. Estas imagens não são nem de perto tão importantes quanto o elemento do LCP. Ao fazer o lazy-loading destas imagens, elas são puladas pelo preload scanner e enfileiradas um pouco mais tarde durante o processo de carregamento.
• Mova scripts sem importância para a parte inferior da página: Mova os scripts que são absolutamente sem importância para o carregamento inicial para a parte inferior da página, a fim de evitar que eles atrasem os recursos críticos. Por exemplo, um widget de chat. Ninguém na história da internet já precisou conversar antes da página se tornar visível!

2. Evite Background Images

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

3. Use o Fetch Priority

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

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

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

4. Implemente o Preloading

O preloading altera a ordem na qual o preload scanner coloca os arquivos na fila. Coloque a tag <link rel="preload"> no head da página para instruir o navegador a buscar os 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 tarde no HTML (e portanto são enfileirados mais tarde) ou até mesmo para fazer o preload de recursos que ainda não estão referenciados no HTML (como ocorre com alguns sliders). Para efetividade máxima, é recomendado colocar os preloads depois das folhas de estilo e antes dos scripts no head da página.

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

5. Otimize os Estilos

As folhas de estilo são normalmente enfileiradas antes do recurso do LCP e isso acontece por um bom motivo. Sem folhas de estilo, o navegador não saberá como será a aparência da página e não pode iniciar a fase de renderização. No entanto, um tamanho de CSS excessivo e um número excessivo de folhas de estilo irão competir com o recurso do LCP pela 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.

• Carregamento Eager (Eager Load) no Elemento do LCP: Se o elemento do LCP for carregado de forma preguiçosa (lazy-loaded), ele não será enfileirado pelo preload scanner e carregará muito mais tarde, impactando negativamente a performance.
• Lazy-Load nas Imagens da Viewport: Para imagens que estão na viewport visível, mas que não são recursos do LCP, use loading="lazy" para enfileirá-las para download um pouco mais tarde. Isso reduz a competição de largura de banda com o recurso do LCP.
• Evite o Lazy Loading em Imagens Fora da Tela: Imagens que não estão na viewport visível não acionarão nenhum download, eliminando completamente a competição por largura de banda.

7. Cache do Navegador (Browser Caching)

O cache do navegador (browser caching) permite que você pule as requisições de rede para recursos que já foram armazenados localmente no dispositivo do usuário. Embora isso não acelere a primeira visualização de página, melhorará os tempos de carregamento para as visualizações de páginas subsequentes e para os visitantes que retornam. Veja como o cache do navegador ajuda no resource load delay:

• Recursos Concorrentes em Cache: Embora colocar o próprio recurso do LCP em cache seja uma ótima estratégia, o cache do navegador melhora os resource load delays do LCP armazenando os recursos de rede que podem competir com ou atrasar o recurso do LCP, como scripts, folhas de estilo e imagens.
• Reduza a Carga no Servidor: Fazer o cache diminui o número de requisiçõ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 API Speculation Rules permite que os navegadores façam o prefetch ou prerender de páginas web com base na previsão da navegação do usuário. O prefetching elimina efetivamente a subparte Time to First Byte do LCP e não tem impacto no resource load delay. O prerendering renderiza a próxima página em uma aba oculta e baixa todos os recursos da página. Isto elimina todos os load delays para o elemento do LCP, conforme mostrado neste exemplo de detalhamento do LCP de uma página com prerender.

9. Evite a Renderização no Lado do Cliente

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:

• Corrigir e Identificar Problemas de LCP: A metodologia de diagnóstico completa para encontrar e consertar todos os problemas de LCP.
• Otimizar a Imagem do LCP: Seleção de formato de imagem, imagens responsivas, preloading e erros comuns com imagens.
• Resource Load Duration: Depois que o navegador descobre o recurso, reduza o tempo que leva para baixá-lo através de compressão, formatos modernos e otimização de CDN.
• Element Render Delay: Depois que o recurso é baixado, garanta que o navegador possa pintá-lo imediatamente, limpando a thread principal.