Otimizar o LCP Resource Load Delay

Este guia faz parte do hub Largest Contentful Paint (LCP). O Resource Load Delay é frequentemente o maior contribuidor individual para um mau score de LCP. A maioria das equipas foca-se em comprimir imagens quando o verdadeiro problema é que o browser encontrou a imagem demasiado tarde.

Otimizar o LCP Resource Load Delay

O Largest Contentful Paint (LCP) é composto por quatro fases: TTFB, Resource Load Delay, Resource Load Duration e Element Render Delay. Os esforços de desenvolvimento focam-se frequentemente em reduzir o Load Duration através de compressão de ficheiros, mas isso negligencia o Resource Load Delay, que é frequentemente uma fonte maior de latência. Este atraso antes do download começar pode adicionar centenas de milissegundos ao seu LCP, fazendo-o ultrapassar o limiar de 2,5 segundos para um score 'Bom'.

Uma dica rápida: se o seu LCP é uma imagem, quase sempre vai ser pior do que texto. Deve rastrear os tipos de elementos LCP nos seus dados RUM, caso contrário está a navegar às cegas.

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

O Resource Load Delay é o tempo entre o TTFB e quando o browser inicia o download do recurso LCP. Não é o tempo de download; é a latência de descoberta que ocorre antes do fetch começar. Um valor alto aqui indica um problema arquitetónico onde o browser não consegue encontrar o URL do recurso no payload HTML inicial. Este resource load delay pode ser visto como o tempo que o browser gasta a identificar que o recurso LCP é necessário e a decidir buscá-lo.

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

O Motor da Descoberta: Preload Scanner vs. DOM Parser

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

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

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

Porque é que o Load Delay Importa

Um equívoco comum é que um LCP lento é um problema de "tamanho de ficheiro". Isto leva as equipas a focarem-se apenas na compressão de imagens para reduzir o Resource Load Duration. Embora a otimização de assets seja um fator, a análise de dados de campo reais mostra que para muitos sites com LCP mau, o Resource Load Delay é o principal gargalo de desempenho, não o Resource Load Duration.

Os dados de campo mostram que o site mediano com um score de LCP mau tem um Resource Load Delay de 1,3 segundos. Isso é mais de metade do orçamento total de 2,5 segundos para um score LCP 'Bom', tudo consumido antes do download do recurso LCP sequer começar. Os dados indicam que estes sites passam quase quatro vezes mais tempo à espera que o download comece do que no próprio download.

Estes dados expõem um redirecionamento frequente do esforço de desenvolvimento. As equipas podem passar semanas a remover kilobytes das imagens para encurtar o Load Duration em alguns milissegundos, enquanto um problema arquitetónico que causa um Load Delay de 1,5 segundos permanece sem solução. O LCP é um processo sequencial; um atraso numa fase inicial não pode ser recuperado ao otimizar uma fase posterior. Se um fetch é atrasado em mais de um segundo, uma diferença de 100ms no tempo de download é irrelevante para o score final de LCP. As otimizações de maior impacto envolvem mudanças arquitetónicas, como melhorar a descoberta de recursos, não apenas compressão de assets. O foco deve mudar de tornar os assets menores para garantir que são descobertos mais cedo.

Como Detetar o Resource Load Delay

Para corrigir o Resource Load Delay, primeiro tem de medi-lo com precisão. O fluxo de trabalho profissional é primeiro definir o problema com dados de utilizadores reais (RUM), e só depois passar para o Chrome DevTools para análise aprofundada.

Passo 1: Analisar Dados de Campo (RUM)

Os dados de campo, ou Real User Monitoring (RUM), são recolhidos de sessões de utilizadores reais. Ferramentas RUM, como o Chrome User Experience Report (CrUX) público ou a minha própria ferramenta, CoreDash, respondem à pergunta: O que está a acontecer no mundo real? Uma ferramenta RUM completa também fornece uma decomposição das sub-partes do LCP, mostrando-lhe o Resource Load Delay mediano entre os seus utilizadores. Estes dados validam que um problema de LCP existe, mostram quais URLs são afetados e revelam os elementos LCP comuns que os seus utilizadores estão realmente a ver. Deve começar aqui para confirmar que está a resolver um problema real.

Passo 2: Diagnosticar com DevTools

