Otimize a Duração do Carregamento do Recurso da LCP

Este guia faz parte da seção Largest Contentful Paint (LCP) do nosso centro de recursos Core Web Vitals. A Duração do Carregamento do Recurso é a terceira de quatro fases sequenciais da LCP, medindo o tempo que leva para baixar o recurso da LCP pela rede. Embora o Resource Load Delay frequentemente represente uma fatia maior do tempo da LCP, otimizar a duração do download continua sendo essencial para alcançar uma boa pontuação de LCP.

Otimize a Duração do Carregamento do Recurso da LCP

A Largest Contentful Paint (LCP) é uma das três métricas de desempenho Core Web Vitals que medem sua user experience online. A LCP captura o tempo que leva para o maior elemento de conteúdo (uma imagem, vídeo ou bloco de texto) se tornar visível na viewport. A Duração do Carregamento do Recurso é uma subparte da LCP que indica quanto tempo é gasto buscando o recurso de rede para o elemento da LCP.

O que é a Duração do Carregamento do Recurso na LCP?

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

A Duração do Carregamento do Recurso é medida do momento em que o navegador começa a baixar o recurso da LCP até terminar de baixá-lo. 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 desaceleram a busca de recursos.
• Downloads Concorrentes: Recursos baixados simultaneamente competem por largura de banda, o que pode aumentar os tempos de carregamento.

Como Detectar a Duração do Carregamento do Recurso

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

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

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

Use Dados de Real User Monitoring (RUM):

As ferramentas de RUM frequentemente registram dados de atribuição da LCP. Os dados de atribuição para a Largest Contentful Paint contêm informações sobre a duração do carregamento do recurso. Com esses dados, você pode criar gráficos das tendências de duração de carregamento ao longo do tempo ou por página e identificar as páginas ou elementos que atrasam as coisas.

Como Melhorar a Duração do Carregamento da LCP

Problemas com a duração do carregamento de recursos ocorrem quando os recursos são grandes demais ou entregues por caminhos de rede subideais. Duas abordagens principais resolvem isso: reduzir o tamanho dos dados ou otimizar a entrega de dados.

1. Otimize 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 sobre otimização de imagens, consulte nosso artigo sobre como otimizar imagens.

Use Formatos Modernos de Imagem

AVIF e WebP são as melhores opções para compressão de imagem. O AVIF comprime até 50% mais que o WebP para fotos complexas, sem perda de qualidade visível. O WebP tem um suporte mais amplo nos navegadores e funciona bem para imagens mais simples. De acordo com o Web Almanac 2025, o WebP agora é usado em mais de 40% das requisições de imagens, enquanto a adoção do AVIF quase dobrou em relação ao ano anterior, mas ainda se mantém abaixo de 10%.

Escolhendo a Configuração de Qualidade Certa

Formatos modernos de imagem como WebP e AVIF permitem uma redução significativa na qualidade antes que a degradação visual se torne perceptível. Como regra geral, uma configuração de qualidade entre 75 e 85 para o WebP e entre 60 e 75 para o AVIF parecerá idêntica ao original em distâncias normais de visualização, mas com uma fração do tamanho do arquivo. Teste sempre 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 Imagens com Sharp

Para otimização de imagens no 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 tanto para o formato WebP quanto para o AVIF com configurações de qualidade otimizadas:

const sharp = require('sharp');

// Convert to WebP with optimized quality
await sharp('input.jpg')
  .resize(1200)  // Resize to maximum needed width
  .webp({ quality: 80, effort: 6 })
  .toFile('output.webp');

// Convert to AVIF with optimized quality
await sharp('input.jpg')
  .resize(1200)
  .avif({ quality: 65, effort: 6 })
  .toFile('output.avif');

// Generate multiple sizes for responsive images
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 que você precisa 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 fornecem tamanhos de imagem diferentes com base na tela: versões menores para mobile, e resoluções mais altas 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="Description" width="800" height="450">
</picture>

Dimensões Corretas da Imagem

Imagens responsivas são apenas parte da solução, pois ser responsivo não significa ter o 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 com 2000px de largura para uma área de exibição de 500px desperdiça largura de banda e pode atrasar consideravelmente os tempos de carregamento.

Otimização de Arquivo de Fonte

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

• Usando o formato WOFF2: O WOFF2 oferece a melhor compressão para web fonts, sendo normalmente 30% menor que o WOFF e significativamente menor que os arquivos TTF ou OTF.
• Fazendo subsetting de suas fontes: Se o seu site usar apenas caracteres latinos, faça o subsetting (subconjunto) da fonte para remover conjuntos de caracteres não utilizados (Cirílico, Grego, CJK). Ferramentas como glyphhanger ou pyftsubset podem automatizar isso, reduzindo muitas vezes o tamanho do arquivo da fonte em 50% ou mais.
• Limitando as variações da fonte: Cada peso e estilo (regular, negrito, itálico) é um download de arquivo separado. Inclua apenas os pesos que o seu design realmente utiliza.

2. Melhore o Desempenho 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 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 as 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 colocado em cache tanto por navegadores quanto por caches intermediários.
• max-age=31536000: Define o tempo máximo pelo qual o recurso é considerado novo como um ano (31.536.000 segundos).
• immutable: Indica que o recurso não mudará com o tempo, prevenindo solicitações desnecessárias de revalidação.

