Otimize a Resource Load Duration do LCP

Este guia faz parte da seção de Largest Contentful Paint (LCP) da nossa central de Core Web Vitals. A Resource Load Duration é a terceira das quatro fases sequenciais do LCP e mede o tempo necessário para baixar o recurso do LCP pela rede. O Resource Load Delay costuma representar uma fatia maior do tempo do LCP, mas otimizar a duração do download continua essencial para alcançar uma boa pontuação de LCP.

Otimize a Resource Load Duration do LCP

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

O que é Resource Load Duration no LCP?

A Resource Load Duration, muitas vezes chamada apenas de Load Duration, é o tempo que o navegador leva para baixar o recurso de rede (como uma imagem) que se tornará o elemento do LCP. Para imagens e vídeos, essa duração vai do início do download até o momento em que o navegador conclui a transferência. Para elementos de LCP baseados em texto, a duração de carregamento costuma ser zero. O guia de otimização do LCP do Google divide o LCP em quatro subpartes sequenciais, sendo a Resource Load Duration o tempo efetivamente gasto no download dos bytes do recurso.

A Resource Load Duration é medida a partir do momento em que o navegador começa a baixar o recurso do LCP até o término do download. Quatro fatores principais determinam a Resource Load Duration:

• Tamanho do arquivo: Arquivos maiores exigem mais tempo de download.
• Velocidade da rede: Conexões mais lentas aumentam a duração do carregamento.
• Tempo de resposta do servidor: Atrasos na resposta do servidor tornam a busca do recurso mais lenta.
• Downloads simultâneos: Recursos baixados ao mesmo tempo disputam largura de banda, o que pode aumentar o tempo de carregamento.

Como detectar a Resource Load Duration

Existem duas maneiras eficazes de identificar e medir a Resource Load Duration:

Inspeção de rede no Chrome DevTools: Abra as ferramentas de desenvolvedor do Chrome com o atalho Ctrl + Shift + I, selecione a aba "Network" e recarregue a página. Localize o elemento do LCP entre as requisições de rede (se quiser identificar o elemento do LCP, experimente a extensão Core Web Vitals Visualizer). O inspetor de rede mostrará quanto tempo o recurso levou para ser baixado.

Dica: Ative as linhas de requisiçã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 costumam registrar dados de atribuição do LCP. Os dados de atribuição do Largest Contentful Paint contêm informações sobre a Resource Load Duration. Com esses dados, você pode analisar as tendências de duração ao longo do tempo ou por página e identificar as páginas ou elementos que causam lentidão.

Passo a passo: para uma medição precisa em laboratório, grave um trace no painel Performance. O insight de detalhamento do LCP mostra a Resource Load Duration ao lado das outras três subpartes. Passo a passo completo: Diagnostique o LCP com o painel Performance do Chrome DevTools.

Como melhorar a Load Duration do LCP

Problemas de Resource Load Duration acontecem quando os recursos são grandes demais ou entregues por rotas de rede pouco eficientes. Há duas abordagens principais para resolver isso: reduzir o tamanho dos dados ou otimizar a entrega.

1. Otimize o tamanho dos arquivos

Otimizar o tamanho dos arquivos reduz o volume de bytes enviados pela rede. Menos dados significam menos tempo de download. Para conferir o guia completo de otimização de imagens, veja nosso artigo sobre como otimizar imagens.

Use formatos modernos de imagem

AVIF e WebP são as melhores opções para compressão de imagens. O AVIF gera arquivos até 50% menores que o WebP em fotos complexas, sem perda perceptível de qualidade. O WebP tem compatibilidade mais ampla entre navegadores e funciona bem para imagens simples. De acordo com o Web Almanac 2025, o WebP já é usado em mais de 40% das requisições de imagem, enquanto a adoção do AVIF praticamente dobrou ano a ano, mas ainda fica abaixo de 10%.

Escolha a configuração de qualidade certa

Formatos modernos de imagem, como WebP e AVIF, permitem reduzir bastante a qualidade antes que a perda visual fique perceptível. Como regra geral, um ajuste de qualidade entre 75 e 85 no WebP, e entre 60 e 75 no AVIF, resulta em uma imagem idêntica à original em distâncias normais de visualização, mas com uma fração do tamanho do arquivo. Sempre faça testes com imagens reais do projeto, pois a qualidade ideal varia conforme o tipo de conteúdo (fotos versus ilustrações ou imagens com muito texto).

Automatize a compressão de imagens com o Sharp