Depois dos seus dados RUM terem identificado uma página alvo e elemento LCP, usa o Chrome DevTools para diagnosticar a causa. O objetivo aqui é reproduzir o problema e medir as sub-partes do LCP para obter um valor preciso de Resource Load Delay. O DevTools é também onde realiza uma Análise do Main Thread para ver exatamente que tarefas estão a correr e potencialmente a bloquear o processo de renderização.

Guia Passo-a-Passo para o 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é ao separador Performance.
• Certifique-se de que a caixa Web Vitals está ativada nas definições de captura. Isto irá sobrepor informações de Core Web Vitals na timeline de desempenho.
• Para simular condições realistas de utilizador, aplique throttling de CPU e Rede. Um "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. Gravar um Perfil de Performance:

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

3. Análise e Interpretação:

• Faixa de Timings: Na vista principal da timeline, localize a faixa Timings. Verá um marcador com a etiqueta LCP. Ao passar o rato sobre este marcador irá realçar o elemento LCP correspondente na captura de ecrã do viewport principal e exibir o tempo total de LCP.
• Decomposição do LCP por Fase: Clique no marcador LCP na faixa Timings. No separador Summary na parte inferior do painel, encontrará uma decomposição detalhada do timing do LCP. Esta decomposição mostra explicitamente a duração de cada uma das quatro sub-partes, incluindo o Load delay, medido em milissegundos. Este valor é a medição mais direta e precisa do Resource Load Delay para essa carga de página específica.
• Análise do Main Thread: Ao examinar a timeline, observe a faixa Main à procura de quaisquer long tasks (blocos de atividade sinalizados com um triângulo vermelho). Se estas long tasks ocorrerem após o recurso LCP ter terminado de carregar mas antes do marcador LCP, estão provavelmente a contribuir para o Element Render Delay, um problema relacionado mas distinto.

Causas Comuns e Soluções de Alto Impacto

Um Resource Load Delay alto é causado por uma de duas coisas: o recurso LCP é descoberto tarde, ou recebe uma prioridade de fetch baixa. Aqui estão os erros arquitetónicos mais comuns e as suas soluções.

Causa: LCP Carregado via CSS

O Problema: O preload scanner não analisa ficheiros CSS. Quando a sua imagem LCP é definida com um CSS background-image, o seu URL é invisível para este scanner de alta velocidade. O browser só consegue descobrir a imagem após descarregar o HTML, encontrar o link do ficheiro CSS, descarregar o ficheiro CSS, construir o CSSOM e depois aplicar o estilo. Esta cadeia de dependências causa diretamente um Resource Load Delay alto. Para mais sobre este padrão, veja o nosso guia sobre diferir background images.

A Solução: A implementação correta é evitar usar background-image para qualquer elemento LCP crítico. Use uma tag <img> padrão em vez disso. Isto coloca o URL da imagem diretamente no HTML onde o preload scanner pode encontrá-lo imediatamente. Pode obter o mesmo resultado visual com CSS.

Exemplo de Implementação:

Anti-Padrão (Não Faça Isto):

    <!-- CSS -->
   .hero {
      background-image: url('hero-image.jpg');
      height: 500px;
      width: 100%;
    }

    <!-- HTML -->
    <div class="hero"></div>
    

Melhor 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>Page Title</h1>
      </div>
    </div>

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

   .hero-background-img {
      position: absolute;
      inset: 0; /* Equivalent to top: 0; right: 0; bottom: 0; left: 0; */
      width: 100%;
      height: 100%;
      object-fit: cover; /* This property mimics background-size: cover */
      z-index: -1; /* Places the image behind other content */
    }
    

Esta implementação fornece o mesmo resultado visual mas torna a imagem LCP descoberta no momento mais cedo possível, o que minimiza o seu load delay.

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

O Problema: Aplicações que usam frameworks de client-side rendering (CSR) como React ou Vue frequentemente servem um shell HTML mínimo. O conteúdo real, incluindo a tag LCP <img>, é apenas inserido no DOM por JavaScript após os pacotes grandes do framework serem descarregados, analisados e executados. Este processo esconde fundamentalmente o recurso LCP do preload scanner, criando alta latência de descoberta.

A Solução: A solução mais eficaz é mover a renderização inicial do cliente para o servidor.

