Otimizar o Resource Load Duration do LCP

Este guia faz parte da secção de Largest Contentful Paint (LCP) do nosso centro de recursos de Core Web Vitals. O Resource Load Duration é a terceira de quatro fases sequenciais do LCP e mede o tempo necessário para descarregar o recurso do LCP pela rede. Embora o Resource Load Delay costume representar uma fatia maior do tempo de LCP, otimizar a duração do download continua a ser essencial para obter uma boa pontuação de LCP.

Otimizar o Resource Load Duration do LCP

O Largest Contentful Paint (LCP) é uma das três métricas Core Web Vitals que medem a experiência do utilizador. O LCP regista o tempo que o maior elemento de conteúdo (uma imagem, vídeo ou bloco de texto) demora a ficar visível no viewport. O Resource Load Duration é uma subparte do LCP que indica quanto tempo é gasto a descarregar o recurso de rede desse elemento.

O que é o Resource Load Duration no LCP?

O Resource Load Duration, muitas vezes chamado apenas Load Duration, refere-se ao tempo que o browser demora a descarregar o recurso de rede (por exemplo, uma imagem) que se tornará o elemento de LCP. Em imagens e vídeos, esta duração vai desde o momento em que o download começa até o browser concluir a transferência. Em elementos de LCP baseados em texto, a duração de carregamento é normalmente zero. O guia de otimização do LCP da Google divide o LCP em quatro subpartes sequenciais, sendo o Resource Load Duration o tempo efetivamente gasto a descarregar os bytes do recurso.

O Resource Load Duration mede-se a partir do instante em que o browser começa a descarregar o recurso do LCP até concluir o download. Há quatro fatores principais que determinam o Resource Load Duration:

• Tamanho do ficheiro: ficheiros maiores exigem tempos de download mais longos.
• Velocidade da rede: ligações mais lentas prolongam naturalmente a duração do carregamento.
• Capacidade de resposta do servidor: atrasos na resposta do servidor tornam a obtenção do recurso mais lenta.
• Downloads simultâneos: recursos descarregados ao mesmo tempo competem pela largura de banda, o que pode aumentar os tempos de carregamento.

Como detetar o Resource Load Duration

Existem duas formas eficazes de identificar e medir o Resource Load Duration:

Inspeção de rede no Chrome DevTools: use o atalho Ctrl + Shift + I para abrir as Developer Tools do Chrome, selecione o separador «Network» e recarregue a página. Procure o elemento de LCP nos pedidos de rede (se quiser identificar o elemento de LCP, experimente o Core Web Vitals Visualizer). O inspetor de rede mostra quanto tempo demorou a descarregar o recurso.

Dica pro: ative as linhas de pedidos grandes para ver detalhes adicionais como a latência do LCP, o tamanho transferido e o tamanho real.

Usar dados de Real User Monitoring (RUM):

As ferramentas de RUM registam frequentemente dados de atribuição do LCP. Os dados de atribuição do Largest Contentful Paint contêm informação sobre o Resource Load Duration. Com estes dados, pode acompanhar a evolução da duração de carregamento ao longo do tempo ou por página e detetar as páginas ou elementos que causam lentidão.

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

Como melhorar o Load Duration do LCP

Os problemas de Resource Load Duration ocorrem quando os recursos são demasiado grandes ou são entregues por rotas de rede lentas. Há duas abordagens principais para resolver isto: reduzir o tamanho dos dados ou otimizar a entrega dos dados.

1. Otimizar o tamanho dos ficheiros

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

Usar formatos de imagem modernos

O AVIF e o WebP são as melhores opções para compressão de imagem. O AVIF comprime até 50% mais do que o WebP em fotografias complexas, sem qualquer perda visível de qualidade. O WebP tem maior compatibilidade com browsers e funciona bem para imagens mais simples. De acordo com o Web Almanac de 2025, o WebP já é utilizado em mais de 40% dos pedidos de imagens, enquanto a adoção do AVIF quase duplicou de ano para ano, mas permanece abaixo dos 10%.

Escolher a definição de qualidade certa

Formatos de imagem modernos como o WebP e o AVIF permitem reduzir substancialmente a qualidade antes de haver degradação visual percetível. Regra geral, uma definição de qualidade entre 75 e 85 no WebP, e entre 60 e 75 no AVIF, fica idêntica ao original a distâncias normais de visualização, mas com uma fração do tamanho do ficheiro. Teste sempre com as suas imagens reais, pois a qualidade ideal depende do tipo de conteúdo (fotografias vs. ilustrações vs. imagens com muito texto).

Automatizar a compressão de imagens com o Sharp

