Otimize o Resource Load Delay da LCP

Este guia faz parte da seção Largest Contentful Paint (LCP) do nosso centro de recursos Core Web Vitals. O Resource Load Delay é uma das quatro fases sequenciais da LCP e, frequentemente, é o maior contribuinte para uma pontuação ruim de LCP. Este artigo aborda as causas, diagnósticos e soluções em profundidade.

Otimize o Resource Load Delay da LCP

A Largest Contentful Paint (LCP) é composta por quatro fases: TTFB, Resource Load Delay, Resource Load Duration e Element Render Delay. Os esforços de desenvolvimento geralmente se concentram em reduzir o Load Duration por meio da compactação de arquivos, mas isso negligencia o Resource Load Delay, que costuma ser uma fonte maior de latência. Esse atraso antes do início do download pode adicionar centenas de milissegundos à sua LCP, fazendo com que ultrapasse o limite 'Bom' de 2,5 segundos.

Uma dica rápida: se a sua LCP for uma imagem, quase sempre será pior do que texto. Você deve rastrear os tipos de elemento LCP em seus dados RUM, caso contrário, 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 da LCP. Não é o tempo de download; é a latência de descoberta que ocorre antes do início do fetch. Um valor alto aqui indica um problema de arquitetura em que o navegador não consegue encontrar o URL do recurso no payload HTML inicial. Esse resource load delay pode ser visto como o tempo que o navegador gasta identificando que o recurso da LCP é necessário e decidindo buscá-lo.

Para elementos LCP baseados em texto e renderizados usando uma fonte do sistema, esse resource load delay geralmente é zero porque nenhum recurso externo precisa ser buscado. Valores mais altos de resource load delay são específicos para elementos 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 os recursos. A eficiência desse processo de descoberta é o principal fator 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 verifica o HTML bruto em busca de URLs de recursos, como aqueles em tags <img> ou <link>. Ele os enfileira 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 (Caminho Lento): Este é o parser principal que constrói o Document Object Model (DOM) completo e o CSS Object Model (CSSOM). Recursos não encontrados no HTML inicial, como um background-image no CSS ou um elemento injetado por JavaScript, só são descobertos por este parser. Este é o caminho lento porque depende do download e execução de outros arquivos 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 o URL do recurso da LCP seja detectável pelo preload scanner. Qualquer padrão que oculte o URL do documento HTML inicial força o navegador a usar o caminho de descoberta lento. Esse período de espera se traduz diretamente em Resource Load Delay. Toda otimização eficaz consiste em arquitetar seu HTML para colocar o recurso da LCP no caminho rápido. Para um guia completo sobre a priorização de recursos do navegador, consulte nosso artigo sobre priorização de recursos.

Por Que o Load Delay é Importante

Um equívoco comum é que uma LCP lenta é um problema de "tamanho de arquivo". Isso leva as equipes a se concentrarem apenas na compactação de imagens para reduzir o Resource Load Duration. Embora a otimização de ativos seja um fator, a análise de dados de campo reais mostra que para muitos sites com LCP ruim, o Resource Load Delay é o principal gargalo de desempenho, e não o Resource Load Duration.

Os 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, tudo consumido antes mesmo de o download do recurso da LCP começar. Os dados indicam que esses sites passam quase quatro vezes mais tempo esperando o início do download do que no próprio download.

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

Como Detectar o Resource Load Delay

Para corrigir o Resource Load Delay, primeiro você precisa medi-lo com precisão. O fluxo de trabalho profissional é primeiro definir o problema com dados reais do usuário (RUM) e só então passar para o Chrome DevTools para análises profundas.

Passo 1: Analisar os Dados de Campo (RUM)

Os dados de campo, ou Real User Monitoring (RUM), são coletados a partir de sessões reais de usuários. Ferramentas RUM, como o Chrome User Experience Report (CrUX) público ou a minha própria ferramenta, CoreDash, respondem à pergunta: O que está acontecendo no mundo real? Uma ferramenta RUM completa também fornecerá um detalhamento das subpartes da LCP, mostrando o Resource Load Delay mediano entre seus usuários. Esses dados validam a existência de um problema de LCP, mostram quais URLs são afetados e revelam os elementos LCP comuns 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