• Server-Side Rendering (SSR) ou Static Site Generation (SSG): Padrões arquitetónicos como SSR ou SSG geram o HTML completo no servidor. O browser recebe um documento completo contendo a tag <img> e o seu atributo src, tornando o recurso LCP imediatamente descoberto pelo preload scanner. Esta é a arquitetura necessária para qualquer página crítica em termos de desempenho.
• Otimizações Específicas de Framework: Os frameworks modernos também fornecem otimizações integradas. Por exemplo, o componente <Image> do Next.js tem uma propriedade priority. Definir isto como true instrui o framework a adicionar automaticamente os atributos corretos <link rel="preload"> e fetchpriority="high", garantindo que a imagem é descoberta e buscada com a prioridade correta.

Causa: Usar loading="lazy" na Imagem LCP

O Problema: Este é um erro frequente e de alto impacto. O atributo loading="lazy" é uma instrução direta ao browser para atrasar o fetch de uma imagem até estar perto do viewport. Embora esta seja a otimização correta para imagens abaixo do fold, aplicá-la a um elemento LCP acima do fold é contraproducente. O preload scanner do browser é projetado para ignorar imagens com loading="lazy", o que garante uma descoberta tardia e um Resource Load Delay alto.

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

• Remova loading="lazy" da Imagem LCP: Qualquer imagem que provavelmente seja o elemento LCP não deve ter o atributo loading="lazy". O comportamento padrão do browser é loading="eager", que é a definição correta para conteúdo crítico acima do fold. Omitir completamente o atributo loading tem o mesmo efeito.
• Audite e Configure Ferramentas de Terceiros: Também deve auditar ferramentas de terceiros. Muitas plataformas CMS como WordPress e vários plugins de otimização de imagens aplicam automaticamente lazy loading a todas as imagens. É essencial configurar estas ferramentas para excluir a imagem LCP deste comportamento. Isto frequentemente 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 largura de banda, como ícones de cabeçalho ou scripts de widgets de chat, são colocados mais acima no <body> do que o elemento LCP, são descobertos e colocados na fila de download primeiro. Isto consome largura de banda inicial e pode atrasar o download do recurso LCP. Um documento HTML grande também pode ser um problema; se o elemento LCP não está no primeiro bloco de dados que o browser recebe (cerca de 14KB), a sua descoberta é atrasada por pelo menos uma ida e volta de rede.

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

• Reordene o HTML: Quando possível, garanta que a tag <img> ou bloco de texto para o elemento LCP aparece o mais cedo possível dentro da tag <body>.
• Desprioritize Imagens Não Críticas: Para imagens não essenciais que devem aparecer cedo no código fonte HTML (como ícones num cabeçalho), aplique loading="lazy". Isto diz ao preload scanner para as ignorar, preservando a fila de download para o elemento LCP.
• Difira Scripts Não Essenciais: Scripts para analytics, publicidade ou widgets de redes sociais raramente são críticos para a renderização inicial. Mova as suas tags <script> para o final do <body> ou use o atributo defer. Isto impede-os de bloquear o parser ou competir por largura de banda com o recurso LCP.

Priorização Avançada com Resource Hints

Depois do recurso LCP ser descoberto no HTML, pode usar resource hints para dar ao browser instruções mais explícitas sobre como buscá-lo. Estes hints fornecem controlo granular sobre a descoberta e priorização.

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

<link rel="preload"> não é um hint; é uma diretiva. Força o browser a descarregar um recurso com alta prioridade, mesmo que ainda não seja descoberto pelo parser principal. Colocá-lo no <head> do seu HTML é a forma mais direta de corrigir problemas de descoberta tardia para recursos como fontes, CSS background images ou imagens LCP localizadas profundamente no DOM. Para detalhes completos de implementação e exemplos, veja o nosso guia dedicado sobre como fazer preload da imagem LCP.

Mecanismo

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

Preloading Responsivo

Um detalhe crítico de implementação é necessário ao fazer preload de imagens responsivas. Para garantir que o browser faz preload da imagem com o tamanho correto para o viewport do utilizador e evita um download duplo desperdiçado, a tag <link rel="preload"> deve incluir atributos imagesrcset e imagesizes que espelhem perfeitamente os atributos na tag <img> correspondente.

Exemplo de Preloading Responsivo:

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

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

Armadilha Potencial

O preloading resolve o timing de fetch (Load Delay e Load Duration) mas não o timing de paint. Se o main thread está bloqueado por JavaScript pesado ou CSS que bloqueia a renderização quando a imagem preloaded chega, a imagem ainda terá de 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 Browser