Para otimização de imagens durante o build, a biblioteca sharp é uma das ferramentas mais rápidas e populares no ecossistema Node.js. O exemplo seguinte mostra como converter e comprimir uma imagem para os formatos WebP e AVIF com definiçõ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`);
}

Esta abordagem gera todas as variantes necessárias para um elemento <picture> responsivo compatível com formatos modernos. Em sites WordPress, plugins como o ShortPixel ou o Imagify tratam desta conversão automaticamente no upload.

Imagens responsivas

O elemento <picture> e o atributo srcset servem diferentes tamanhos de imagem consoante o ecrã: versões mais pequenas para telemóvel, resoluções maiores para ecrãs grandes. Eis 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

As imagens responsivas são apenas parte da solução: serem responsivas não significa que tenham o tamanho certo. Não ajustar as dimensões da imagem ao tamanho real de exibição é um dos erros mais comuns que encontro. Servir uma imagem de 2000px de largura para uma área de 500px desperdiça largura de banda e atrasa visivelmente o carregamento.

Otimização de ficheiros de fontes

Quando o elemento de LCP é texto renderizado com uma fonte web personalizada, o ficheiro da fonte passa a ser o recurso do LCP. Otimize o tempo de carregamento da fonte:

• Usar o formato WOFF2: o WOFF2 oferece a melhor compressão para fontes web — normalmente 30% menor do que o WOFF e muito mais leve do que ficheiros TTF ou OTF.
• Fazer subsetting das fontes: se o site apenas utiliza carateres latinos, faça o subsetting da fonte para remover conjuntos de carateres não utilizados (cirílico, grego, CJK). Ferramentas como o glyphhanger ou o pyftsubset automatizam este processo e reduzem muitas vezes o tamanho do ficheiro em 50% ou mais.
• Limitar as variações da fonte: cada peso e estilo (normal, negrito, itálico) implica o download de um ficheiro em separado. Inclua apenas os pesos que o design realmente utiliza.

2. Melhorar o desempenho da rede

Depois de otimizar o tamanho dos recursos, o passo seguinte é maximizar a velocidade da rede — ou até contornar a rede por completo.

Evitar a rede com a cache do browser

Não há ligação de rede mais rápida do que uma ligação evitada. Os browsers conseguem servir conteúdo estático (imagens, scripts, folhas de estilo) diretamente da cache local. Configure o servidor para enviar instruções de cache corretas para o browser.

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 guardado em cache tanto por browsers como por caches intermediárias.
• max-age=31536000: define que o recurso é considerado recente até um máximo de um ano (31.536.000 segundos).
• immutable: indica que o recurso não se alterará ao longo do tempo, evitando pedidos de revalidação desnecessários.

Para esta estratégia funcionar em segurança, utilize nomes de ficheiros com hash do conteúdo (por exemplo, hero-abc123.webp). Quando a imagem mudar, o nome do ficheiro muda também, invalidando a cache de forma automática.

Compressão Brotli vs. Gzip

Em recursos baseados em texto (HTML, CSS, JavaScript, SVG), a compressão no servidor é fundamental. O Brotli, desenvolvido pela Google, supera consistentemente o Gzip na taxa de compressão e mantém velocidades de descompressão comparáveis. A comparação seguinte mostra a diferença:

O cenário ideal é pré-comprimir assets estáticos com Brotli num nível elevado (por exemplo, nível 11) durante o processo de build, e usar o Gzip como fallback para clientes sem suporte para Brotli. A maioria das CDNs, incluindo a Cloudflare, trata disto automaticamente. Para mais detalhes sobre a configuração de CDN, consulte o nosso guia sobre como configurar a Cloudflare para o melhor desempenho.

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

O protocolo de entrega é especialmente importante quando o browser descarrega múltiplos recursos ao mesmo tempo.

• O HTTP/2 introduziu o multiplexing, permitindo enviar vários pedidos e respostas em simultâneo através de uma única ligação TCP. Isto elimina o problema de head-of-line blocking do HTTP/1.1, no qual um recurso lento bloqueava todos os outros. O HTTP/2 também suporta compressão de cabeçalhos (HPACK) e server push.
• O HTTP/3 vai mais longe e substitui o TCP pelo QUIC, um protocolo baseado em UDP. O HTTP/3 elimina o head-of-line blocking ao nível do TCP (onde um único pacote perdido bloqueia todas as streams), estabelece ligações mais rápidas através de 0-RTT (Zero Round Trip Time na retoma para visitantes recorrentes) e lida melhor com perdas de pacotes. Estas melhorias aceleram sobretudo o Time to First Byte, mas também reduzem o Resource Load Duration.

Para verificar se o HTTP/3 está ativo, basta inspecionar a rede com o atalho Ctrl+Shift+I. Selecione o separador Network, clique com o botão direito no cabeçalho das colunas e certifique-se de que a opção «Protocol» está ativa. Recarregue a página e veja o protocolo: em HTTP/3, a coluna deve indicar «h3».

Content Delivery Networks (CDN)

Uma CDN é uma rede de servidores distribuídos que guarda em cache e serve recursos estáticos (como imagens, CSS e JavaScript) a partir de localizações mais próximas do utilizador. Isto reduz o tempo de viagem dos dados (o round-trip time), o que diminui diretamente o Resource Load Duration.

Para 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 conseguem comprimir, redimensionar e converter imagens em tempo real. Por exemplo, o Cloudflare Polish, o Imgix e o Cloudinary podem servir WebP ou AVIF automaticamente com base no cabeçalho Accept do browser.
• Cache no edge: os recursos estáticos ficam em cache em nós de edge por todo o mundo, eliminando por completo a necessidade de os ir buscar ao servidor de origem.
• Otimização de protocolos: as CDNs costumam ativar HTTP/2 e HTTP/3 por omissão, juntamente com a compressão Brotli, sem exigir alterações de configuração no servidor.
• Reutilização de ligações: como a CDN serve todos os recursos a partir de um único domínio, o browser reutiliza uma única ligação, eliminando o overhead de múltiplos lookups de DNS e handshakes TLS.

As CDNs especializadas em imagens vão ainda mais longe, fornecendo otimizações automáticas em tempo real como conversão de formatos, redimensionamento e compressão.

Self-hosting de recursos

Os recursos de rede essenciais e carregados no início devem, por omissão, estar sempre alojados no servidor de origem. O self-hosting evita a necessidade de ligação a servidores externos, o que pode causar atrasos consideráveis devido a lookups de DNS adicionais, negociações SSL e estabelecimento de ligações. O self-hosting garante a reutilização de uma única ligação já aberta e reduz o overhead de abrir ligações separadas. Além disso, recursos em self-hosting garantem controlo absoluto sobre as políticas de compressão e de cache.

3. Otimizar a priorização de recursos

Depois de reduzir o tamanho dos recursos e otimizar a rede, resta resolver a disputa de rede. Quando o browser pede vários recursos ao mesmo tempo numa ligação lenta, eles competem pela largura de banda. Minimize essa concorrência programando o descarregamento dos recursos.

Priorizar recursos críticos

Identifique os recursos essenciais, como hero images ou CSS above-the-fold, com fetchpriority="high". Isto indica ao browser para descarregar estes assets primeiro, evitando que fiquem retidos por scripts, widgets ou elementos de terceiros que não precisam de carregamento imediato. Priorizar estes recursos críticos reduz o tempo de carregamento do conteúdo que mais interessa aos utilizadores. A combinação de preload (para resolver a descoberta tardia) com fetchpriority="high" (para resolver a contenção de rede) é a técnica mais eficaz para garantir que o recurso de LCP é descarregado 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 melhorar a descoberta  -->
<link rel="preload" href="hero-image.webp" as="image" fetchpriority="high">

Reduzir a contenção de rede

Agilize os downloads iniciais adiando ou aplicando lazy loading a recursos não essenciais. Adie o carregamento de quaisquer imagens ou vídeos que não estejam visíveis de imediato, bem como elementos secundários ou de fundo. Usar loading="lazy" em ficheiros multimédia fora do ecrã é um bom ponto de partida. Adiar outros scripts e assets não essenciais liberta largura de banda e elimina a concorrência com os recursos críticos, mantendo o conteúdo principal da página rápido a carregar e a surgir no ecrã. Nunca aplique loading="lazy" à imagem de LCP: é um anti-pattern grave que prejudica a pontuação.

4. Configurar Speculation Rules

A funcionalidade Speculation Rules permite aos browsers fazer prefetch ou prerender de páginas web com base na navegação prevista do utilizador. O prefetch elimina na prática a subparte de Time to First Byte do LCP e não tem qualquer impacto no Resource Load Duration. O prerender processa a página seguinte num separador oculto e descarrega todos os recursos da página. Isto elimina praticamente todo o tempo de carregamento do elemento de LCP, como mostra este exemplo de divisão do LCP de uma página com prerender.

Próximos passos: continuar a otimizar o LCP

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

• Identificar e corrigir problemas de LCP: a metodologia de diagnóstico completa para encontrar e resolver todos os problemas de LCP com recurso a field data e ferramentas de laboratório.
• Otimizar a imagem de LCP: escolha de formatos de imagem, imagens responsivas, preloading e erros comuns na otimização de imagens.
• Resource Load Delay: garanta que o browser descobre o recurso de LCP o mais cedo possível. Este atraso é muitas vezes um gargalo maior do que a própria duração do download.
• Element Render Delay: após o download do recurso, garanta que o browser consegue desenhá-lo de imediato no ecrã, libertando a main thread.