Otimize a duração do carregamento do recurso do LCP

Este guia faz parte da seção de Largest Contentful Paint (LCP) do nosso centro de recursos dos Core Web Vitals. A duração de carregamento do recurso é a terceira das quatro fases sequenciais do LCP e mede o tempo necessário para baixar o recurso do LCP pela rede. Embora o atraso de carregamento do recurso geralmente represente uma parte maior do tempo do LCP, otimizar a duração do download é essencial para atingir uma boa pontuação no LCP.

Otimize a duração de carregamento do recurso do LCP

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

O que é a duração de carregamento do recurso no LCP?

A duração de 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 do LCP. Para imagens e vídeos, essa duração vai do momento em que a imagem começa a ser baixada até o momento em que o navegador conclui o download. Para elementos do LCP baseados em texto, a duração do carregamento é geralmente zero. O guia de otimização do LCP do Google divide o LCP em quatro subpartes sequenciais, sendo a duração de carregamento do recurso o tempo gasto efetivamente baixando os bytes do recurso.

A duração de carregamento do recurso é medida a partir do momento em que o navegador começa a baixar o recurso do LCP até concluir o download. Quatro fatores principais determinam a duração de carregamento do recurso:

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

Como detectar a duração de carregamento do recurso

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

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

Dica profissional: Ative as linhas de requisição grandes para ver detalhes adicionais, como latência do LCP, tamanho transferido e tamanho real.

Use dados de Real User Monitoring (RUM):

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

Guia passo a passo: para uma medição precisa em laboratório, grave um trace no painel Performance. O insight de divisão do LCP mostra a duração de carregamento do recurso junto com as outras três subpartes. Passo a passo completo: Diagnostique o LCP com o painel Performance do Chrome DevTools.

Como melhorar a duração de carregamento do LCP

Problemas na duração de carregamento do recurso ocorrem quando os recursos são muito grandes ou entregues por caminhos de rede subideais. Duas abordagens principais resolvem isso: reduzir o tamanho dos dados ou otimizar a entrega dos 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, 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 imagens. O AVIF comprime fotos complexas em arquivos até 50% menores que o WebP, sem perda visível de qualidade. O WebP tem um suporte mais amplo nos navegadores e funciona bem para imagens mais simples. Segundo o Web Almanac 2025, o WebP agora é usado em mais de 40% das requisições de imagens, enquanto a adoção do AVIF praticamente dobrou de um ano para o outro, mas ainda permanece abaixo dos 10%.

Escolha a configuração de qualidade correta

Formatos de imagem modernos 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 à 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).

Automatize a compressão de imagens com o Sharp

Para a otimização de imagens 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 para os 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 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 variantes que você precisa para um elemento <picture> responsivo com suporte a formatos modernos. Para sites em 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="Description" 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. 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 tornar os tempos de carregamento visivelmente mais lentos.

Otimização de arquivos de fonte

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

• Use o formato WOFF2: O WOFF2 oferece a melhor compressão para web fonts, tipicamente 30% menor que o WOFF e significativamente menor que os arquivos TTF ou OTF.
• Faça o 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 o glyphhanger ou o pyftsubset podem automatizar isso, frequentemente reduzindo o tamanho do arquivo da fonte em 50% ou mais.
• Limite as variações da fonte: Cada peso e estilo (normal, negrito, itálico) representa um download de arquivo separado. Inclua apenas os pesos que o seu design realmente utiliza.

2. Melhore a performance da rede

Depois que os tamanhos dos recursos estiverem otimizados, o próximo passo é maximizar a velocidade da rede, ou até mesmo evitar a rede completamente.

Evite necessidades de rede com o cache do navegador

Não existe conexão de rede mais rápida do que uma conexão de rede evitada. 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 em que o recurso é considerado novo para 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 do conteúdo (por exemplo, hero-abc123.webp) para que, quando a imagem for alterada, o nome do arquivo também mude, 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 comparação a seguir ilustra a diferença:

A configuração ideal é pré-comprimir ativos estáticos com o 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 a Cloudflare, lida com isso automaticamente. Para mais detalhes sobre a configuração de CDN, veja nosso guia sobre como configurar a Cloudflare para performance.

