Otimize a duração do carregamento do recurso LCP

Este guia faz parte da seção Largest Contentful Paint (LCP) do nosso centro de recursos sobre Core Web Vitals. A Duração do Carregamento do Recurso é a terceira de quatro fases sequenciais do LCP. Ela mede o tempo necessário para baixar o recurso do LCP pela rede. O Atraso no Carregamento do Recurso costuma representar a maior parte do tempo do LCP. Ainda assim, otimizar a duração do download é essencial para atingir uma boa pontuação no LCP.

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

O Largest Contentful Paint (LCP) é uma das três métricas de desempenho do Core Web Vitals que medem a sua experiência do usuário online. 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 do Carregamento do Recurso é uma subparte do LCP. Ela indica quanto tempo é gasto buscando o recurso de rede para o elemento do LCP.

O que é a Duração do Carregamento do Recurso no 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 (ex., uma imagem) que se tornará o elemento do LCP. Para imagens e vídeos, essa duração vai do início do download da imagem até o navegador concluir a transferência. Para elementos do LCP baseados em texto, a duração do carregamento é tipicamente zero. O guia de otimização do LCP do Google divide o LCP em quatro subpartes sequenciais. A Duração do Carregamento do Recurso é o tempo realmente gasto baixando os bytes do recurso.

A Duração do Carregamento do Recurso é medida desde o momento em que o navegador começa a baixar o recurso do LCP até ele terminar o download. Quatro fatores principais determinam essa duração:

• 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 lentificam a busca do recurso.
• Downloads Concorrentes: Recursos baixados simultaneamente competem por largura de banda. Isso pode aumentar os tempos de carregamento.

Como Detectar a Duração do Carregamento do Recurso

Existem duas maneiras 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 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 quiser saber qual é o elemento do LCP, experimente 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 ("large request rows") 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 para o Largest Contentful Paint contêm informações sobre a duração do carregamento do recurso. Com esses dados, você pode mapear tendências de duração do carregamento ao longo do tempo ou por página e identificar as páginas ou os elementos que tornam as coisas mais lentas.

Guia 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 duração do carregamento do recurso ao lado das outras três subpartes. Passo a passo completo: Diagnostique o LCP com o painel Performance do Chrome DevTools.

Como Melhorar a Duração do Carregamento do LCP

Problemas na duração do carregamento do recurso acontecem quando os recursos são grandes demais ou entregues por caminhos de rede subotimizados. 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 significa menos tempo de download. Para um guia completo sobre 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 comprime até 50% mais que o WebP em fotos complexas, sem perda de qualidade visível. 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 imagem. A adoção do AVIF praticamente dobrou de um ano para o outro, mas ainda está abaixo de 10%.

Escolhendo a Configuração de Qualidade Certa

Formatos de imagem modernos como WebP e AVIF permitem uma redução considerável de qualidade antes que a degradação visual fique 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 à original em distâncias normais de visualização. Tudo isso com uma fração do tamanho do arquivo. Teste sempre com as suas imagens. 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 momento do build, a biblioteca sharp é uma das ferramentas mais rápidas e usadas 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');

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

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

// Gera 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 necessárias para um elemento <picture> responsivo com suporte a formatos modernos. Em sites WordPress, plugins como ShortPixel ou Imagify lidam com essa conversão automaticamente no momento do 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çõ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="Description" width="800" height="450">
</picture>

Dimensões Corretas da Imagem

Imagens responsivas são apenas parte da solução. Responsivo não significa ter o tamanho correto. Não igualar as dimensões da imagem ao seu tamanho de exibição é um dos erros mais comuns que vejo em campo. Servir uma imagem com 2000px de largura para uma área de exibição de 500px desperdiça largura de banda e pode desacelerar os tempos de carregamento de forma perceptível.

Otimização do Arquivo de Fonte

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

• Use o formato WOFF2: O WOFF2 oferece a melhor compressão para web fonts. Ele costuma ser 30% menor que o WOFF e significativamente menor que arquivos TTF ou OTF.
• Faça o subsetting das suas fontes: Se o seu site usa apenas caracteres latinos, aplique subsetting na fonte para remover conjuntos de caracteres não usados (Cirílico, Grego, CJK). Ferramentas como glyphhanger ou pyftsubset automatizam isso. Elas costumam reduzir o tamanho do arquivo da fonte em 50% ou mais.
• Limite as variações da fonte: Cada peso e estilo (regular, negrito, itálico) representa um download separado. Inclua apenas os pesos que seu design realmente usa.

2. Melhore o Desempenho da Rede

Com os tamanhos dos recursos otimizados, o próximo passo é maximizar a velocidade da rede. Ou até mesmo evitar a rede por completo.

Evite a Necessidade de Rede com o Cache do Navegador

Não existe conexão de rede mais rápida do que aquela que foi evitada. Os navegadores podem servir conteúdo estático (imagens, scripts, stylesheets) diretamente do cache local. Configure o servidor para enviar instruções corretas de cache para o navegador.

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

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

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