O atributo fetchpriority é um hint que sinaliza a importância relativa do download de um recurso. Permite-lhe influenciar a prioridade de um recurso dentro da fila de download do browser.

Como Funciona a Prioridade do Browser

Quando o browser descobre recursos durante o carregamento da página, atribui a cada um um nível de prioridade interno. Por defeito, imagens no viewport começam com prioridade "Baixa" e são depois atualizadas para "Alta" quando o browser completa o layout e determina que são visíveis. Esta atualização requer que o browser primeiro descarregue e analise o CSS, o que cria um atraso. O atributo fetchpriority="high" contorna este processo inteiramente ao definir a imagem como prioridade "Alta" desde o momento em que é descoberta. Isto é especialmente impactante para imagens LCP porque elimina o atraso de atualização de prioridade.

preload vs. fetchpriority

Estes dois hints servem propósitos diferentes mas complementares. preload afeta quando um recurso é descoberto e adicionado à fila. fetchpriority afeta o seu nível de prioridade uma vez que está na fila. Compreender esta distinção é crítico: o preload resolve a descoberta tardia, enquanto o fetchpriority resolve a baixa priorização. Para muitas imagens LCP que já estão no HTML, o fetchpriority sozinho pode ser suficiente. Para um guia completo sobre como estes interagem, veja o nosso artigo sobre priorização de recursos.

Melhor Prática para LCP

Para a imagem LCP, a estratégia ideal é usá-los juntos. Primeiro, garanta a descoberta antecipada colocando a tag <img> cedo no HTML ou usando preload. Segundo, adicione fetchpriority="high" diretamente à tag <img> (e ao link preload, se usado). Esta combinação garante que o recurso não é apenas descoberto cedo mas também recebe a maior prioridade possível para ganhar 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 é apenas para aumentar prioridade. Também pode usar fetchpriority="low" para desprioritizar recursos não críticos que competem por largura de banda com a imagem LCP. Candidatos comuns incluem imagens acima do fold que não são o elemento LCP (como pequenos ícones ou avatares no cabeçalho), e recursos preloaded que são necessários mas não urgentes. Ao baixar explicitamente a prioridade destes recursos concorrentes, cria mais espaço de largura de banda para a imagem 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

Num caso de estudo envolvendo o Google Flights, adicionar fetchpriority="high" à imagem de background LCP da página melhorou o tempo de LCP de 2,6 segundos para 1,9 segundos, uma melhoria de 700ms.

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

O Problema

Se o seu recurso LCP está alojado num domínio de terceiros, como um CDN de imagens ou um fornecedor de fontes como o Google Fonts, o browser deve estabelecer uma nova conexão de rede com esse domínio. Este processo envolve uma consulta DNS, um handshake TCP e uma negociação TLS, tudo isto deve ser completado antes do primeiro byte do recurso poder ser descarregado. Este tempo de configuração de conexão é um contribuidor direto para o Resource Load Delay de assets cross-origin.

As Soluções

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

Melhor Prática de Implementação

Para garantir compatibilidade máxima, forneça ambos os hints. O browser usará preconnect se suportado 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 prevenir o uso incorreto e clarificar os papéis distintos destes hints poderosos, a tabela seguinte fornece um resumo comparativo.

Estratégias Holísticas e Orientadas para o 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 Content Delivery Network (CDN) é uma tecnologia fundamental para desempenho web que reduz indiretamente mas significativamente o Resource Load Delay, especialmente para recursos LCP.

• Reduzir a Sobrecarga de Conexão: Ao distribuir assets por uma rede global de servidores, um CDN coloca o conteúdo geograficamente mais perto do utilizador. Isto inerentemente reduz o tempo de ida e volta (RTT) necessário para a consulta DNS, handshake TCP e negociação TLS, que são todos componentes do tempo de configuração de conexão. Para uma imagem LCP alojada num CDN, isto reduz diretamente o seu load delay.
• CDNs de Imagem: CDNs de Imagem especializados oferecem um benefício duplo. Proporcionam a vantagem de proximidade de um CDN standard enquanto também automatizam muitas otimizações complexas que reduzem o Resource Load Duration, como redimensionamento de imagens 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 usa QUIC em vez de TCP. O HTTP/3 reduz o tempo de configuração de conexão e mitiga o bloqueio head-of-line, levando a uma entrega de recursos mais rápida e eficiente no geral.

