Otimize o atraso no carregamento do recurso LCP

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

Otimize o Resource Load Delay do LCP

O Largest Contentful Paint (LCP) possui 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ê deve rastrear os tipos de elemento do 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 o recurso do LCP (a imagem do LCP, por exemplo)  na fila o mais rápido possível. Se ele não for colocado na fila imediatamente, o mais provável é que o navegador não consiga descobri-lo na hora ou não o reconheça como importante o suficiente.

Um valor alto aqui indica um problema de arquitetura (onde o navegador não consegue encontrar a URL do recurso no payload HTML inicial). Esse atraso 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 esse atraso ocorre antes de o recurso ser de fato carregado. Por isso não tem nada a ver com imagens responsivas ou formatos de imagem novos como WebP ou AVIF.

Para elementos do LCP baseados em texto e renderizados com uma fonte do sistema, o Resource Load Delay geralmente é zero, pois não há recursos externos para buscar. Valores mais altos de Resource Load Delay são específicos para elementos do LCP que dependem de um recurso de rede externo, como uma imagem ou um arquivo de vídeo.

Como um navegador encontra o elemento do LCP?

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

• O DOM Parser (Caminho Lento): Este é o parser principal do navegador e é pesado. Ele constrói a página completa  lendo o HTML, as stylesheets 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 possuem um scanner secundário extremamente rápido que varre a página 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 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: garanta que a URL do recurso do LCP seja descoberta o mais cedo possível pelo preload scanner.

Isso significa 2 coisas para um elemento do LCP:

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

Por que o Load Delay Importa para os Core Web Vitals

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

A questão aqui é 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, você primeiro precisa medi-lo com precisão. O fluxo de trabalho é sempre este: verifique com o CrUX para definir o problema com field data de usuários reais (RUM) e só então vá para o Chrome DevTools para uma análise profunda.

Passo 1: Verifique com o CrUX.

O CrUX contém os field data públicos do Google baseados em usuários reais e elegíveis do Chrome, fornecidos como uma janela móvel de 28 dias dos seus Core Web Vitals no percentil 75. Ele diz se um número é bom ou ruim, mas não diz quem, o que ou por quê. Como o Google se baseia nos dados do CrUX, esta é sua melhor fonte da verdade como ponto de partida.

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

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 que, segmentado da forma que você quiser (e essa informação vale ouro), mas não diz o porquê.

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

Passo 3: Diagnostique com o DevTools

Quando seus dados de RUM identificarem uma página alvo e o elemento do 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 rodando e possivelmente bloqueando o processo de renderização.

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

Causas Comuns e Soluções de Alto Impacto

Um Resource Load Delay alto é causado por um de dois motivos: o recurso do LCP é descoberto tarde, 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 sua imagem de LCP é definida por um background-image no CSS, a URL dela 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ências causa diretamente um Resource Load Delay alto. Para saber mais sobre esse padrão, veja 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ê consegue 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 */
    }
    

Essa implementação entrega o mesmo resultado visual, mas torna a imagem do LCP detectável o mais cedo possível, o que minimiza o 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, muitas vezes entregam um shell HTML mínimo. O conteúdo real, incluindo a tag <img> do LCP, só é inserido no DOM pelo JavaScript depois que grandes pacotes do framework são baixados, analisados e executados. Esse processo esconde totalmente o recurso do LCP do preload scanner, gerando 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 com 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 com performance crítica.
• Otimizações Específicas do Framework: Frameworks modernos também oferecem otimizações nativas. Por exemplo, o componente <Image> do Next.js possui uma propriedade priority. Defini-la como true instrui o framework a adicionar automaticamente os atributos corretos de <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 perto da viewport. Embora esta seja a otimização correta para imagens abaixo da dobra, aplicá-la a um elemento de LCP acima da dobra é contraproducente. O preload scanner do navegador é 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 do LCP: Qualquer imagem que tenha chance de ser o elemento do LCP não deve ter o atributo loading="lazy". O comportamento padrão do navegador é loading="eager", que é a configuração correta para conteúdo crítico acima da dobra. Omitir o atributo de carregamento completamente surte o mesmo efeito.
• Audite e Configure Ferramentas de Terceiros: Você também deve auditar as ferramentas de terceiros. Muitas plataformas de CMS, como WordPress, e vários plugins de otimização de imagem aplicam automaticamente lazy loading em todas as imagens. É essencial configurar essas ferramentas para excluir a imagem do LCP desse comportamento. Isso geralmente envolve criar uma regra de exclusão para as primeiras uma ou duas imagens da página.

