Otimize o atraso no carregamento do recurso do LCP

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

Otimize o Resource Load Delay do LCP

O Largest Contentful Paint (LCP) é composto por quatro subfases: TTFB, Resource Load Delay, Resource Load Duration e Element Render Delay. 

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

O que é Resource Load Delay?

O Resource Load Delay é o tempo entre o TTFB e o momento em que o navegador inicia o download do recurso do LCP. Basicamente, o navegador deve colocar um recurso do LCP (a imagem do LCP, por exemplo) na fila de download o mais rápido possível. Se isso não acontecer, provavelmente é 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 arquitetônico (onde o navegador não consegue encontrar a 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 do LCP é necessário e decidindo buscá-lo.

Também é importante entender que o Resource Load Delay acontece antes de o recurso ser realmente carregado. É por isso que ele não tem relação com imagens responsivas ou novos formatos de imagem como WebP ou AVIF.

Para elementos LCP baseados em texto e renderizados usando uma fonte do sistema, esse Resource Load Delay normalmente é zero, pois 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.

Como o navegador encontra o elemento LCP?

Para reduzir o Resource Load Delay, você precisa entender como os navegadores descobrem recursos (ou, pelo menos, como descobrem o elemento LCP). Os navegadores usam dois mecanismos: um caminho rápido e um caminho lento. Primeiro, você precisa garantir que o elemento LCP esteja no "caminho rápido".

• O DOM Parser (Caminho Lento): Este é o analisador principal do navegador e é extremamente complexo. Ele constrói a página completa lendo o HTML, as folhas de estilo e interagindo com o JavaScript. Este é o caminho lento porque pode ser atrasado e interrompido pelo download e execução de outros arquivos primeiro, criando uma cadeia de dependências que introduz atraso.
• O Preload Scanner (Caminho Rápido): Como o DOM Parser é (relativamente) lento, os navegadores têm um scanner secundário ultrarrápido que varre a página rapidamente em busca de recursos para download e não é interrompido 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 analisado 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: garantir que a URL do recurso do LCP seja detectável o mais cedo possível pelo preload scanner.

Isso significa duas coisas para um elemento 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 dê prioridade a recursos menos importantes em excesso.

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 faz com que as equipes se concentrem em compressão de imagem, formatos modernos de imagem e imagens responsivas. Esse é um erro. Nossa própria pesquisa sobre os Core Web Vitals mostra que o maior gargalo individual no LCP é o TTFB (48%), seguido pelo Load delay, que representa (24%), enquanto o tempo de carregamento representa apenas 10%, seguido pelo Render delay, com 17%.

Agora, o segredo é que o Load delay é quase totalmente corrigível, enquanto o TTFB sempre existirá. Isso torna o 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 definir o problema com dados de usuários reais (RUM) e, só então, usar o Chrome DevTools para uma análise detalhada.

Passo 1: Verifique com o CrUX

O CrUX representa os dados de campo de usuários reais do Google, disponíveis publicamente e coletados de usuários qualificados do Chrome, apresentados como uma visão móvel de 28 dias dos seus Core Web Vitals no 75º percentil. Ele informa 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, esta é a sua melhor fonte de verdade como ponto de partida.

Acesse cruxvis.withgoogle.com, insira seu site, navegue até Loading Performance e clique em  Largest Contentful Paint (LCP) image subparts

Passo 2: Analise os dados de campo (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 maneira que você quiser (e essa informação vale ouro), mas não o porquê.

Passo 3: Diagnostique com o DevTools

Depois que seus dados de RUM identificarem uma página-alvo e o elemento LCP, você usará 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ê realiza uma análise da main thread para ver exatamente quais tarefas estão em execução e potencialmente bloqueando o processo de renderização.

Guia passo a passo do painel Performance do Chrome DevTools

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

1. Configuração e Preparaçã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á as informações dos Core Web Vitals na linha do tempo de desempenho.
• Para simular condições reais de uso, aplique a limitação de CPU e rede. Uma redução de velocidade de "4x" 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 desempenho:

• Clique no botão "Record and reload page" (um ícone de seta circular) no painel 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:

• Timings Track: Na visualização principal da linha do tempo, localize a seção Timings. Você verá um marcador rotulado LCP. Passar o mouse sobre esse marcador destacará o elemento LCP correspondente na captura de tela do viewport principal e exibirá o tempo total do LCP.
• Detalhamento por fases do LCP (LCP by Phase Breakdown): Clique no marcador LCP na seção Timings. Na aba Summary na parte inferior do painel, você encontrará um detalhamento das fases do LCP. Esse detalhamento mostra explicitamente a duração de cada uma das quatro subpartes, incluindo o Load delay, medido em milissegundos. Esse valor é a medição mais direta e precisa do Resource Load Delay para aquele carregamento de página específico.
• Análise da Main Thread: Ao examinar a linha do tempo, observe a seção Main para verificar se há long tasks (blocos de atividade sinalizados com um triângulo vermelho). Se essas long tasks ocorrerem após o término do carregamento do recurso do LCP, mas antes do marcador LCP, elas provavelmente estão contribuindo para o Element Render Delay, um problema relacionado, mas diferente.

Causas comuns e soluções de alto impacto

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

Causa: LCP carregado via CSS

O Problema: O preload scanner não analisa arquivos CSS. Quando sua imagem LCP é definida com um background-image no CSS, sua URL fica invisível para esse scanner de alta velocidade. O navegador só consegue descobrir a imagem depois de baixar o HTML, encontrar o link do arquivo CSS, baixar o arquivo CSS, construir o CSSOM e, finalmente, aplicar o estilo. Essa cadeia de dependências causa diretamente um alto Resource Load Delay. 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 LCP crítico. 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 obter o mesmo resultado visual usando 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>
    

Boas práticas (Faça isso em vez disso):

    <!-- HTML -->
    <div class="hero-container">
      <img
        src="hero-image.jpg"
        alt="Texto alternativo descritivo para a imagem hero"
        fetchpriority="high"
        class="hero-background-img"
        width="1200"
        height="500"
      />
      <div class="hero-content">
        <h1>Título da Página</h1>
      </div>
    </div>

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

   .hero-background-img {
      position: absolute;
      inset: 0; /* Equivalente a top: 0; right: 0; bottom: 0; left: 0; */
      width: 100%;
      height: 100%;
      object-fit: cover; /* Esta propriedade imita background-size: cover */
      z-index: -1; /* Posiciona a imagem atrás do outro conteúdo */
    }
    

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

Causa: Renderização no lado do cliente (Client-Side Rendering) e injeção de JavaScript

O Problema: Aplicações 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 LCP <img>, só é inserido no DOM pelo JavaScript depois que grandes pacotes (bundles) de frameworks são baixados, analisados e executados. Esse processo oculta 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.

• Server-Side Rendering (SSR) ou Static Site Generation (SSG): Padrões arquitetônicos como SSR ou SSG geram o HTML completo no servidor. O navegador recebe um documento completo que contém a tag <img> e seu atributo src, tornando o recurso do LCP imediatamente detectável pelo preload scanner. Esta é a arquitetura necessária para qualquer página crítica para o desempenho.
• Otimizações específicas do framework: 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: Uso de 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 próxima ao 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 (above-the-fold) é contraproducente. O preload scanner do navegador é 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 exige diligência.

• Remova o loading="lazy" da imagem do 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údos críticos acima da dobra. Omitir totalmente o atributo loading tem o mesmo efeito.
• Audite e configure ferramentas de terceiros: Você também precisa auditar ferramentas de terceiros. Muitas plataformas de CMS, como o WordPress, e vários plugins de otimização de imagem 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 as primeiras uma ou duas imagens da página.

Causa: Estrutura HTML inadequada 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 widgets de chat), forem colocados mais acima no <body> do que o elemento 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 LCP não estiver no primeiro bloco de dados (chunk) que o navegador recebe (cerca de 14 KB), sua descoberta será atrasada por pelo menos uma viagem de ida e volta (round trip) da rede.

• Reordene o HTML: Quando possível, garanta que a tag <img> ou o bloco de texto do elemento LCP apareça o mais cedo possível dentro da tag <body>.
• Desprioritize imagens não críticas: Para imagens não essenciais que precisam aparecer cedo no código HTML (como ícones no 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 (analytics), anúncios ou widgets de redes sociais raramente são críticos para a renderização inicial. Mova as tags <script> desses serviços para o final do <body> ou use o atributo defer. Isso evita que eles bloqueiem o analisador ou disputem largura de banda de rede com o recurso do LCP.

Priorização avançada com Resource Hints

Assim que o recurso do LCP for detectável no HTML, você poderá 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 precoce 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 analisador 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 do CSS ou imagens do LCP localizadas profundamente no DOM. Para detalhes completos de implementação 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 na fila de download imediatamente. Isso é ideal para recursos como fontes carregadas via @font-face em uma folha de estilo externa, LCPs que utilizam background-image no CSS (embora usar uma tag <img> seja preferível) ou uma imagem de LCP localizada profundamente em uma estrutura DOM complexa.

Preload responsivo

Um detalhe crucial de implementação é necessário ao fazer o preload de imagens responsivas. Para garantir que o navegador faça o preload do tamanho correto de imagem para o 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 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="Um texto alternativo descritivo"
     fetchpriority="high"
     width="1200" height="675">
    

Possível armadilha

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

fetchpriority="high" e a fila de prioridades do navegador

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

Como funciona a prioridade do navegador

Quando o navegador descobre recursos durante o carregamento da página, ele atribui a cada um deles um nível de prioridade interno. Por padrão, as imagens no viewport começam com prioridade "Baixa" e depois são atualizadas para "Alta" assim que o navegador conclui o layout e determina que elas estão visíveis. Essa atualização exige que o navegador baixe e analise o CSS primeiro, o que gera um atraso. O atributo fetchpriority="high" ignora esse processo completamente, definindo a imagem com prioridade "Alta" desde o momento em que é descoberta. Isso é especialmente impactante para imagens de LCP porque elimina o atraso de 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 depois que ele já está na fila. Entender essa distinção é fundamental: o preload resolve a descoberta tardia, enquanto o fetchpriority resolve a baixa priorização. Para muitas imagens de 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.

Melhores práticas para o LCP

Para a imagem do LCP, a estratégia ideal é usar ambos juntos. Primeiro, garanta a descoberta precoce colocando a tag <img> cedo no HTML ou usando o preload. Segundo, adicione fetchpriority="high" diretamente na tag <img> (e no link de preload, se utilizado). Essa combinação garante que o recurso seja não apenas descoberto cedo, mas também receba a maior prioridade possível para vencer a disputa por largura de banda contra outros recursos, como folhas de estilo ou fontes.

Exemplo:

<img src="lcp-image.jpg" fetchpriority="high" alt="Uma imagem hero crítica">

Quando usar fetchpriority="low"

O atributo fetchpriority não serve apenas para aumentar a prioridade. Você também pode usar fetchpriority="low" para desprioritizar recursos não críticos que disputam largura de banda com a imagem do 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 pré-carregados que são necessários, mas não urgentes. Ao reduzir explicitamente a prioridade desses recursos concorrentes, você abre mais espaço de largura de banda para a imagem do LCP.

<!-- Imagem LCP: alta prioridade -->
<img src="hero.jpg" fetchpriority="high" alt="Imagem hero" width="1200" height="600">

<!-- Imagem não crítica acima da dobra: baixa prioridade -->
<img src="avatar.jpg" fetchpriority="low" alt="Avatar do autor" width="48" height="48">

Impacto comprovado

Em um estudo de caso envolvendo o Google Flights, a adição de fetchpriority="high" à imagem de fundo do LCP melhorou o tempo do 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 um CDN de imagens ou um provedor de fontes como o Google Fonts, o navegador precisará estabelecer uma nova conexão de rede com esse domínio. Esse processo envolve uma consulta de DNS, um handshake TCP e uma negociação TLS, e tudo isso precisa ser concluído 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 de ativos de origem cruzada.

As Soluções

• preconnect: Este hint instrui o navegador a realizar toda a configuração de 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á ativa, eliminando a latência de configuração. Isso é altamente eficaz e recomendado para os um ou dois domínios de terceiros mais críticos que servem recursos do LCP.
• dns-prefetch: Este é um hint mais leve que realiza apenas a consulta de DNS para um domínio. Ele economiza menos tempo do que o preconnect, mas tem um suporte mais amplo nos navegadores e é útil como fallback ou para domínios de terceiros menos críticos.

Boas práticas de implementação

Para garantir a compatibilidade máxima, forneça ambos os hints. O navegador usará o preconnect se houver suporte e recorrerá ao dns-prefetch caso contrário. 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: Comparativo de Resource Hints para otimização de LCP

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

Estratégias holísticas e orientadas ao futuro

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

O papel de um CDN moderno

Uma Rede de Distribuição de Conteúdo (CDN) é uma tecnologia fundamental para o desempenho web que reduz indireta, mas significativamente, o Resource Load Delay, especialmente para recursos do LCP.

• Redução da sobrecarga de conexão: Ao distribuir os arquivos em uma rede global de servidores, um CDN posiciona o conteúdo geograficamente mais próximo do usuário. Isso reduz inerentemente o tempo de viagem de ida e volta (RTT) necessário para a consulta de DNS, handshake TCP e negociação TLS, que são todos componentes do tempo de configuração da conexão. Para uma imagem de LCP hospedada em um CDN, isso reduz diretamente o seu Load Delay.
• CDNs de imagem: CDNs de imagem especializados oferecem um benefício duplo. Eles fornecem a vantagem de proximidade de um CDN padrão, ao mesmo tempo em que automatizam muitas otimizações complexas que reduzem o Resource Load Duration, como redimensionamento de imagem em tempo real, compressão e conversão para formatos modernos como AVIF e WebP.
• Protocolos avançados: Muitos CDNs modernos usam HTTP/3, que utiliza QUIC em vez de TCP. O HTTP/3 reduz o tempo de configuração da conexão e mitiga o bloqueio de início de fila, resultando em uma entrega de recursos mais rápida e eficiente no geral.

Eliminando o atraso completamente com Speculation Rules

A API Speculation Rules pode eliminar o atraso de LCP por completo em navegações subsequentes.

Mecanismo

Esta API permite que os desenvolvedores informem declarativamente ao navegador quais URLs um usuário provavelmente navegará a seguir. Com base nessas regras, o navegador pode optar por realizar a pré-renderização (prerender) de uma página-alvo em uma aba oculta em segundo plano antes mesmo de o usuário clicar no link.

Impacto no LCP

Quando o usuário clica em um link para uma página pré-renderizada, a navegação é praticamente instantânea. A página já foi totalmente carregada e renderizada em segundo plano. Para essa navegação, o TTFB, Resource Load Delay, Resource Load Duration e Element Render Delay são todos reduzidos de forma eficaz para quase zero sob a 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 produtos dos primeiros itens da lista. Quando um usuário clica em um desses produtos, a página aparece instantaneamente.

Síntese de estudos de caso: da teoria à prática

Essas otimizações têm um impacto real e mensurável.

• Caso 1: O poder transformador do Preloading: Um experimento conduzido pela DebugBear em uma página com alto load delay fornece um exemplo impressionante. 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 mais cedo, o Resource Load Delay foi reduzido para apenas 2% do tempo do LCP. Isso mostra como um ajuste arquitetônico simples pode resolver um gargalo enorme de desempenho.
• Caso 2: O antipadrão de loading="lazy" na vida real: Um desenvolvedor no Stack Overflow relatou um LCP no desktop com um atraso de carregamento desconcertante de 1.430 ms, apesar de estar em 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 placeholder transparente. A solução definitiva foi desativar esse comportamento para o elemento LCP, permitindo que ele fosse descoberto e carregado de forma imediata. Isso ilustra como ferramentas de terceiros podem, inadvertidamente, introduzir atrasos graves de carregamento.
• Caso 3: O ganho de desempenho com 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 fundo 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 fundamental para vencer a disputa 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 "Network" e recarregue a página. Observe a sequência de carregamento. Seu recurso do LCP deve ser um dos primeiros itens colocados na fila de download. Se ele estiver atrasado em relação a 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 frequentemente registram dados de atribuição do LCP (LCP attribution data). Com o RUM, você pode visualizar o detalhamento das subpartes do LCP (ao longo do tempo ou por página), obtendo uma imagem clara do load delay para elementos LCP em todo o seu site ou por página. O exemplo abaixo mostra um detalhamento global do LCP juntamente com o respectivo load delay.

Como melhorar o Load Delay

Um atraso no carregamento de recursos (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 do LCP ou despriorizar recursos que não sejam do LCP (Non-LCP). Vamos explorar alguns padrões comuns:

Dica de LCP: Entenda o Preload Scanner: Os navegadores modernos usam um mecanismo chamado preload scanner, que varre rapidamente o HTML e coloca os recursos na fila de download. Se um recurso não puder ser colocado na fila pelo preload scanner, ele terá que esperar pelo DOM parser, 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 do HTML

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

• Aplique lazy loading em imagens não importantes ou ocultas: Às vezes, imagens (por exemplo, bandeiras para versões de idiomas específicos do seu site ou imagens no menu) são encontradas logo no topo do HTML do seu site. Essas imagens não são nem de longe tão importantes quanto o elemento LCP. Ao aplicar o lazy loading nessas imagens, elas são ignoradas pelo preload scanner e 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 sejam absolutamente irrelevantes para o carregamento inicial para o final da página, evitando que eles atrasem recursos críticos. Por exemplo, um widget de chat. Ninguém na história da internet precisou iniciar um chat antes mesmo de a página estar visível!

2. Evite imagens de fundo (Background Images)

As imagens de fundo são invisíveis para o preload scanner, o que significa que elas sempre serão colocadas na fila pelo DOM parser, que é bem mais lento. Para evitar esse atraso, use uma tag <img> normal em conjunto com a propriedade CSS object-fit: cover para imitar a aparência de uma imagem de fundo. Dessa forma, o preload scanner pode detectar e enfileirar a imagem imediatamente.

3. Use o Fetch Priority

Adicione o atributo fetchpriority="high" ao seu elemento 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 atualiza os elementos visíveis para prioridade alta. Ao definir fetchpriority="high", o download começa imediatamente em prioridade alta, garantindo um LCP mais rápido.

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

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

4. Implemente o 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 do LCP, o mais cedo possível. Preloads can be used to preload resources that are referenced later in the HTML (and therefore are enqueued later) or even to preload resources that are not yet referenced in the HTML (as with some sliders). For maximum effectiveness it is recommended to place preloads after stylesheets and before scripts in the head of the page.

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

5. Otimize os estilos

As folhas de estilo normalmente são colocadas na fila antes do recurso do LCP, e isso com um bom motivo. Sem folhas de estilo, o navegador não saberá como a página deve ser exibida e não poderá iniciar a fase de renderização. No entanto, um tamanho excessivo de CSS e um número excessivo de folhas de estilo competirão com o recurso do LCP pela largura de banda inicial.

6. Implemente o Lazy Loading de forma eficiente

O atributo loading pode ser uma faca de dois gumes. Use loading="eager" (or 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 (offscreen).

• Carregue o elemento LCP de forma imediata (eager): Se o elemento LCP for carregado de forma preguiçosa (lazy-loaded), ele não será enfileirado pelo preload scanner e carregará muito mais tarde, afetando negativamente o desempenho.
• Aplique lazy loading em imagens do viewport: Para imagens que estão no viewport visível, mas não são recursos do LCP, use loading="lazy" para colocá-las na fila de download um pouco mais tarde. Isso reduz a disputa de largura de banda com o recurso do LCP.
• Evite o lazy loading de imagens fora da tela: Imagens que não estão no viewport visível não acionarão o download de forma alguma, eliminando completamente a concorrência por largura de banda.

7. Cache do Navegador

O cache do navegador permite ignorar solicitações de rede para recursos que já foram armazenados localmente no dispositivo do usuário. Embora não acelere a primeira visualização da página, ele melhorará os tempos de carregamento para visualizações de página subsequentes e visitantes que retornam. Veja como o cache do navegador ajuda no Resource Load Delay:

• Faça o cache de recursos concorrentes: Embora armazenar em cache o próprio recurso do LCP seja uma ótima estratégia, o cache do navegador melhora o Resource Load Delay do LCP ao armazenar recursos de rede que poderiam competir ou atrasar o recurso do LCP, como scripts, folhas de estilo e imagens.
• Reduza a carga do servidor: O cache diminui a quantidade de solicitações enviadas ao seu servidor, o que pode melhorar o desempenho de outros recursos ao liberar largura de banda e reduzir os ciclos de CPU do servidor.

8. Use Speculation Rules

As Speculation Rules permitem que os navegadores façam prefetch ou prerender de páginas web com base na navegação prevista do usuário. O prefetching elimina de forma eficaz a subparte Time to First Byte (TTFB) do LCP e não tem impacto no Resource Load Delay. A pré-renderizaçã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 carregamento para o elemento LCP, conforme mostrado neste exemplo de detalhamento do LCP de uma página pré-renderizada.

9. Evite a renderização no lado do cliente (Client-Side Rendering)

Próximos passos: continue otimizando o LCP

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

• Identificar &amp;amp; corrigir problemas de LCP: A metodologia de diagnóstico completa para encontrar e corrigir todos os problemas de LCP.
• Otimizar 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 de download por meio de compressão, formatos modernos e otimização de CDN.
• Element Render Delay: Depois do download do recurso, garanta que o navegador possa pintá-lo imediatamente limpando a main thread.