HTTP/2 e HTTP/3: Benefícios dos protocolos modernos

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

• O HTTP/2 introduziu a multiplexação, permitindo que várias requisições e respostas sejam enviadas simultaneamente através de uma única conexão TCP. Isso elimina o problema de 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çalhos (HPACK) e server push.
• O HTTP/3 leva isso ainda mais longe 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 fluxos), proporciona o estabelecimento mais rápido de conexões através do 0-RTT (recuperação com tempo de ida e volta zero 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 a duração de carregamento do recurso.

Para verificar se o HTTP/3 está ativado, simplesmente inspecione a sua rede com o atalho Ctrl+Shift+I. Selecione a aba Network, clique com o botão direito nos cabeçalhos das colunas de rede e certifique-se de que 'protocol' está ativado. Recarregue a página e verifique o protocolo. Para HTTP/3, o protocolo deve exibir '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, a partir de locais mais próximos do usuário. Isso reduz o tempo de viagem dos dados (o tempo de ida e volta), o que afeta diretamente a duração de carregamento do recurso.

Além da proximidade, as CDNs modernas oferecem diversas vantagens de performance 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.
• Cache na borda: Recursos estáticos são armazenados em cache em nós de borda no mundo todo, eliminando totalmente a necessidade de buscar do servidor de origem.
• Otimização de protocolo: CDNs geralmente habilitam o HTTP/2 e HTTP/3 por padrão, junto com a compressão Brotli, sem exigir alterações de configuração no lado do servidor.
• Reutilização de conexões: Como a CDN serve todos os recursos a partir de um único domínio, o navegador reutiliza uma única conexão, eliminando a sobrecarga de múltiplas buscas de DNS e handshakes TLS.

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

Hospedagem própria de recursos

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

3. Otimize a priorização de recursos

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

Priorize recursos críticos

Sinalize recursos essenciais, como hero images ou o CSS above-the-fold, com fetchpriority="high". Isso instrui o navegador a baixar esses ativos primeiro, evitando que eles fiquem travados 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 do conteúdo que mais importa para os seus usuários. A combinação de preload (para resolver a descoberta tardia) e fetchpriority="high" (para resolver a contenção de rede) é a técnica mais poderosa para garantir que o recurso do LCP seja buscado o mais cedo e o mais rápido possível.

<!-- Para imagens do 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">

Reduza a contenção de rede

Otimize os downloads iniciais adiando ou aplicando lazy loading aos ativos não essenciais. Adie o carregamento de quaisquer imagens ou vídeos que não estejam imediatamente visíveis, bem como elementos de fundo ou secundários. Usar loading="lazy" para mídias fora da tela é um bom ponto de partida, enquanto adiar outros scripts e ativos não essenciais liberará largura de banda e reduzirá qualquer competição com os 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 do LCP; este é um antipadrã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 prerenderizem páginas da web com base na navegação prevista do usuário. O prefetching elimina efetivamente a subparte Time to First Byte do LCP e não tem impacto na duração de carregamento do recurso. A prerenderização 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 de carregamento para o elemento do LCP, como mostrado neste exemplo de divisão do LCP de uma página prerenderizada.

Próximos passos: Continue a otimizar o LCP

A duração de carregamento do recurso é apenas uma das quatro fases do LCP. Depois de otimizar o tempo de download, continue com as outras fases do LCP:

• Corrija e identifique problemas de LCP: A metodologia completa de diagnóstico para encontrar e corrigir todos os problemas de LCP utilizando field data e ferramentas de laboratório.
• Otimize a imagem do LCP: Seleção do formato da imagem, imagens responsivas, preloading e erros comuns de otimização de imagens.
• Atraso de carregamento do recurso: Garanta que o navegador descubra o recurso do LCP o mais cedo possível. Esse frequentemente é um gargalo maior que a própria duração do carregamento.
• Atraso de renderização do elemento: Após o download do recurso, garanta que o navegador consiga pintá-lo imediatamente liberando a main thread.