Otimizar o LCP Resource Load Duration

Este guia faz parte da seção de Largest Contentful Paint (LCP) do nosso centro de recursos Core Web Vitals. O Resource Load Duration é a terceira das quatro fases sequenciais do LCP, medindo o tempo necessário para baixar o recurso LCP pela rede. Embora o Resource Load Delay muitas vezes represente uma parcela maior do tempo de LCP, otimizar a duração do download continua sendo essencial para alcançar uma boa pontuação de LCP.

Otimizar o LCP Resource Load Duration

O Largest Contentful Paint (LCP) é uma das três métricas de performance dos Core Web Vitals que medem a sua experiência de usuário online. O LCP captura o tempo que o maior elemento de conteúdo (uma imagem, vídeo ou bloco de texto) leva para se tornar visível no viewport. O Resource Load Duration é uma subparte do LCP que indica quanto tempo é gasto buscando o recurso de rede para o elemento LCP.

O que é Resource Load Duration no LCP?

O Resource Load Duration, frequentemente chamado de Load Duration, refere-se ao tempo necessário para o navegador baixar o recurso de rede (por exemplo, uma imagem) que eventualmente se tornará o elemento LCP. Para imagens e vídeos, essa duração abrange desde o momento em que a imagem começa a ser baixada até que o navegador complete o download. Para elementos LCP baseados em texto, a duração do carregamento é tipicamente zero. O guia de otimização de LCP do Google divide o LCP em quatro subpartes sequenciais, sendo o Resource Load Duration o tempo gasto baixando efetivamente os bytes do recurso.

O Resource Load Duration é medido desde o momento em que o navegador começa a baixar o recurso LCP até que ele termine de ser baixado. Quatro fatores principais determinam a duração do carregamento do recurso:

• Tamanho do Arquivo: Arquivos maiores exigem tempos de download mais longos.
• Velocidade da Rede: Conexões mais lentas estendem naturalmente a duração do carregamento.
• Capacidade de Resposta do Servidor: Atrasos na resposta do servidor tornam a busca de recursos mais lenta.
• Downloads Simultâneos: Recursos baixados simultaneamente competem pela largura de banda, o que pode aumentar os tempos de carregamento.

Como Detectar o Resource Load Duration

Existem duas formas eficazes de identificar e medir a duração do carregamento do recurso:

Inspeção de Rede no Chrome DevTools: Use o atalho Ctrl + Shift + I para abrir as Developer Tools do Chrome, selecione a aba "Network" e recarregue a página. Procure pelo elemento LCP nas solicitações de rede (se quiser saber o elemento LCP, tente o Core Web Vitals Visualizer). O inspetor de rede mostrará quanto tempo levou para baixar o recurso.

Dica Pro: Habilite as linhas de solicitação grandes para ver detalhes adicionais, como a latência do LCP, o tamanho transferido e o tamanho real.

Use Dados de Real User Monitoring (RUM):

Ferramentas de RUM frequentemente registram dados de atribuição de LCP. Os dados de atribuição para o Largest Contentful Paint contêm informações sobre o resource load duration. Com esses dados, você pode mapear tendências de duração de carregamento ao longo do tempo ou por página e identificar as páginas ou elementos que tornam as coisas lentas.

Como Melhorar o LCP Load Duration

Problemas de duração de carregamento de recursos acontecem quando os recursos são muito grandes ou entregues através de caminhos de rede sub-otimizados. Duas abordagens principais tratam disso: reduzir o tamanho dos dados ou otimizar a entrega dos dados.

1. Otimizar o Tamanho do Arquivo

Otimizar o tamanho do arquivo reduz o número de bytes a serem enviados pela rede. Menos dados significam menos tempo de download. Para um guia completo de otimização de imagem, veja nosso artigo sobre como otimizar imagens.

Use Formatos de Imagem Modernos