Depois que seus dados RUM identificarem uma página de destino e um elemento LCP, você usa o Chrome DevTools para diagnosticar a causa. O objetivo aqui é reproduzir o problema e medir as subpartes da LCP para obter um valor preciso de Resource Load Delay. O DevTools também é onde você realiza uma Main Thread Analysis 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 Desempenho do Chrome DevTools

O painel de Desempenho (Performance) no Chrome DevTools é uma ferramenta indispensável para dissecar a LCP e quantificar o load delay.

1. Instalação e Configuração:

• 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.
• Certifique-se de que a caixa de seleção Web Vitals esteja ativada nas configurações de captura. Isso sobreporá informações dos Core Web Vitals na linha do tempo de desempenho.
• Para simular condições realistas do usuário, aplique limitação de CPU e Rede (throttling). Uma "lentidão 4x" (4x slowdown) para a CPU e um perfil de rede "Fast 3G" ou "Slow 4G" são pontos de partida comuns para testes móveis.

2. Gravando um Perfil de Desempenho:

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

3. Análise e Interpretação:

• Trilha Timings: Na visualização principal da linha do tempo, localize a trilha Timings. Você verá um marcador rotulado como LCP. Passar o mouse sobre este marcador destacará o elemento LCP correspondente na captura de tela principal da janela de visualização e exibirá o tempo total da LCP.
• Detalhamento da LCP por Fase: Clique no marcador LCP na trilha Timings. Na aba Summary na parte inferior do painel, você encontrará um detalhamento dos tempos da LCP. Esse detalhamento mostra explicitamente a duração de cada uma das quatro subpartes, incluindo o Load delay, medido em milissegundos. Esse valor é a medida mais direta e precisa do Resource Load Delay para aquele carregamento de página específico.
• Main Thread Analysis: Ao examinar a linha do tempo, observe a trilha Main em busca de tarefas longas (long tasks - blocos de atividade sinalizados com um triângulo vermelho). Se essas tarefas longas ocorrerem após o término do carregamento do recurso da LCP, mas antes do marcador LCP, é provável que estejam 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 da LCP é descoberto tarde ou recebe uma fetch priority baixa. Aqui estão os erros de arquitetura mais comuns e suas soluções.

Causa: LCP Carregada via CSS

O Problema: O preload scanner não analisa arquivos CSS. Quando sua imagem LCP é definida com um background-image no CSS, o URL dela fica invisível para esse scanner de alta velocidade. O navegador só pode descobrir a imagem depois de 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 saber mais sobre esse padrão, consulte nosso guia sobre como adiar imagens de fundo.

A Solução: A implementação correta é evitar o uso de background-image para qualquer elemento crítico da LCP. Use uma tag <img> padrão em vez disso. Isso coloca o URL da imagem diretamente no HTML, onde o preload scanner pode encontrá-lo imediatamente. Você pode obter 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 da LCP detectável no momento mais inicial possível, o que minimiza seu load delay.

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

O Problema: Aplicativos que usam frameworks de renderização no lado do cliente (CSR), como React ou Vue, costumam servir um shell HTML mínimo. O conteúdo real, incluindo a tag <img> da LCP, só é inserido no DOM pelo JavaScript após o download, análise e execução de grandes pacotes do framework. Esse processo fundamentalmente oculta o recurso da LCP do preload scanner, criando 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 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 da LCP imediatamente detectável pelo preload scanner. Esta é a arquitetura necessária para qualquer página crítica de desempenho.
• Otimizações Específicas de Frameworks: Frameworks modernos também oferecem otimizações integradas. Por exemplo, o componente <Image> do Next.js possui uma propriedade priority. Definir isso como true instrui o framework a adicionar automaticamente os atributos corretos <link rel="preload"> e fetchpriority="high", garantindo que a imagem seja descoberta e buscada com a prioridade correta.

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

O Problema: Este é um erro frequente e de alto impacto. O atributo loading="lazy" é uma instrução direta ao navegador para atrasar a busca de uma imagem até que ela esteja próxima da janela de visualização (viewport). Embora essa seja a otimização correta para imagens abaixo da dobra (below-the-fold), aplicá-la a um elemento 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 requer diligência.

