Otimize o atraso de carregamento do recurso do LCP

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

Otimize o Resource Load Delay do LCP

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

Dica rápida: se o seu LCP for uma imagem, ele quase sempre será pior que texto. Você precisa rastrear os tipos de elementos de 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 de LCP. Basicamente, um navegador deve enfileirar um recurso de LCP (a imagem de LCP, por exemplo)  o mais rápido possível. Se ele não for enfileirado o mais rápido possível, muito 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 de arquitetura (em que o navegador não consegue encontrar a URL do recurso no payload HTML inicial). Esse atraso de carregamento de recurso pode ser visto como o tempo que o navegador gasta identificando que o recurso de LCP é necessário e decidindo buscá-lo.

Também é importante entender que o atraso de carregamento do recurso acontece antes do recurso ser realmente carregado. É por isso que ele não tem nada a ver com imagens responsivas ou novos formatos de imagem como WebP ou AVIF.

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

Como o navegador encontra o elemento de LCP?

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

• O DOM Parser (Caminho Lento): Este é o principal analisador do navegador e ele é um monstro. Ele constrói a página inteira  lendo o HTML, 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 extremamente rápido que varre a página muito rapidamente em busca de recursos para download e não é interrompido  por nada. Se ele encontrar tags <script>, <img> não-lazy 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 baseia-se em um princípio: garantir que a URL do recurso de LCP seja detectável o mais cedo possível pelo preload scanner.

Isso significa duas coisas para um elemento de LCP:

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

Por que o Load Delay importa para os Core Web Vitals

Desenvolvedores iniciantes costumam pensar que o LCP é um problema de "tamanho de arquivo". Isso leva as equipes a focarem em compressão de imagem, formatos de imagem modernos e imagens responsivas. Esse é um erro. A 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%). O tempo de carregamento ocupa apenas 10%, seguido pelo Render delay, com 17%.

O grande 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, definir o problema primeiro 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 fornece os field data públicos do Google de usuários reais do Chrome qualificados, representados como uma média 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, essa é a sua melhor fonte de verdade como ponto de partida.

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

Passo 2: Analise os field data (RUM)

O RUM coleta os Core Web Vitals de todos os seus usuários reais e oferece uma visão muito mais específica e detalhada. Ele diz quem e o quê, segmentado da 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 do RUM identificarem uma página de destino e o elemento de 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.

Um 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 load delay.

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

3. Análise e Interpretação:

• Faixa Timings: Na visualização principal da linha do tempo, localize a faixa Timings. Você verá um marcador rotulado como LCP. Passar o cursor sobre esse marcador destacará o elemento de LCP correspondente na captura de tela da viewport principal e exibirá o tempo total do LCP.
• Decomposição do LCP por Fase: Clique no marcador de LCP na faixa Timings. Na aba Summary (Resumo) na parte inferior do painel, você encontrará um detalhamento das etapas de tempo do LCP. Esse 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 Main Thread: Ao examinar a linha do tempo, procure por long tasks na faixa Main (blocos de atividade sinalizados com um triângulo vermelho). Se essas long tasks ocorrerem depois que o download do recurso de LCP for concluído, mas antes do marcador de 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 uma de duas coisas: o recurso de LCP é descoberto tardiamente ou recebe uma baixa prioridade de busca. Aqui estão os erros de arquitetura mais comuns e suas soluções.

Causa: LCP carregado via CSS

O Problema: O preload scanner não analisa arquivos CSS. Quando a imagem de 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 então aplicar o estilo. Essa cadeia de dependência 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 de 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 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>
    

Boa prática (Faça isto 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>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 de outros conteúdos */
    }
    

Esta implementação fornece o mesmo resultado visual, mas torna a imagem de LCP detectável no primeiro momento possível, o que minimiza seu load delay.

Causa: Client-Side Rendering e Injeção de JavaScript