AVIF e WebP são as melhores opções para compressão de imagem. O AVIF comprime até 50% menos que o WebP para fotos complexas, sem perda de qualidade visível. O WebP tem suporte mais amplo do navegador e funciona bem para imagens mais simples. De acordo com o 2025 Web Almanac, o WebP agora é usado em mais de 40% das solicitações de imagem, enquanto a adoção do AVIF quase dobrou ano após ano, mas ainda permanece abaixo de 10%.

Escolhendo a Configuração de Qualidade Correta

Formatos de imagem modernos como WebP e AVIF permitem uma redução significativa da qualidade antes que a degradação visual se torne perceptível. Como regra geral, uma configuração de qualidade entre 75 e 85 para WebP, e entre 60 e 75 para AVIF, parecerá idêntica ao original em distâncias normais de visualização, mas com uma fração do tamanho do arquivo. Sempre teste com suas imagens específicas, pois a qualidade ideal depende do tipo de conteúdo (fotografias vs. ilustrações vs. imagens com muito texto).

Automatizando a Compressão de Imagem com Sharp

Para otimização de imagem em tempo de build, a biblioteca sharp é uma das ferramentas mais rápidas e amplamente utilizadas no ecossistema Node.js. O exemplo a seguir mostra como converter e comprimir uma imagem nos formatos WebP e AVIF com configurações de qualidade otimizadas:

const sharp = require('sharp');

// Converter para WebP com qualidade otimizada
await sharp('input.jpg')
  .resize(1200)  // Redimensionar para a largura máxima necessária
  .webp({ quality: 80, effort: 6 })
  .toFile('output.webp');

// Converter para AVIF com qualidade otimizada
await sharp('input.jpg')
  .resize(1200)
  .avif({ quality: 65, effort: 6 })
  .toFile('output.avif');

// Gerar vários tamanhos para imagens responsivas
const widths = [400, 800, 1200];
for (const width of widths) {
  await sharp('input.jpg')
    .resize(width)
    .webp({ quality: 80 })
    .toFile(`output-${width}w.webp`);
}

Essa abordagem gera todas as variantes necessárias para um elemento <picture> responsivo com suporte a formatos modernos. Para sites WordPress, plugins como ShortPixel ou Imagify lidam com essa conversão automaticamente no upload.

Imagens Responsivas

O elemento <picture> e o atributo srcset servem tamanhos de imagem diferentes com base na tela: versões menores para mobile, resolução mais alta para telas maiores. Aqui está um exemplo de configuração:

<picture>
  <source media="(min-width: 800px)" srcset="large.jpg 1x, larger.jpg 2x">
  <img src="photo.jpg" alt="Descrição" width="800" height="450">
</picture>

Dimensões de Imagem Corretas

Imagens responsivas são apenas parte da solução porque responsivo não significa que elas estão no tamanho certo. Combinar as dimensões da imagem com o seu tamanho de exibição é um dos erros mais comuns que vejo. Servir uma imagem de 2000px de largura para uma área de exibição de 500px desperdiça largura de banda e pode retardar visivelmente os tempos de carregamento.

Otimização de Arquivo de Fonte

Quando o elemento LCP é um texto renderizado com uma fonte web personalizada, o arquivo da fonte torna-se o recurso LCP. Otimize a duração do carregamento da fonte:

• Use o formato WOFF2: O WOFF2 oferece a melhor compressão para fontes web, tipicamente 30% menor que o WOFF e significativamente menor que arquivos TTF ou OTF.
• Faça subset das suas fontes: Se o seu site usa apenas caracteres latinos, faça o subset da fonte para remover conjuntos de caracteres não utilizados (cirílico, grego, CJK). Ferramentas como glyphhanger ou pyftsubset podem automatizar isso, reduzindo frequentemente o tamanho do arquivo da fonte em 50% ou mais.
• Limite as variações de fonte: Cada peso e estilo (regular, negrito, itálico) é um download de arquivo separado. Inclua apenas os pesos que seu design realmente utiliza.

2. Melhorar a Performance da Rede

Uma vez que os tamanhos dos recursos estão otimizados, o próximo passo é maximizar a velocidade da rede, ou até mesmo ignorar a rede completamente.

Ignore as Necessidades de Rede com o Cache do Navegador