• Remova loading="lazy" da Imagem da LCP: Qualquer imagem que provavelmente seja o elemento 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.
• Audite e Configure Ferramentas de Terceiros: Você também deve auditar ferramentas de terceiros. Muitas plataformas de 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 da 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 Subideal 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 LCP, eles serão descobertos e enfileirados para download primeiro. Isso consome a largura de banda de rede inicial e pode atrasar o download do recurso da LCP. Um documento HTML grande também pode ser um problema; se o elemento LCP não estiver no primeiro bloco de dados que o navegador recebe (cerca de 14 KB), sua descoberta será atrasada por pelo menos uma viagem de ida e volta na rede (round trip).

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 LCP apareça o mais cedo possível dentro da tag <body>.
• Despriorize Imagens Não Críticas: Para imagens não essenciais que devem aparecer no início do 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 LCP.
• Adie Scripts Não Essenciais: Scripts de análises, 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 da LCP.

Priorização Avançada com Resource Hints

Assim que o recurso da LCP for 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 refinado sobre a descoberta e a priorização.

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

<link rel="preload"> não é um hint (dica); é uma diretiva. Ele força o navegador a baixar um recurso com alta prioridade, mesmo que 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 de recursos como fontes, imagens de fundo CSS ou imagens LCP localizadas profundamente no DOM. Para detalhes de implementação e exemplos completos, veja nosso guia dedicado sobre como fazer o preload da imagem da LCP.

Mecanismo

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

Preload Responsivo

Um detalhe crítico de implementação é 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 desperdício de download duplo, a tag <link rel="preload"> deve incluir os atributos imagesrcset e imagesizes que espelham perfeitamente os atributos na tag <img> correspondente.[4]

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 em Potencial

O preload resolve o tempo de busca (fetch timing) (Load Delay e Load Duration), mas não o *tempo de pintura (paint timing)*. Se a thread principal (main thread) 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 do Load Delay para o Element Render Delay.[5, 6]

Mergulho Profundo: fetchpriority="high" e a Fila de Prioridade do Navegador