O Problema: Aplicações que usam frameworks de client-side rendering (CSR), como React ou Vue, frequentemente servem uma estrutura HTML minimalista. O conteúdo real, incluindo a tag <img> do LCP, só é inserido no DOM pelo JavaScript após o download, análise e execução de grandes pacotes do framework. Esse processo oculta fundamentalmente o recurso de 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 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 de LCP imediatamente detectável pelo preload scanner. Esta é a arquitetura necessária para qualquer página em que o desempenho seja crítico.
• Otimizações específicas de framework: Frameworks modernos também fornecem 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 <link rel="preload"> e fetchpriority="high" corretos, garantindo que a imagem seja descoberta e buscada com a prioridade correta.

Causa: Uso de loading="lazy" na imagem de LCP

O Problema: Este é um erro frequente e de alto impacto. O atributo loading="lazy" é uma instrução direta ao navegador para adiar a busca de uma imagem até que ela esteja próxima da viewport. Embora essa seja a otimização correta para imagens abaixo da dobra (below-the-fold), aplicá-la a um elemento de LCP acima da dobra é contraproducente. O preload scanner do navegador é 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 loading="lazy" da imagem de LCP: Qualquer imagem que provavelmente seja o elemento de 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 o atributo loading completamente 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 de 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 chat, forem colocados antes do elemento de LCP no <body>, 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 de LCP. Um documento HTML grande também pode ser um problema; se o elemento de LCP não estiver no primeiro fragmento (chunk) de dados que o navegador recebe (cerca de 14 KB), sua descoberta será atrasada por pelo menos uma viagem de ida e volta (round trip) de rede.

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

• Reordene o HTML: Quando possível, certifique-se de que a tag <img> ou o bloco de texto para o elemento de 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 em um cabeçalho), aplique loading="lazy". Isso diz ao preload scanner para ignorá-las, preservando a fila de download para o elemento de 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 analisador ou disputem largura de banda com o recurso de LCP.

Priorização Avançada com Resource Hints

Uma vez que o recurso de LCP esteja 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 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 para recursos como fontes, imagens de fundo CSS ou imagens de LCP localizadas profundamente no DOM. Para detalhes completos de implementação e exemplos, consulte nosso guia dedicado sobre como fazer o preload da imagem de 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 estilo externa, LCPs com CSS background-image (embora o uso de uma tag <img> seja preferível) ou uma imagem de LCP que esteja localizada profundamente em uma estrutura DOM complexa.

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 do tamanho correto de imagem 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 correspondam perfeitamente aos atributos da tag <img> correspondente.

Exemplo de Preload Responsivo:

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

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

Possível Armadilha

O preload resolve o tempo de busca (Load Delay e Resource Load Duration), mas não o tempo de pintura. Se a main thread estiver bloqueada por JavaScript pesado ou CSS render blocking quando a imagem pré-carregada chegar, ela ainda terá que esperar para ser renderizada, o que pode deslocar 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 que você influencie a prioridade de um recurso dentro da fila de download do navegador.

Como funciona a prioridade no 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 na viewport começam com prioridade "Low" e são posteriormente atualizadas para "High" quando 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 inteiramente, definindo a imagem com prioridade "High" a partir do momento em que é descoberta. Isso é especialmente impactante para imagens de LCP porque elimina o atraso na atualização da prioridade.

preload vs. fetchpriority

Esses dois hints servem a propósitos diferentes, porém complementares. O preload afeta quando um recurso é descobri-lo e adicionado à fila. O fetchpriority afeta o seu nível de prioridade uma vez 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, veja nosso artigo sobre priorização de recursos.

Boa prática para o LCP

Para a imagem de LCP, a melhor estratégia é usá-los juntos. Primeiro, garanta a descoberta precoce 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 apenas seja descoberto mais cedo, mas também receba a maior prioridade possível para vencer a disputa 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 disputam largura de banda com a imagem de LCP. Candidatos comuns incluem imagens acima da dobra que não são o elemento de 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 de LCP.

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