Eliminar o Delay Completamente com Speculation Rules

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

Mecanismo

Esta API permite aos programadores informar declarativamente o browser sobre quais URLs um utilizador provavelmente navegará a seguir. Com base nestas regras, o browser pode escolher prerenderizar uma página alvo num separador oculto de fundo antes do utilizador sequer clicar no link.

Impacto no LCP

Quando o utilizador clica num link para uma página prerenderizada, a navegação é virtualmente instantânea. A página já foi completamente carregada e renderizada em segundo plano. Para esta navegação, o TTFB, Resource Load Delay, Resource Load Duration e Element Render Delay são todos efetivamente reduzidos a quase zero da perspetiva do utilizador.

Exemplo de Caso de Uso

Numa página de categoria de e-commerce, as speculation rules poderiam ser usadas para prerenderizar as páginas de detalhe dos produtos para os primeiros itens da lista. Quando um utilizador clica num destes produtos, a página aparece instantaneamente.

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

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

• Caso 1: O Poder Transformador do Preloading: Uma experiência conduzida pelo DebugBear numa página com um alto load delay fornece um exemplo dramático. A imagem LCP estava escondida numa cadeia de pedidos, fazendo com que o Resource Load Delay representasse uns impressionantes 75% do tempo total de LCP. Ao implementar um único hint <link rel="preload"> para tornar a imagem descoberta cedo, o Resource Load Delay foi reduzido para apenas 2% do tempo de LCP. Isto demonstra como uma simples correção arquitetónica pode resolver um gargalo massivo de desempenho.
• Caso 2: O Anti-Padrão Real de loading="lazy": Um programador no Stack Overflow reportou um LCP de desktop com um desconcertante load delay de 1.430ms apesar de uma rede rápida. A causa foi rastreada até um plugin de otimização de imagens que estava incorretamente a aplicar lazy loading à imagem LCP ao substituir o seu atributo src por um SVG placeholder transparente. A solução definitiva foi desativar este comportamento para o elemento LCP, permitindo que fosse descoberto e carregado avidamente. Isto ilustra como ferramentas de terceiros podem inadvertidamente introduzir load delays severos.
• Caso 3: O Boost de Desempenho do fetchpriority: O caso de estudo do Google Flights fornece evidência clara para o impacto da priorização explícita. Ao simplesmente adicionar fetchpriority="high" à imagem de background LCP da página, o score de LCP melhorou em 700ms, caindo de 2,6 segundos para 1,9 segundos. Isto demonstra que mesmo quando um recurso é descoberto, sinalizar a sua alta importância ao browser é um passo crítico para ganhar a corrida pela largura de banda.

Inspeção de Rede no Chrome DevTools: Use o atalho Ctrl + Shift + I para abrir as Ferramentas de Desenvolvimento do Chrome, depois selecione o separador "Network" e recarregue a página. Observe a sequência de carregamento. O seu recurso LCP deve ser um dos primeiros itens na fila de download. Se está 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 registam dados de atribuição de LCP. Com RUM, pode visualizar a decomposição das sub-partes do LCP (ao longo do tempo ou por página), dando-lhe uma imagem clara do load delay para elementos LCP em todo o seu site ou por página. O exemplo abaixo mostra uma decomposição global de LCP juntamente com o load delay correspondente.

Como Melhorar o Load Delay

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

Dica de LCP: Compreenda o Preload Scanner: Os browsers modernos usam um mecanismo chamado preload scanner, que examina rapidamente o HTML e coloca recursos na fila de download. Se um recurso não pode ser colocado na fila pelo preload scanner, terá de esperar pelo DOM parser mais lento, resultando em atrasos. Garantir que os seus recursos LCP são descobertos pelo preload scanner pode fazer uma grande diferença na redução do load delay.

1. Otimize a Estrutura HTML

O browser (ou o preload scanner) processa o seu HTML de cima para baixo, colocando recursos na fila na ordem em que aparecem. Isto significa que quanto mais acima o recurso LCP aparece no HTML, mais cedo é colocado na fila. Para otimizar isto, remova ou difira recursos desnecessários do topo do HTML:

• Lazy-Load de Imagens Não Importantes ou Ocultas: Por vezes imagens (por exemplo bandeiras para versões específicas de idioma do seu site ou imagens no menu) são encontradas no topo do HTML do seu site. Estas imagens não são nem de perto tão importantes como o elemento LCP. Ao fazer lazy-load destas imagens, são ignoradas pelo preload scanner e colocadas na fila um pouco mais tarde durante o processo de carregamento.
• Mova scripts não importantes para o fundo da página: Mova scripts que são absolutamente não importantes para o carregamento inicial para o fundo da página para evitar que atrasem recursos críticos. Por exemplo, um widget de chat. Ninguém na história da internet alguma vez precisou de chatear antes da página estar visível!

2. Evite Background Images

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

3. Use Fetch Priority

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

O fetchpriority é geralmente 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, stylesheets ou scripts não-bloqueantes.

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

4. Implemente Preloading

O preloading altera a ordem na qual o preload scanner coloca ficheiros na fila. Coloque a tag <link rel="preload"> no head da página para instruir o browser a buscar recursos críticos, como a imagem LCP, o mais cedo possível. Preloads podem ser usados para preload de recursos que são referenciados mais tarde no HTML (e portanto são colocados na fila mais tarde) ou mesmo para preload de recursos que ainda não são referenciados no HTML (como com alguns sliders). Para máxima eficácia, recomenda-se colocar preloads após stylesheets e antes de scripts no head da página.

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

5. Otimize Estilos

Stylesheets são normalmente colocadas na fila antes do recurso LCP e isso é por boa razão. Sem stylesheets o browser não saberá como a página vai parecer e não pode iniciar a fase de renderização. No entanto, tamanho excessivo de CSS e um número excessivo de stylesheets irão competir com o recurso LCP por largura de banda inicial.

6. Implemente Lazy-Loading Eficiente

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

• Carregue Eagerly o Elemento LCP: Se o elemento LCP tem lazy-load, não será colocado na fila pelo preload scanner e carregará muito mais tarde, impactando negativamente o desempenho.
• Lazy-Load de Imagens no Viewport: Para imagens que estão no viewport visível mas não são recursos LCP, use loading="lazy" para colocá-las na fila de download ligeiramente mais tarde. Isto reduz a competição de largura de banda com o recurso LCP.
• Evite Lazy Loading de Imagens Fora do Ecrã: Imagens que não estão no viewport visível não irão desencadear nenhum download, eliminando completamente a competição de largura de banda.

7. Cache do Browser

O cache do browser permite-lhe saltar pedidos de rede para recursos que já foram armazenados localmente no dispositivo do utilizador. Embora não acelere a primeira visualização da página, irá melhorar os tempos de carregamento para visualizações subsequentes e visitantes recorrentes. Eis como o cache do browser ajuda com o resource load delay:

• Cache de Recursos Concorrentes: Embora fazer cache do recurso LCP em si seja uma ótima estratégia, o cache do browser melhora os resource load delays do LCP ao armazenar recursos de rede que podem competir com ou atrasar o recurso LCP, como scripts, stylesheets e imagens.
• Reduza a Carga do Servidor: O cache diminui o número de pedidos enviados ao seu servidor, o que pode melhorar o desempenho de outros recursos ao libertar largura de banda e reduzir ciclos de CPU do servidor.

8. Use Speculation Rules

As Speculation Rules permitem aos browsers fazer prefetch ou prerenderizar páginas web baseado em navegação prevista do utilizador. O prefetching elimina efetivamente a sub-parte Time to First Byte do LCP e não tem impacto no resource load delay. O prerendering renderiza a próxima página num separador oculto e descarrega todos os recursos da página. Isto elimina todos os load delays para o elemento LCP como mostrado neste exemplo de decomposição de LCP de uma página prerenderizada.

9. Evite Client-Side Rendering

Próximos Passos: Continue a Otimizar o LCP

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

• Corrigir e Identificar Problemas de LCP: A metodologia de diagnóstico completa para encontrar e corrigir todos os problemas de LCP.
• Otimizar a Imagem LCP: Seleção de formato de imagem, imagens responsivas, preloading e erros comuns com imagens.
• Resource Load Duration: Depois do browser descobrir o recurso, reduza quanto tempo demora a descarregar através de compressão, formatos modernos e otimização de CDN.
• Element Render Delay: Depois do recurso ser descarregado, garanta que o browser pode pintá-lo imediatamente ao limpar o main thread.