Causa: Estrutura HTML Subótima e Documentos Grandes

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

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

• Reordene o HTML: Sempre que possível, garanta que a tag <img> ou o bloco de texto do LCP apareça o mais cedo possível dentro da tag <body>.
• Despriorize 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 do LCP.
• Adie Scripts Não Essenciais: Scripts de analytics, anúncios ou widgets de redes sociais raramente são críticos para a renderização inicial. Mova as tags <script> deles para o final do <body> ou use o atributo defer. Isso evita que eles bloqueiem o parser ou compitam por largura de banda da rede com o recurso do LCP.

Priorização Avançada com Resource Hints

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

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

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

Mecanismo

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

Preload Responsivo

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

Exemplo de Preload Responsivo:

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

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

Possível Armadilha

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

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

O atributo fetchpriority é 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 um nível interno de prioridade. 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 estão visíveis. Essa atualização exige que o navegador baixe e processe o CSS primeiro, o que gera um atraso. O atributo fetchpriority="high" ignora esse processo totalmente, definindo a imagem com prioridade "Alta" desde o momento em que é descoberta. Isso é especialmente impactante para imagens de LCP, pois elimina o atraso da atualização de prioridade.

preload vs. fetchpriority

Esses dois hints têm propósitos diferentes, mas complementares. O preload afeta quando um recurso é descoberto e adicionado à fila. O fetchpriority afeta o nível de prioridade dele depois que já está na fila. Entender essa diferença é crítico: 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.

Melhor Prática para LCP

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

Exemplo:

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

Quando Usar fetchpriority="low"

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

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

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

Impacto Comprovado

Em um estudo de caso do Google Flights, adicionar fetchpriority="high" à imagem de fundo do LCP melhorou o tempo de LCP de 2,6 segundos para 1,9 segundos, uma redução de 700 ms.

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

O Problema

Se o recurso do seu 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 precisa estabelecer uma nova conexão de rede para esse domínio. Esse processo envolve uma busca de DNS, um handshake TCP e uma negociação TLS. Tudo isso deve ser concluído antes que o primeiro byte do recurso possa ser baixado. Esse tempo de configuração da conexão contribui diretamente para o Resource Load Delay de recursos cross-origin.

As Soluções

• preconnect: Este hint instrui o navegador a fazer a configuração completa da conexão (DNS, TCP e TLS) para uma origem de terceiros específica em segundo plano, com antecedência. Quando o recurso é de fato solicitado, a conexão já está estabelecida, eliminando a latência de setup. 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 executa apenas a busca de DNS para um domínio. Ele economiza menos tempo que o preconnect, mas tem um suporte maior nos navegadores e é útil como fallback ou para domínios de terceiros menos críticos.

Melhor Prática de Implementação

Para garantir a máxima compatibilidade, forneça ambos os hints. O navegador usará o preconnect se suportado e recorrerá ao dns-prefetch caso não seja. 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 os papéis distintos desses hints poderosos, a tabela a seguir traz um resumo comparativo.

Estratégias Holísticas e Visando o Futuro

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

O Papel de um CDN Moderno

Uma Content Delivery Network (CDN) é uma tecnologia base para web performance que reduz o Resource Load Delay indiretamente, mas de forma significativa, principalmente para recursos de LCP.

• Redução de Overhead de Conexão: Ao distribuir recursos por uma rede global de servidores, um CDN aproxima o conteúdo geograficamente do usuário. Isso inerentemente reduz o round-trip time (RTT) exigido para a busca de DNS, handshake TCP e negociação TLS, que são todos componentes do tempo de configuração de conexão. Para uma imagem de LCP hospedada em um CDN, isso reduz seu load delay diretamente.
• Image CDNs: Image CDNs especializados oferecem um duplo benefício. Eles fornecem a vantagem de proximidade de um CDN padrão enquanto automatizam muitas otimizações complexas que reduzem a 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 no lugar de TCP. O HTTP/3 reduz o tempo de configuração da conexão e atenua o head-of-line blocking, gerando uma entrega de recursos mais rápida e eficiente no geral.