<!-- Imagem acima da dobra não crítica: baixa prioridade -->
<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 de LCP melhorou o tempo do LCP de 2,6 segundos para 1,9 segundos, uma melhoria de 700 ms.

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

O Problema

Se o seu recurso de 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 deve 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 origens diferentes (cross-origin).

As Soluções

• preconnect: Este hint instrui o navegador a realizar 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á ativa (warm), 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 de LCP.
• dns-prefetch: Este é um hint mais leve que realiza apenas a consulta de DNS para um domínio. Ele economiza menos tempo que o preconnect, mas tem um suporte mais amplo do navegador e é útil como fallback ou para domínios de terceiros menos críticos.

Melhor Prática de Implementação

Para garantir a compatibilidade máxima, forneça ambos os hints. O navegador usará 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: Comparação 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 Focadas no Futuro

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

O Papel de uma CDN Moderna

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

• Redução de Overhead 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 round-trip time (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 uma CDN, isso reduz diretamente o seu load delay.
• CDNs de Imagem: CDNs de imagem especializadas oferecem um duplo benefício. Elas fornecem a vantagem de proximidade de uma CDN padrão, ao mesmo tempo em que automatizam muitas otimizações complexas que reduzem o Resource Load Duration, como redimensionamento de imagem dinâmico (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 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 da fila (head-of-line blocking), levando a uma entrega de recursos mais rápida e eficiente no geral.

Eliminando o Atraso Completamente com Speculation Rules

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

Mecanismo

Essa API permite que os desenvolvedores informem ao navegador, de forma declarativa, quais URLs o usuário provavelmente navegará a seguir. 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 de o usuário clicar 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 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 regras de especulação (speculation rules) poderiam 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.

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

Essas 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 alto load delay fornece um exemplo impressionante. A imagem de 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 uma correção arquitetônica simples pode resolver um gargalo massivo de desempenho.
• Caso 2: O Antipadrão do loading="lazy" no Mundo Real: Um desenvolvedor no Stack Overflow relatou um LCP em desktop com um inacreditável load delay de 1.430 ms, apesar de uma rede rápida. A causa foi rastreada até um plugin de otimização de imagem que estava aplicando incorretamente o lazy loading à imagem de LCP, substituindo seu atributo src por um SVG marcador de posição (placeholder) transparente. A solução definitiva foi desativar esse comportamento para o elemento de LCP, aumentando a velocidade e permitindo que ele fosse descoberto e carregado de forma ávida (eager). Isso ilustra como ferramentas de terceiros podem introduzir inadvertidamente atrasos severos de carregamento.
• Caso 3: O Ganho de Desempenho do fetchpriority: O estudo de caso do Google Flights fornece evidências claras do impacto da priorização explícita. Ao simplesmente adicionar fetchpriority="high" à imagem de fundo de LCP da página, a pontuação do LCP melhorou em 700 ms, caindo de 2,6 segundos para 1,9 segundos. Isso demonstra que, mesmo quando um recurso é detectável, sinalizar sua alta importância para o navegador é um passo crítico para vencer a 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" (Rede) e recarregue a página. Observe a sequência de carregamento. O recurso do LCP deve ser um dos primeiros itens na fila de download. Se ele estiver atrás de outros elementos, há um problema de atraso no carregamento do recurso (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): As 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), obtendo uma imagem clara do load delay para elementos de LCP em todo o seu site ou por página. O exemplo abaixo mostra um detalhamento global do LCP junto com o load delay correspondente.

Como melhorar o Load Delay

O atraso no carregamento do recurso acontece quando a ordem e o tempo de download 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 são do 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 enfileirado pelo preload scanner, ele terá que esperar pelo DOM parser mais lento, resultando em atrasos. Garantir que seus recursos de 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 (or the preload scanner) processa seu HTML de cima para baixo, enfileirando os recursos na ordem em que aparecem. Isso significa que quanto mais alto o recurso de LCP aparecer no HTML, mais cedo ele será enfileirado. Para otimizar isso, remova ou adie recursos desnecessários do topo do HTML:

• Faça lazy loading de imagens não importantes ou ocultas: Às vezes, imagens (por exemplo, bandeiras para versões de idiomas do seu site ou imagens no menu) são encontradas no topo do HTML. Essas imagens não são tão importantes quanto o elemento de LCP. Ao aplicar o lazy loading a essas imagens, elas são ignoradas pelo preload scanner e enfileiradas um pouco mais tarde no processo de carregamento.
• Mova scripts não importantes para o final da página: Mova scripts que são totalmente desnecessários 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 conversar no chat antes da página estar visível!

2. Evite imagens de fundo

Imagens de fundo (background images) são invisíveis para o preload scanner, o que significa que sempre serão enfileiradas pelo DOM parser, que é muito mais lento. Para evitar esse atraso, use uma tag <img> comum, combinada 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 Fetch Priority

Adione o atributo fetchpriority="high" ao seu elemento de LCP para indicar ao navegador que ele deve priorizar esse recurso desde o início. Normalmente, as imagens são carregadas 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, gerando um LCP mais rápido.

O fetchpriority costuma ser menos intrusivo (e menos eficaz) do que o preloading 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="Hero Image" fetchpriority="high">

4. Implemente o Preloading

O preloading 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 de LCP, o mais cedo possível. O preload pode ser usado para carregar recursos que são referenciados mais tarde no HTML (e, portanto, são enfileirados mais tarde) ou até mesmo para pré-carregar recursos que ainda não foram referenciados no HTML (como em alguns sliders). Para máxima eficácia, recomenda-se colocar os 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 Estilos

As folhas de estilo normalmente são enfileiradas antes do recurso de LCP, e isso por 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 exagerado de folhas de estilo competirão com o recurso de LCP pela largura de banda inicial.

6. Implemente o 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 de LCP, enquanto aplica loading="lazy" para imagens fora da tela (offscreen).

• Carregue o elemento de LCP de forma eager: Se o elemento de LCP for carregado com lazy loading, ele não será enfileirado pelo preload scanner e carregará muito mais tarde, impactando negativamente o desempenho.
• Faça lazy loading de imagens da viewport: Para imagens que estão na viewport visível, mas não são recursos de LCP, use loading="lazy" para enfileirá-las para download um pouco mais tarde. Isso reduz a disputa por largura de banda com o recurso de LCP.
• Evite o carregamento de imagens fora da tela: Imagens que não estão na viewport visível não dispararão download algum, eliminando completamente a disputa por largura de banda.

7. Cache do Navegador

O cache do navegador permite que você pule solicitações de rede para recursos que já foram armazenados localmente no dispositivo do usuário. Embora não acelere a primeira visualização da página, ele melhorará o tempo de carregamento para visualizações subsequentes e visitantes que retornam. Veja como o cache do navegador ajuda com o atraso no carregamento de recursos:

• Armazene em cache recursos concorrentes: Embora armazenar o próprio recurso de LCP em cache seja uma ótima estratégia, o cache do navegador melhora os atrasos de carregamento de recursos de LCP armazenando recursos de rede que poderiam competir com ou atrasar o recurso de 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 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 prefetch elimina efetivamente a subparte do LCP correspondente ao Time to First Byte (TTFB), sem impacto no atraso de carregamento do recurso. O prerender renderiza a próxima página em uma aba oculta e baixa todos os recursos da página. Isso elimina todos os atrasos de carregamento para o elemento de LCP, conforme mostrado neste exemplo de detalhamento do LCP de uma página com prerender.

9. Evite o Client-Side Rendering

Próximos Passos: Continue Otimizando o LCP

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

• Identificar e 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 formatos de imagem, imagens responsivas, preloading e erros comuns de imagem.
• Resource Load Duration: Depois que o navegador descobrir o recurso, reduza o tempo de download por meio de compressão, formatos modernos e otimização de CDN.
• Element Render Delay: Depois de baixar o recurso, garanta que o navegador consiga pintá-lo imediatamente, liberando a main thread.