Não há conexão de rede mais rápida do que uma conexão de rede ignorada. Os navegadores podem servir conteúdo estático (imagens, scripts, folhas de estilo) diretamente do cache local. Configure o servidor para enviar instruções de cache corretas para o navegador.

A configuração mais eficaz é enviar um cabeçalho Cache-Control como este:

Cache-Control: public, max-age=31536000, immutable

• public: Permite que o recurso seja armazenado em cache tanto pelos navegadores quanto por caches intermediários.
• max-age=31536000: Define o tempo máximo que o recurso é considerado novo para um ano (31.536.000 segundos).
• immutable: Indica que o recurso não mudará com o tempo, evitando solicitações de revalidação desnecessárias.

Para que essa estratégia funcione com segurança, use nomes de arquivo com hash de conteúdo (por exemplo, hero-abc123.webp) para que, quando a imagem mudar, o nome do arquivo mude também, invalidando o cache automaticamente.

Compressão Brotli vs. Gzip

Para recursos baseados em texto (HTML, CSS, JavaScript, SVG), a compressão no lado do servidor é essencial. O Brotli, desenvolvido pelo Google, supera consistentemente o Gzip na taxa de compressão, mantendo velocidades de descompressão comparáveis. A seguinte comparação ilustra a diferença:

A configuração ideal é pré-comprimir ativos estáticos com Brotli em um nível de compressão alto (por exemplo, nível 11) durante o seu processo de build e usar o Gzip como fallback para clientes que não suportam Brotli. A maioria dos CDNs, incluindo o Cloudflare, lida com isso automaticamente. Para mais detalhes sobre a configuração de CDN, veja nosso guia sobre como configurar o Cloudflare para performance.

HTTP/2 e HTTP/3: Benefícios dos Protocolos Modernos

O protocolo de entrega importa mais quando o navegador baixa vários recursos ao mesmo tempo.

• HTTP/2 introduziu a multiplexação, permitindo que várias solicitações e respostas sejam enviadas simultaneamente sobre uma única conexão TCP. Isso elimina o problema de bloqueio head-of-line do HTTP/1.1, onde um recurso lento poderia atrasar todos os outros. O HTTP/2 também suporta compressão de cabeçalho (HPACK) e server push.
• HTTP/3 vai além ao substituir o TCP pelo QUIC, um protocolo baseado em UDP. O HTTP/3 elimina o bloqueio head-of-line no nível do TCP (onde um único pacote perdido interrompe todos os fluxos), fornece estabelecimento de conexão mais rápido através de 0-RTT (Zero Round Trip Time para visitantes recorrentes) e lida com a perda de pacotes de forma mais elegante. Essas melhorias aceleram principalmente o Time to First Byte, mas também reduzem o resource load duration.

Para verificar se o HTTP/3 está habilitado, basta inspecionar sua rede com o atalho Ctrl+Shift+I. Selecione a aba de rede, clique com o botão direito nos cabeçalhos das colunas de rede e certifique-se de que 'protocol' esteja habilitado. Recarregue a página e verifique o protocolo. Para HTTP/3, o protocolo deve constar como 'h3'.

Content Delivery Networks (CDN)

Um CDN é uma rede de servidores distribuídos que armazenam em cache e servem recursos estáticos como imagens, CSS e JavaScript de locais mais próximos do usuário. Isso reduz o tempo de viagem dos dados (o round-trip time), o que afeta diretamente o Resource Load Duration.

Além da proximidade, os CDNs modernos oferecem várias vantagens de performance que reduzem a duração do carregamento:

• Otimização automática de imagem: Muitos CDNs podem comprimir, redimensionar e converter imagens dinamicamente. Por exemplo, o Cloudflare Polish, Imgix e Cloudinary podem servir WebP ou AVIF automaticamente com base no cabeçalho Accept do navegador.
• Edge caching: Recursos estáticos são armazenados em cache nos nós de borda em todo o mundo, eliminando a necessidade de buscar no servidor de origem inteiramente.
• Otimização de protocolo: Os CDNs normalmente habilitam HTTP/2 e HTTP/3 por padrão, juntamente com a compressão Brotli, sem exigir alterações na configuração do lado do servidor.
• Reutilização de conexão: Como o CDN serve todos os recursos de um único domínio, o navegador reutiliza uma única conexão, eliminando o overhead de múltiplas pesquisas DNS e TLS handshakes.