Eliminando o Atraso Completamente com Speculation Rules

A API de Speculation Rules consegue eliminar o atraso do LCP inteiramente nas navegações subsequentes.

Mecanismo

Esta API permite que os desenvolvedores informem ao navegador de forma declarativa quais URLs um usuário provavelmente acessará em seguida. Com base nessas regras, o navegador pode optar por fazer o prerender de uma página alvo em uma aba oculta em segundo plano antes mesmo que o usuário clique no link.

Impacto no LCP

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

Exemplo de Caso de Uso

Em uma página de categoria de e-commerce, as speculation rules podem ser usadas para fazer prerender das páginas de detalhes do produto dos primeiros itens da lista. Quando um usuário clica em um desses produtos, a página aparece instantaneamente.

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

Essas otimizações geram um impacto mensurável no mundo real.

• Caso 1: O Poder Transformador do Preload: Um experimento conduzido pelo DebugBear em uma página com um load delay alto fornece um exemplo impressionante. A imagem do LCP estava escondida em uma cadeia de requisições, fazendo com que o Resource Load Delay fosse responsável por assombrosos 75% do tempo total do LCP. Ao implementar um único hint de <link rel="preload"> para tornar a imagem detectável de imediato, o Resource Load Delay caiu para apenas 2% do tempo do LCP. Isso mostra como um simples ajuste de arquitetura pode resolver um gargalo gigantesco de performance.
• Caso 2: O Antipadrão loading="lazy" no Mundo Real: Um desenvolvedor no Stack Overflow relatou um LCP em desktop com um load delay absurdo de 1.430 ms, apesar de ter uma rede rápida. A causa foi rastreada até um plugin de otimização de imagem que estava aplicando lazy loading incorretamente na imagem do LCP, substituindo seu atributo src por um SVG de espaço reservado transparente. A solução definitiva foi desativar esse comportamento para o elemento de LCP, permitindo que ele fosse detectado e carregado de forma eager. Isso ilustra como ferramentas de terceiros podem introduzir inadvertidamente atrasos severos de carregamento.
• Caso 3: O Impulso de Performance do fetchpriority: O estudo de caso do Google Flights fornece uma prova incontestável sobre o impacto da priorização explícita. Apenas adicionando 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 prova que, mesmo quando um recurso é detectável, sinalizar sua alta importância para o navegador é um passo crítico para vencer a corrida por largura de banda da rede.

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

Use dados de Real User Monitoring (RUM): Ferramentas de RUM frequentemente registram os dados de atribuição do LCP. Com RUM, você consegue visualizar o detalhamento das subpartes do LCP (ao longo do tempo ou por página), tendo uma visão clara do load delay para elementos do LCP em todo o seu site ou página a página. O exemplo a seguir exibe um detalhamento global do LCP junto com o load delay correspondente.

Como Melhorar o Load Delay

Um Resource Load Delay acontece quando a ordem de download e o timing dos recursos não são ideais. Em essência, há duas maneiras diretas de corrigir isso: priorize o recurso do LCP ou despriorize os recursos que não são do LCP. Vamos explorar alguns padrões comuns:

Dica de LCP: Entenda o Preload Scanner: Navegadores modernos usam um mecanismo chamado preload scanner, que varre o HTML rapidamente e enfileira recursos para download. Se um recurso não puder ser enfileirado pelo preload scanner, ele precisará esperar pelo DOM parser mais lento, o que resulta em atrasos. Garantir que seus recursos de LCP sejam detectáveis pelo preload scanner faz toda a diferença para reduzir o load delay.

1. Otimize a Estrutura do HTML

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

• Faça Lazy Loading em Imagens Escondidas ou Sem Importância: Às vezes, imagens (por exemplo, bandeiras para as versões de idioma do site ou imagens do menu) ficam bem no topo do HTML do site. Essas imagens não chegam nem perto da importância do elemento do LCP. Ao fazer o lazy loading dessas imagens, o preload scanner as ignora e elas são enfileiradas um pouco mais tarde durante o processo de carregamento.
• Mova scripts não importantes para o final da página: Mova os scripts que não são essenciais para o carregamento inicial para o fim da página. Isso evita que eles atrasem os recursos críticos. Por exemplo, um widget de chat. Ninguém na história da internet já precisou conversar no chat antes da página ficar visível!