Para que essa estratégia funcione com segurança, use nomes de arquivo baseados no hash do conteúdo (por exemplo, hero-abc123.webp) para que, quando a imagem mudar, o nome do arquivo também mude, quebrando 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 em taxa de compressão, mantendo velocidades de descompressão comparáveis. A comparação a seguir ilustra a diferença:

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

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

O protocolo de entrega importa mais quando o navegador faz o download de múltiplos recursos ao mesmo tempo.

• HTTP/2 introduziu a multiplexação, permitindo que múltiplas requisições e respostas fossem enviadas simultaneamente através de uma única conexão TCP. Isso elimina o problema do head-of-line blocking 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 head-of-line blocking no nível do TCP (onde um único pacote perdido paralisa todos os streams), oferece um estabelecimento de conexão mais rápido através de 0-RTT (retomada de Zero Round Trip Time para visitantes recorrentes) e lida com a perda de pacotes de forma mais eficiente. Essas melhorias aceleram principalmente o Time to First Byte, mas também reduzem a duração do carregamento de recursos.

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

Content Delivery Networks (CDN)

Uma 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 ao usuário. Isso reduz o tempo de viagem dos dados (o tempo de ida e volta), o que afeta diretamente a Duração do Carregamento do Recurso.

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

• Otimização automática de imagens: Muitas CDNs podem comprimir, redimensionar e converter imagens em tempo real. Por exemplo, 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 edge nodes pelo mundo todo, eliminando totalmente a necessidade de busca no servidor de origem.
• Otimização de protocolo: CDNs geralmente habilitam HTTP/2 e HTTP/3 por padrão, juntamente com a compressão Brotli, sem exigir alterações de configuração no lado do servidor.
• Reutilização de conexão: Como a CDN serve todos os recursos de um único domínio, o navegador reutiliza uma única conexão, eliminando a sobrecarga de múltiplas pesquisas DNS e TLS handshakes.

As CDNs de Imagens Especializadas podem levar isso ainda mais longe, fornecendo otimizações automáticas em tempo real, como conversão de formato, redimensionamento e compressão.

Self-Hosting de Recursos

Recursos de rede importantes e iniciais devem, por padrão, ser sempre hospedados no servidor de origem. O self-hosting contorna 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. O self-hosting garante a reutilização de uma única conexão já aberta e reduz a sobrecarga do estabelecimento de conexões separadas. Os recursos self-hosted também permitem controle total sobre a compressão e as políticas de cache.

3. Otimize a Priorização de Recursos

Depois de reduzir o tamanho do recurso e otimizar a rede, há também a questão da concorrência da rede. Quando o navegador solicita vários recursos ao mesmo tempo em uma conexão lenta, eles competem pela largura de banda. Minimize essa concorrência programando os downloads de recursos.

Priorize Recursos Críticos

Marque recursos essenciais, como hero images ou CSS above-the-fold, com fetchpriority="high". Isso sinaliza para o navegador fazer o download desses assets primeiro, impedindo que eles fiquem atolados por scripts, widgets ou elementos de terceiros que não precisam de um carregamento instantâneo. Priorizar esses recursos críticos reduz o tempo de carregamento do conteúdo com o qual os seus usuários mais se importam. A combinação de preload (para resolver a descoberta tardia) e fetchpriority="high" (para resolver a disputa de rede) é a técnica mais poderosa para garantir que o recurso da LCP seja buscado o mais cedo e o mais rápido possível.

<!-- For LCP images visible in the initial HTML -->
<img src="hero-image.webp" fetchpriority="high" alt="...">

<!-- To improve discovery  -->
<link rel="preload" href="hero-image.webp" as="image" fetchpriority="high">

Reduza a Disputa de Rede

Otimize os downloads iniciais adiando ou fazendo o lazy-loading de assets não essenciais. Adie o carregamento de quaisquer imagens ou vídeos que não sejam imediatamente visíveis, bem como elementos de fundo ou secundários. Usar loading="lazy" para mídias fora da tela é um bom começo, enquanto o adiamento adicional de outros scripts e assets não essenciais liberará largura de banda e reduzirá qualquer concorrência 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 da LCP; este é um anti-padrão crítico que prejudicará a sua pontuação.

4. Configure as Speculation Rules

As Speculation Rules permitem que os navegadores façam o prefetch ou o prerender de páginas da web com base na navegação prevista do usuário. O prefetching elimina efetivamente a subparte Time to First Byte da LCP e não tem impacto na duração do carregamento do recurso. O prerendering renderiza a próxima página em uma guia oculta e baixa todos os recursos da página. Isso elimina a maior parte das durações de carregamento do elemento da LCP, conforme mostrado neste exemplo de divisão da LCP de uma página pré-renderizada.

Próximos Passos: Continue Otimizando a LCP

A Duração do Carregamento do Recurso é apenas uma das quatro fases da LCP. Depois de otimizar o tempo de download, continue com as outras fases da LCP:

• Corrija e Identifique Problemas na 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.
• Otimize a Imagem da LCP: Seleção de formato de imagem, imagens responsivas, preloading e erros comuns na otimização de imagens.
• Resource Load Delay: Garanta que o navegador descubra o recurso da LCP o mais cedo possível. Isso costuma ser um gargalo maior que a própria duração do carregamento.
• Element Render Delay: Após o download do recurso, certifique-se de que o navegador possa pintá-lo imediatamente, liberando a main thread.