Para otimizar imagens durante o build, a biblioteca sharp é uma das ferramentas mais rápidas e populares no ecossistema do Node.js. O exemplo a seguir mostra como converter e comprimir uma imagem para os formatos WebP e AVIF com configurações otimizadas de qualidade:

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 múltiplos 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 variações necessárias para um elemento <picture> responsivo compatível com formatos modernos. Em sites WordPress, plugins como ShortPixel ou Imagify fazem essa conversão automaticamente no upload.

Imagens responsivas

O elemento <picture> e o atributo srcset entregam tamanhos de imagem diferentes de acordo com a tela: versões menores para celular e resoluções mais altas para telas maiores. Veja 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 corretas da imagem

Imagens responsivas são apenas parte da solução, porque ser responsivo não significa ter o tamanho correto. Ajustar as dimensões da imagem ao tamanho em que ela é exibida é onde vejo um dos erros mais comuns. Entregar uma imagem de 2000px de largura para uma área de exibição de 500px desperdiça largura de banda e pode deixar o tempo de carregamento perceptivelmente mais lento.

Otimização de arquivos de fonte

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

• Use o formato WOFF2: O WOFF2 oferece a melhor compressão para fontes web, gerando arquivos cerca de 30% menores que o WOFF e bem menores que arquivos TTF ou OTF.
• Faça o subset das fontes: Se o 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 automatizam isso e costumam reduzir o tamanho do arquivo da fonte em 50% ou mais.
• Limite as variações de fonte: Cada peso e estilo (regular, bold, itálico) exige o download de um arquivo separado. Inclua apenas os pesos que o layout realmente utiliza.

2. Melhore a performance da rede

Com o tamanho dos recursos otimizado, o próximo passo é maximizar a velocidade da rede — ou até ignorar a rede por completo.

Evite o uso da rede com o cache do navegador

Não existe conexão de rede mais rápida do que aquela que você não precisa fazer. Os navegadores podem servir conteúdo estático (imagens, scripts, folhas de estilo) direto do cache local. Configure o servidor para enviar as instruções corretas de cache ao navegador.

A configuração mais eficiente é 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 pelo navegador quanto por caches intermediários.
• max-age=31536000: Define o tempo máximo em que o recurso é considerado atualizado como um ano (31.536.000 segundos).
• immutable: Indica que o recurso não mudará com o tempo, evitando requisições desnecessárias de revalidação.

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

Compressão Brotli vs. Gzip

Para recursos baseados em texto (HTML, CSS, JavaScript, SVG), a compressão no servidor é fundamental. O Brotli, desenvolvido pelo Google, supera o Gzip de forma consistente na taxa de compressão e mantém velocidades de descompressão comparáveis. A comparação a seguir ilustra essa diferença:

O cenário ideal é pré-comprimir recursos estáticos com Brotli em um nível de compressão alto (como o nível 11) durante o build, usando o Gzip como fallback para clientes que não são compatíveis com o Brotli. A maioria das CDNs, incluindo a Cloudflare, lida com isso de forma automática. Para conferir mais detalhes sobre a configuração de CDN, veja nosso guia sobre como configurar a Cloudflare para melhorar a performance.

HTTP/2 e HTTP/3: vantagens dos protocolos modernos

O protocolo de entrega ganha ainda mais importância quando o navegador baixa vários recursos ao mesmo tempo.

• HTTP/2 introduziu a multiplexação, permitindo enviar várias requisições e respostas simultaneamente por uma única conexão TCP. Isso elimina o problema de head-of-line blocking do HTTP/1.1, no qual um recurso lento podia travar todos os outros. O HTTP/2 também é compatível com compressão de cabeçalhos (HPACK) e server push.
• HTTP/3 vai além e substitui o TCP pelo QUIC, um protocolo baseado em UDP. O HTTP/3 elimina o head-of-line blocking no nível do TCP (onde um único pacote perdido trava todas as streams), acelera a criação de conexões com 0-RTT (Zero Round Trip Time para visitantes recorrentes) e lida muito melhor com perda de pacotes. Essas melhorias aceleram principalmente o Time to First Byte, mas também reduzem a Resource Load Duration.

Para verificar se o HTTP/3 está ativo, abra a inspeção de rede com o atalho Ctrl+Shift+I. Selecione a aba Network, clique com o botão direito no cabeçalho das colunas e certifique-se de que a opção 'protocol' esteja ativada. Recarregue a página e veja o protocolo. No caso do HTTP/3, o valor exibido deve ser 'h3'.

Content Delivery Networks (CDN)