2. Evite Imagens de Fundo

Imagens de fundo são invisíveis para o preload scanner, o que significa que 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 consegue detectar e enfileirar a imagem imediatamente.

3. Use Fetch Priority

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

O fetchpriority 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, stylesheets 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 os recursos críticos o mais cedo possível, como a imagem do LCP. Você pode usar preloads para buscar antecipadamente recursos que são referenciados mais abaixo no HTML (e por isso são enfileirados mais tarde) ou até recursos que ainda nem constam no HTML (como em alguns sliders). Para obter a máxima eficácia, recomendamos inserir os preloads depois das stylesheets e antes dos scripts dentro do head da página.

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

5. Otimize os Estilos

As stylesheets costumam ser enfileiradas antes do recurso do LCP, e por um bom motivo. Sem stylesheets, o navegador não sabe como a página deve ficar e não consegue iniciar a fase de renderização. Porém, um tamanho excessivo de CSS e uma grande quantidade de stylesheets competirão com o recurso do LCP pela largura de banda inicial.

6. Implemente um Lazy Loading Eficiente

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

• Use Eager Load no Elemento do LCP: Se o elemento do LCP usar lazy loading, ele não será enfileirado pelo preload scanner e carregará bem mais tarde, impactando negativamente a performance.
• Faça Lazy Loading em Imagens da Viewport: Para imagens que estão dentro da viewport visível mas não são recursos de LCP, use loading="lazy" para colocá-las na fila de download um pouco mais tarde. Isso diminui a competição por largura de banda com o recurso do LCP.
• Evite fazer Lazy Loading de Imagens Offscreen: As imagens que não estão na viewport visível não iniciarão um download de forma alguma, o que elimina completamente a competição por largura de banda.

7. Cache do Navegador

O cache do navegador permite pular requisições de rede de recursos que já foram salvos localmente no dispositivo do usuário. Ele não vai acelerar a primeira visualização de página, mas melhora os tempos de carregamento das próximas visualizações e para visitantes recorrentes. Veja como o cache do navegador ajuda com o Resource Load Delay:

• Faça Cache de Recursos Concorrentes: Por mais que fazer o cache do próprio recurso do LCP seja uma ótima estratégia, o cache do navegador reduz os Resource Load Delays do LCP armazenando recursos de rede que poderiam concorrer ou atrasar o recurso do LCP, como scripts, stylesheets e imagens.
• Reduza a Carga no Servidor: O cache diminui a quantidade de requisições que chegam ao seu servidor. Isso pode melhorar o desempenho de outros recursos liberando largura de banda e poupando ciclos de CPU do servidor.

8. Use Speculation Rules

A API de Speculation Rules permite que os navegadores usem prefetch ou prerender de páginas web baseados nas previsões de navegação do usuário. O prefetch elimina de forma eficaz a subparte Time to First Byte do LCP e não tem impacto sobre o Resource Load Delay. O prerender renderiza a próxima página em uma aba oculta e baixa todos os recursos. Isso zera todos os load delays para o elemento do LCP, assim como mostra este exemplo de detalhamento do LCP de uma página com prerender.

9. Evite Client-Side Rendering

Próximos Passos: Continue Otimizando o LCP

O Resource Load Delay é uma das quatro fases do LCP. Depois de reduzir a latência de descoberta, siga para estes guias:

• Fix &amp;amp; Identify LCP Issues: A metodologia de diagnóstico completa para encontrar e corrigir todos os problemas de LCP.
• Optimize the LCP Image: Seleção de formato de imagem, imagens responsivas, preload e erros de imagem comuns.
• Resource Load Duration: Após o navegador descobrir o recurso, reduza o tempo que ele leva para baixar através de compressão, formatos modernos e otimização por CDN.
• Element Render Delay: Após o download do recurso, garanta que o navegador possa pintá-lo imediatamente liberando a main thread.