CDNs de Imagem especializados podem ir além ao fornecer otimizações automáticas em tempo real, como conversão de formato, redimensionamento e compressão.

Auto-hospedagem de Recursos

Recursos de rede importantes e iniciais devem, por padrão, ser sempre hospedados no servidor de origem. A auto-hospedagem evita a necessidade de se conectar a servidores de terceiros, o que pode causar atrasos consideráveis devido a pesquisas DNS adicionais, negociações SSL e configurações de conexão. A auto-hospedagem garante a reutilização de uma única conexão já aberta e reduz o overhead de estabelecer conexões separadas. Recursos auto-hospedados também permitem o controle total sobre as políticas de compressão e cache.

3. Otimizar a Priorização de Recursos

Após reduzir o tamanho do recurso e otimizar a rede, há também o problema da competição de rede. Quando o navegador solicita vários recursos ao mesmo tempo em uma conexão lenta, eles competem pela largura de banda. Minimize essa competição agendando os downloads de recursos.

Priorizar Recursos Críticos

Sinalize recursos essenciais, como imagens hero ou CSS acima da dobra, com fetchpriority="high". Isso sinaliza para o navegador baixar esses ativos primeiro, evitando que fiquem atolados por scripts, widgets ou elementos de terceiros que não precisam de carregamento instantâneo. Priorizar esses recursos críticos reduz o tempo de carregamento para o conteúdo que seus usuários mais se importam. A combinação de preload (para resolver a descoberta tardia) e fetchpriority="high" (para resolver a competição de rede) é a técnica mais poderosa para garantir que o recurso LCP seja buscado o mais cedo e o mais rápido possível.

<!-- Para imagens LCP visíveis no HTML inicial -->
<img src="hero-image.webp" fetchpriority="high" alt="...">

<!-- Para melhorar a descoberta  -->
<link rel="preload" href="hero-image.webp" as="image" fetchpriority="high">

Reduzir a Competição de Rede

Agilize os downloads iniciais adiando ou carregando tardiamente (lazy-loading) ativos não essenciais. Adie o carregamento de quaisquer imagens ou vídeos não visíveis imediatamente, bem como elementos de fundo ou secundários. Usar loading="lazy" para mídia fora da tela é um bom começo, enquanto adiar ainda mais outros scripts e ativos não essenciais liberará largura de banda e reduzirá qualquer competição com seus recursos críticos, mantendo o conteúdo principal da sua página rápido para carregar e exibir. Nunca aplique loading="lazy" à sua imagem LCP; este é um anti-padrão crítico que prejudicará sua pontuação.

4. Configurar 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 Time to First Byte do LCP e não tem impacto no resource load duration. O prerender renderiza a próxima página em uma aba oculta e baixa todos os recursos da página. Isso elimina a maior parte da duração do carregamento para o elemento LCP, como mostrado neste exemplo de detalhamento do LCP de uma página pré-renderizada.

Próximas Etapas: Continue Otimizando o LCP

O Resource Load Duration é apenas uma das quatro fases do LCP. Após otimizar o tempo de download, continue com as outras fases do LCP:

• Identificar e Corrigir Problemas de LCP: A metodologia de diagnóstico completa para encontrar e corrigir todos os problemas de LCP usando dados de campo e ferramentas de laboratório.
• Otimizar a Imagem LCP: Seleção de formato de imagem, imagens responsivas, preloading e erros comuns de otimização de imagem.
• Resource Load Delay: Garanta que o navegador descubra o recurso LCP o mais cedo possível. Isso costuma ser um gargalo maior do que a própria duração da carga.
• Element Render Delay: Após o download do recurso, garanta que o navegador possa pintá-lo imediatamente limpando a thread principal.