Uma CDN é uma rede de servidores distribuídos que armazena em cache e entrega recursos estáticos como imagens, CSS e JavaScript a partir de locais mais próximos do usuário. Isso reduz o tempo de tráfego dos dados (o round-trip time), o que impacta diretamente a Resource Load Duration.

Além da proximidade física, as CDNs modernas oferecem várias vantagens de performance que reduzem a duração do carregamento:

• Otimização automática de imagens: Várias CDNs conseguem comprimir, redimensionar e converter imagens em tempo real. Por exemplo, Cloudflare Polish, Imgix e Cloudinary podem entregar WebP ou AVIF automaticamente com base no cabeçalho Accept do navegador.
• Cache na edge: Recursos estáticos ficam armazenados em cache em nós de edge pelo mundo, eliminando a necessidade de buscar arquivos no servidor de origem.
• Otimização de protocolos: As CDNs geralmente ativam HTTP/2 e HTTP/3 por padrão, além da compressão Brotli, sem exigir alterações de configuração no servidor.
• Reutilização de conexão: Como a CDN serve todos os recursos a partir de um único domínio, o navegador reaproveita a mesma conexão, eliminando o overhead de múltiplas consultas DNS e handshakes TLS.

CDNs especializadas em imagens vão além e oferecem otimizações automáticas em tempo real, como conversão de formato, redimensionamento e compressão.

Hospedagem própria de recursos

Recursos de rede essenciais e carregados no início devem, por padrão, ser sempre hospedados no servidor de origem. A auto-hospedagem elimina a necessidade de conectar a servidores de terceiros, o que evita atrasos consideráveis causados por consultas DNS extras, negociações SSL e abertura de conexões. A hospedagem própria garante o reaproveitamento de uma única conexão já aberta e reduz o overhead da criação de novas conexões. Recursos auto-hospedados também garantem controle total sobre as políticas de compressão e cache.

3. Otimize a priorização de recursos

Depois de reduzir o tamanho dos recursos e otimizar a rede, ainda resta a concorrência na rede. Quando o navegador requisita vários recursos ao mesmo tempo em uma conexão lenta, eles disputam largura de banda. Minimize essa disputa escalonando o download dos recursos.

Priorize recursos críticos

Marque recursos essenciais, como hero images ou o CSS above-the-fold, com fetchpriority="high". Isso sinaliza ao navegador para baixar esses arquivos primeiro, evitando que fiquem travados atrás de scripts, widgets ou elementos de terceiros que não precisam de carregamento imediato. Priorizar esses recursos críticos reduz o tempo de carregamento do conteúdo mais importante para o usuário. A combinação de preload (para resolver a descoberta tardia) com fetchpriority="high" (para resolver a concorrência na rede) é a técnica mais poderosa para garantir que o recurso do LCP seja baixado o mais cedo e o mais rápido possível.

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

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

Reduza a concorrência na rede

Otimize os downloads iniciais adiando ou aplicando lazy loading aos recursos não essenciais. Adie o carregamento de imagens ou vídeos que não estejam visíveis de imediato, além de elementos secundários ou de fundo. Usar loading="lazy" em mídias fora da tela é um ótimo ponto de partida. Adiar outros scripts e recursos secundários libera largura de banda e elimina a disputa com os recursos críticos, mantendo o conteúdo principal da página rápido para carregar e exibir. Nunca aplique loading="lazy" na imagem do LCP; esse é um anti-pattern grave que vai prejudicar a pontuação.

4. Configure Speculation Rules

A Speculation Rules permite que o navegador faça o prefetch ou prerender de páginas web com base na previsão de navegação do usuário. O prefetch elimina na prática a subparte de Time to First Byte do LCP e não tem impacto na Resource Load Duration. O prerender renderiza a próxima página em uma aba oculta e baixa todos os recursos dela. Isso elimina a maior parte da duração de carregamento do elemento do LCP, como mostra este detalhamento de LCP em uma página com prerender.

Próximos passos: continue otimizando o LCP

A Resource Load Duration é apenas uma das quatro fases do LCP. Depois de otimizar o tempo de download, continue com as outras fases do LCP:

• Identifique e corrija problemas de LCP: Metodologia completa de diagnóstico para identificar e corrigir todos os problemas de LCP usando field data e ferramentas de laboratório.
• Otimize a imagem do LCP: Escolha de formatos de imagem, imagens responsivas, preload e os erros mais comuns na otimização de imagens.
• Resource Load Delay: Garanta que o navegador descubra o recurso do LCP o quanto antes. Essa fase costuma ser um gargalo maior do que a própria duração de download.
• Element Render Delay: Após o download do recurso, garanta que o navegador consiga renderizá-lo imediatamente liberando a main thread.