O atributo fetchpriority é um hint (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.[7]

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, as imagens na viewport começam com prioridade "Baixa" e depois são atualizadas para "Alta" quando 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" contorna esse processo inteiramente, definindo a imagem com prioridade "Alta" a partir do momento em que é descoberta. Isso é especialmente impactante para imagens da LCP porque elimina o atraso da atualização de prioridade.

preload vs. fetchpriority

Esses dois hints servem a propósitos diferentes, mas complementares. O preload afeta quando um recurso é descoberto e adicionado à fila. O fetchpriority afeta seu nível de prioridade quando já está na fila. Entender essa distinção é fundamental: o preload resolve a descoberta tardia, enquanto o fetchpriority resolve a priorização baixa. Para muitas imagens da 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 LCP

Para a imagem da LCP, a estratégia ideal é usá-los juntos. Primeiro, garanta a descoberta inicial colocando a tag <img> no início do HTML ou usando o preload. Segundo, adicione fetchpriority="high" diretamente à tag <img> (e ao link preload, se usado). Essa combinação garante que o recurso não apenas seja 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.[3, 1, 7]

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 da LCP. Candidatos comuns incluem imagens acima da dobra que não são o elemento LCP (como pequenos ícones ou avatares no cabeçalho) e recursos preloaded que são necessários, mas não urgentes. Ao diminuir explicitamente a prioridade desses recursos concorrentes, você cria mais espaço na largura de banda para a imagem da 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, a adição de fetchpriority="high" à imagem de fundo da LCP da página foi fundamental para melhorar o tempo da LCP de 2,6 segundos para 1,9 segundos, uma melhoria de 700 ms.[8]

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

O Problema

Se o recurso da 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 deverá estabelecer uma nova conexão de rede com esse domínio. Esse processo envolve uma pesquisa 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 de conexão é um contribuidor direto para o Resource Load Delay para ativos cross-origin.[9, 2, 10, 11]

As Soluções

• preconnect: Este 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, antecipadamente. Quando o recurso é realmente solicitado, a conexão já está aquecida, eliminando a latência de configuração. Isso é altamente eficaz e recomendado para um ou dois domínios de terceiros mais críticos que servem recursos da LCP.[2]
• dns-prefetch: Este é um hint mais leve que executa apenas a pesquisa DNS para um domínio. Ele economiza menos tempo do que o preconnect, mas tem um suporte mais amplo do navegador e é útil como um fallback ou para domínios de terceiros menos críticos.[2, 12]

Melhor Prática de Implementação

Para garantir a máxima compatibilidade, forneça ambos os hints. O navegador usará preconnect se suportado e voltará para dns-prefetch se 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 da LCP

Para evitar o uso indevido e esclarecer os papéis distintos desses hints poderosos, a tabela a seguir fornece um resumo comparativo.

Estratégias Holísticas e Voltadas Para o Futuro

Além de hints direcionados, decisões arquitetônicas mais amplas e recursos emergentes da plataforma web podem fornecer soluções holísticas e poderosas para o Resource Load Delay.

O Papel de um CDN Moderno

Uma Content Delivery Network (CDN) é uma tecnologia fundamental para o desempenho da web que reduz o Resource Load Delay de forma indireta, mas significativa, especialmente para recursos da LCP.

• Reduzindo a Sobrecarga de Conexão: Ao distribuir ativos por uma rede global de servidores, uma CDN coloca o conteúdo geograficamente mais próximo do usuário. Isso reduz inerentemente o tempo de ida e volta (RTT) necessário para a pesquisa DNS, o handshake TCP e a negociação TLS, que são todos componentes do tempo de configuração da conexão.[13, 14, 15] Para uma imagem da LCP hospedada em uma CDN, isso reduz diretamente o load delay dela.
• CDNs de Imagens: CDNs de imagens especializadas oferecem um benefício duplo. 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 (em tempo real), compactação e conversão para formatos modernos como AVIF e WebP.[9, 1]
• Protocolos Avançados: Muitos CDNs modernos aproveitam protocolos de rede superiores como 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 no início da fila (head-of-line blocking), resultando em uma entrega de recursos mais rápida e eficiente no geral.[16]

Eliminando o Atraso Inteiramente com Speculation Rules

A Speculation Rules API é um recurso de ponta da plataforma web que oferece o potencial de eliminar o atraso da LCP inteiramente para navegações subsequentes.

Mecanismo

Essa API permite que os desenvolvedores informem declarativamente ao navegador sobre quais URLs um usuário provavelmente navegará em seguida. Com base nessas regras, o navegador pode optar por fazer o prerender de uma página de destino em uma aba oculta em segundo plano antes mesmo que o usuário clique no link.[3, 1, 16]

Impacto na LCP

Quando o usuário clica em um link para uma página em prerender, a navegação é praticamente 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 a quase zero do ponto de vista do usuário.[3, 1, 16]

Exemplo de Caso de Uso

Em uma página de categoria de comércio eletrônico, as speculation rules podem ser usadas para fazer o prerender das páginas de detalhes do produto para os primeiros itens da lista. Quando um usuário clica em um desses produtos, a página aparece instantaneamente, proporcionando uma experiência contínua e excepcionalmente rápida.

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

A eficácia dessas estratégias de otimização não é meramente teórica; ela é demonstrada por dados de testes e cenários do mundo real.

• Caso 1: O Poder Transformador do Preload: Um experimento conduzido por DebugBear em uma página com alto load delay fornece um exemplo dramático. A imagem da LCP estava escondida em uma cadeia de solicitações, fazendo com que o Resource Load Delay fosse responsável por impressionantes 75% do tempo total da LCP. Ao implementar um único hint <link rel="preload"> para tornar a imagem detectável mais cedo, o Resource Load Delay foi reduzido a apenas 2% do tempo da LCP.[17] Isso mostra como uma simples correção de arquitetura pode resolver um gargalo enorme de desempenho.
• Caso 2: O Antipadrão de loading="lazy" do Mundo Real: Um desenvolvedor no Stack Overflow relatou uma LCP em desktop com um load delay desconcertante 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 da LCP, substituindo seu atributo src por um placeholder SVG transparente. A solução definitiva foi desativar esse comportamento para o elemento LCP, permitindo que ele fosse descoberto e carregado com 'eager'.[18] Isso ilustra como ferramentas de terceiros podem inadvertidamente introduzir load delays graves.
• Caso 3: O Aumento de Desempenho do fetchpriority: O estudo de caso do Google Flights fornece evidências claras do impacto da priorização explícita. Apenas adicionando fetchpriority="high" à imagem de fundo da LCP da página, a pontuação da LCP melhorou em 700ms, caindo de 2,6 segundos para 1,9 segundos.[8] Isso demonstra que mesmo quando um recurso é detectável, sinalizar sua alta importância para o navegador é um passo fundamental 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 as Ferramentas do Desenvolvedor do Chrome, selecione a aba "Rede" (Network) e recarregue a página. Observe a sequência de carregamento. O recurso da sua LCP deve ser um dos primeiros itens enfileirados para download. Se ele estiver ficando para trá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.

Aproveite os Dados do Real User Monitoring (RUM): Ferramentas de Real User Monitoring frequentemente registram dados de atribuição da LCP. Com o RUM, você pode visualizar o detalhamento das subpartes da LCP (ao longo do tempo ou por página), dando a você uma visão clara do load delay para elementos LCP em todo o seu site ou por página. O exemplo abaixo mostra um detalhamento global da 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, em essência, duas maneiras diretas de corrigir isso: priorizar o recurso da LCP ou despriorizar recursos não-LCP. Vamos explorar alguns padrões comuns:

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

• Aplique Lazy-Load em Imagens Sem Importância ou Ocultas: Às vezes as imagens (por exemplo, bandeiras para versões específicas de idioma 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 LCP. Ao carregar essas imagens com lazy-loading, 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 scripts que são absolutamente sem importância para o carregamento inicial para a parte inferior da página para evitar que eles atrasem os recursos críticos. Por exemplo, um widget de chat. Ninguém na história da internet jamais precisou conversar antes da página estar visível!

2. Evite Background Images

Imagens de fundo (background images) são invisíveis para o preload scanner, o que significa que elas sempre serão enfileiradas pelo parser DOM muito mais lento. Para evitar este atraso, use uma tag <img> regular, combinada com a propriedade CSS object-fit: cover para imitar a aparência de uma imagem de fundo. Desta forma, o preload scanner pode detectar e enfileirar a imagem imediatamente.

3. Use Fetch Priority

Adicione o atributo fetchpriority="high" ao seu elemento LCP para dar uma dica ao navegador de que ele deve priorizar este 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 eleva os elementos visíveis para prioridade alta. Ao definir fetchpriority="high", o download começa imediatamente em prioridade alta, garantindo uma LCP mais rápida.

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 do que outras imagens), mas 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 Preload

O preload altera a ordem em que o preload scanner enfileira os arquivos. Coloque a tag <link rel="preload"> no head da página para instruir o navegador a buscar recursos críticos, como a imagem 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 enfileirados mais tarde) ou até mesmo para fazer o preload de recursos que ainda não são referenciados no HTML (como em alguns sliders). Para eficácia máxima, recomenda-se colocar preloads após as 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 normalmente são enfileiradas antes do recurso da LCP e isso por um bom motivo. Sem folhas de estilo, o navegador não saberá como a página ficará e não poderá iniciar a fase de renderização. No entanto, o tamanho excessivo do CSS e um número excessivo de folhas de estilo competirão com o recurso da 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 seu recurso da LCP, enquanto aplica loading="lazy" para imagens fora da tela.

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

7. Cache do Navegador

O cache do navegador permite pular 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 melhorará os tempos de carregamento para visualizações de página subsequentes e visitantes recorrentes. Veja como o cache do navegador ajuda no resource load delay:

• Armazene em Cache os Recursos Concorrentes: Embora armazenar em cache o próprio recurso da LCP seja uma ótima estratégia, o cache do navegador melhora os atrasos de carga do recurso da LCP armazenando recursos de rede que podem competir ou atrasar o recurso da LCP, como scripts, folhas 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 o desempenho de outros recursos liberando largura de banda e reduzindo os ciclos da CPU do servidor.

8. Use Speculation Rules

A Speculation Rules permite que os navegadores façam o prefetch ou prerender de páginas web com base na navegação prevista do usuário. O prefetching elimina efetivamente a subparte Time to First Byte da 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. Isso elimina todos os atrasos de carga (load delays) para o elemento LCP, como mostrado neste exemplo de detalhamento da LCP de uma página prerenderizada.

9. Evite Renderização no Lado do Cliente

Próximos Passos: Continue Otimizando a LCP

O Resource Load Delay é apenas uma das quatro fases da LCP. Depois de minimizar a latência de descoberta, continue com estes guias relacionados:

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