Para essa estratégia funcionar com segurança, use nomes de arquivo com hash de conteúdo (ex., hero-abc123.webp). Assim, quando a imagem mudar, o nome do arquivo também muda, 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 o Gzip consistentemente em taxa de compressão. Ao mesmo tempo, ele mantém 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 Brotli em um nível de compressão alto (ex., nível 11) durante o seu processo de build. Use 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 CDNs, veja nosso guia sobre como configurar a Cloudflare para desempenho.

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

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

• HTTP/2 introduziu a multiplexação. Isso permite o envio de múltiplas requisições e respostas simultaneamente pela mesma conexão TCP. Isso elimina o problema de head-of-line blocking do HTTP/1.1, onde um recurso lento podia atrasar todos os outros. O HTTP/2 também suporta compressão de headers (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 paralisa todos os fluxos). Ele oferece um estabelecimento de conexão mais rápido com o 0-RTT (retomada com Zero Round Trip Time para visitantes recorrentes) e lida com a perda de pacotes de forma mais suave. Essas melhorias aceleram principalmente o Time to First Byte. Elas também reduzem a duração do carregamento do recurso.

Para verificar se o HTTP/3 está ativo, inspecione sua rede com o atalho Ctrl+Shift+I. Selecione a aba network, clique com o botão direito nos cabeçalhos das colunas e certifique-se de que a opção 'protocol' está ativada. Recarregue a página e verifique o protocolo. Para HTTP/3, o protocolo deve ser '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 do usuário. Isso reduz o tempo de viagem dos dados (o round-trip time). Isso afeta diretamente a Duração do Carregamento do Recurso.

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

• Otimização automática de imagens: Muitas CDNs conseguem comprimir, redimensionar e converter imagens na hora (on the fly). Por exemplo, Cloudflare Polish, Imgix e Cloudinary podem servir WebP ou AVIF automaticamente com base no header Accept do navegador.
• Edge caching: Recursos estáticos são cacheados em edge nodes ao redor do mundo. Isso elimina a necessidade de buscar os arquivos no servidor de origem.
• Otimização de protocolo: CDNs geralmente ativam HTTP/2 e HTTP/3 por padrão, junto com a compressão Brotli. Nenhuma mudança na configuração do lado do servidor é necessária.
• Reúso de conexão: Como a CDN serve todos os recursos de um único domínio, o navegador reutiliza uma única conexão. Isso elimina a sobrecarga de múltiplas buscas de DNS e handshakes TLS.

Image CDNs especializadas vão ainda mais longe. Elas fornecem otimizações automáticas e em tempo real, como conversão de formato, redimensionamento e compressão.

Self-Hosting de Recursos

Recursos de rede importantes e carregados cedo devem, por padrão, ser sempre hospedados no servidor de origem. O self-hosting evita a conexão a servidores de terceiros. Essas conexões podem causar atrasos consideráveis devido a buscas extras de DNS, negociações SSL e configurações de conexão. O self-hosting garante o reúso de uma conexão única e já aberta. Ele também reduz a sobrecarga de estabelecer conexões separadas. Recursos com self-hosting dão controle total sobre políticas de compressão e cache.

3. Otimize a Priorização de Recursos

Após reduzir o tamanho do recurso e otimizar a rede, sobra a questão da competição de rede. Quando o navegador solicita vários recursos ao mesmo tempo em uma conexão lenta, eles competem por largura de banda. Minimize essa competição 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 baixar esses ativos primeiro. Isso evita que eles fiquem retidos 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 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. Ela garante 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

Agilize os downloads iniciais ao aplicar defer ou lazy loading a ativos não essenciais. Adie o carregamento de imagens ou vídeos que não são visíveis de imediato. Faça o mesmo com elementos de fundo ou secundários. Usar loading="lazy" para mídia fora da tela é um ótimo ponto de partida. Adiar outros scripts e ativos não essenciais vai liberar largura de banda. Isso corta qualquer competição com seus recursos críticos. O conteúdo principal da sua página continuará rápido para carregar e exibir. Nunca aplique loading="lazy" à sua imagem do LCP. Esse é um antipadrão crítico que destruirá 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 web com base na navegação prevista do usuário. O prefetching elimina a subparte Time to First Byte do LCP e não tem impacto na duração do carregamento do recurso. O prerendering renderiza a próxima página em uma aba oculta e baixa todos os recursos da página. Isso elimina a maior parte das durações de carregamento do elemento do LCP, como mostrado neste exemplo de detalhamento do LCP de uma página pré-renderizada.

Próximos Passos: Continue Otimizando o LCP

A Duração do 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 de diagnóstico completa para encontrar e corrigir todos os problemas de LCP usando field data e ferramentas de laboratório.
• Otimize a Imagem do LCP: Seleção do formato de imagem, imagens responsivas, preloading e erros comuns na otimização de imagens.
• Atraso no Carregamento do Recurso: Garanta que o navegador descubra o recurso do LCP o mais cedo possível. Esse costuma ser um gargalo maior que a própria duração do carregamento.
• Atraso na Renderização do Elemento: Após o download do recurso, garanta que o navegador consiga pintá-lo imediatamente limpando a main thread.