Otimize a imagem do Largest Contentful Paint

Otimize a imagem do Largest Contentful Paint

Este guia faz parte do hub do Largest Contentful Paint (LCP). Na maioria dos sites, o elemento LCP é uma imagem. Erre na imagem e sua pontuação de LCP cai. Este artigo cobre todas as técnicas para torná-la rápida.

De acordo com o Google, apenas 65% de todas as visualizações de página na internet (incluindo desktop e dispositivos móveis) têm uma pontuação "boa" de Largest Contentful Paint. Isso significa que 35% das visualizações de página falham, e isso ocorre em parte devido a erros com imagens. Este artigo detalha padrões comuns de boas práticas e erros quando as imagens se tornam o elemento Largest Contentful Paint.

Embora todos esses fatores importem, se o seu elemento LCP for uma imagem (e frequentemente é!), existem passos simples que você pode seguir para garantir que ele carregue o mais rápido possível!

Experimentos com o Largest Contentful Paint

Eu sempre digo: ouça e aprenda, mas não acredite na palavra de ninguém. Há "gurus" demais por aí ensinando informações erradas. Por isso, criei um experimento de LCP totalmente automático onde você pode conferir por si mesmo o que acontece quando o elemento LCP não é carregado de forma ideal. Confira o meu LCP Test no GitHub ou experimente a demonstração ao vivo!

Ele testará automaticamente vários cenários de LCP para você e mostrará os resultados. Vou discutir esses cenários abaixo e explicar como e por que eles aceleram ou desaceleram o elemento de imagem do LCP.

1. Controle o candidato a LCP: A estratégia de texto primeiro

A maneira mais rápida de melhorar o seu Largest Contentful Paint baseado em imagem? Não use uma imagem! Espera, como é? Sim, você ouviu direito. Deixe-me explicar.

Por que o texto é mais rápido que uma imagem. A diferença de desempenho resume-se ao pipeline de requisição. Um nó de texto (como um <h1> ou <p>) faz parte do documento HTML principal. Ele não tem uma requisição de recurso separada; sua renderização é bloqueada apenas pelo CSS. Uma imagem, por outro lado, é um recurso externo que exige sua própria requisição HTTP. Isso introduz latência de rede (DNS, TCP, TLS e tempo de download) além de ser bloqueada por CSS. Essa distinção é o motivo central da diferença de desempenho e por que controlar o candidato a LCP é uma estratégia poderosa e de nível especialista.

Então, qual é o caso para imagens versus texto? Imagens são importantes; elas tornam seu site visualmente atraente. But o Core Web Vitals não se importa com qual elemento se torna o LCP. Quando o elemento LCP é baseado em texto, ele geralmente coocorre com o First Contentful Paint.

Então, você deveria mudar para um elemento do Largest Contentful Paint baseado em texto? Depende! Imagens importam e tornam seu site visualmente atraente. Isso significa que você não me verá defendendo a mudança para elementos de texto antigos e sem graça. Mas erros acontecem! Eu gostaria de ganhar um real para cada página de categoria que foi vítima do anti-padrão "LCP Acidental". É quando uma página "se esquece" de adicionar um texto descritivo de categoria acima da dobra, fazendo com que uma imagem de produto com lazy loading se torne o LCP e atrase o tempo de carregamento em segundos. Isso geralmente acontece quando designers posicionam um banner hero grande no topo do DOM, antes de qualquer título relevante, deixando o navegador sem escolha a não ser selecionar um candidato a LCP mais lento.

2. Use o formato de imagem mais rápido disponível

Sem entrar em um debate caloroso sobre espremer o último byte ou as configurações perfeitas para WebP vs. AVIF, vamos concordar em uma coisa: formatos mais antigos como JPEG e PNG são maiores e mais lentos em comparação com formatos modernos como WebP ou AVIF. Para uma visão completa das técnicas de otimização de imagem, consulte nosso guia sobre otimização de imagem.

Como regra geral, você deve servir uma versão lossy em WebP ou AVIF da sua imagem LCP (melhor ainda, use esses formatos para todas as suas imagens, mas estamos focando no LCP aqui). Com o suporte ao WebP em cerca de 95% e o suporte ao AVIF em 92%, ainda faz sentido servir imagens mais antigas de fallback também. Para fazer isso, use "melhoria progressiva" (progressive enhancement), servindo esses formatos modernos apenas para navegadores que os suportam.

Compensação entre velocidade de decodificação e compressão

Embora o AVIF ofereça a melhor compressão (menor tamanho de arquivo), seus algoritmos complexos podem exigir mais poder de CPU para decodificar em uma imagem renderizável em comparação com o WebP. Essa é uma tarefa vinculada à CPU que ocorre nas threads de Rasterização do navegador e aumenta diretamente o atraso de renderização do elemento. Um AVIF menor pode baixar mais rápido, mas seu tempo de decodificação mais longo pode anular esse benefício, especialmente em dispositivos móveis. Você pode diagnosticar isso no painel Performance do Chrome DevTools procurando por tarefas longas de "Decode Image" associadas ao seu elemento LCP. Se você vir isso, é um sinal claro de que a velocidade de decodificação é o seu gargalo, não apenas o tempo de download.

Visão de especialista: O caso do JPEG XL. Um verdadeiro guia especializado deve abordar o JPEG XL. É um formato tecnicamente notável, especialmente por sua capacidade de recomprimir JPEGs existentes sem perdas (uma enorme vitória para sites legados) e seu suporte para decodificação progressiva, que o AVIF não possui. No entanto, sua desvantagem decisiva é a falta de amplo suporte dos navegadores após ter sido descartado pelo Chrome. Isso o torna ainda inviável para uso geral na web, mas o posiciona como um formato para se acompanhar no futuro.

Usando o elemento <picture>: O elemento <picture> permite que os navegadores ignorem formatos de imagem não suportados, selecionando o primeiro que conseguem processar. Veja como fazer:

<picture>
<source srcset="img.avif" type="image/avif">
<source srcset="img.webp" type="image/webp">
<img src="img.jpg" alt="Image" width="123" height="123">
</picture>

Combinando negociação de formato com tamanhos responsivos

Para o máximo de desempenho, você deve combinar a seleção de formato com tamanhos de imagem responsivos em um único elemento <picture>. Isso garante que cada usuário receba o formato ideal e o tamanho ideal para seu dispositivo. O navegador avalia os elementos <source> de cima para baixo e seleciona o primeiro formato que suporta, depois usa os atributos srcset e sizes para escolher a resolução certa.

<picture>
  <source
    type="image/avif"
    srcset="hero-400w.avif 400w, hero-800w.avif 800w, hero-1200w.avif 1200w"
    sizes="(max-width: 600px) 100vw, (max-width: 1200px) 800px, 1200px">
  <source
    type="image/webp"
    srcset="hero-400w.webp 400w, hero-800w.webp 800w, hero-1200w.webp 1200w"
    sizes="(max-width: 600px) 100vw, (max-width: 1200px) 800px, 1200px">
  <img
    src="hero-800w.jpg"
    srcset="hero-400w.jpg 400w, hero-800w.jpg 800w, hero-1200w.jpg 1200w"
    sizes="(max-width: 600px) 100vw, (max-width: 1200px) 800px, 1200px"
    alt="Descriptive alt text for hero image"
    width="1200" height="675"
    fetchpriority="high">
</picture>

Esse padrão dá ao navegador total liberdade para escolher a melhor combinação de formato e resolução. Um usuário móvel em um navegador compatível receberá um arquivo AVIF pequeno, enquanto um navegador desktop mais antigo fará o fallback para um JPEG de tamanho correto.

Usando negociação de conteúdo

A negociação de conteúdo permite que seu servidor sirva diferentes formatos de imagem com base no suporte do navegador. Os navegadores anunciam os formatos suportados por meio do cabeçalho Accept. Por exemplo, no Chrome, o cabeçalho Accept para imagens tem esta aparência:

Accept: image/avif,image/webp,image/apng,image/*,*/*;q=0.8

Depois, no lado do servidor, leia o cabeçalho accept e, com base nele, sirva o "melhor formato".

3. Use imagens responsivas

Quando se trata de otimizar imagens de LCP, o tamanho realmente importa. Uma das vitórias mais fáceis é servir imagens com as menores dimensões possíveis que ainda fiquem boas nas telas dos seus usuários. Imagens grandes não servem para nada: desperdiçam largura de banda e atrasam o tempo de carregamento, especialmente para usuários em conexões mais lentas ou dispositivos móveis.

Para garantir que você não esteja desperdiçando pixels, siga estes passos:

Imagens responsivas:

Use o atributo srcset para servir diferentes tamanhos de imagem com base no dispositivo do usuário. Dessa forma, dispositivos menores recebem imagens menores, o que ajuda a acelerar o LCP.

Por que o atributo sizes é crítico

Usar srcset com descritores w, mas omitir o atributo sizes, é um erro comum e caro. Sem o atributo sizes, o navegador é forçado a assumir um valor padrão de 100vw (100% da largura da viewport). Isso significa que, em uma tela grande de desktop, o navegador baixará uma imagem enorme da sua lista srcset, mesmo que a imagem seja exibida apenas em uma coluna pequena de 500px. Você forneceu os ingredientes certos (srcset), mas esqueceu a receita (sizes), resultando em desperdício de largura de banda e um LCP mais lento. O atributo sizes fornece o contexto de layout necessário, informando ao navegador a largura real que a imagem terá em diferentes breakpoints da viewport, permitindo que ele faça uma escolha de download inteligente.

Entendendo os descritores w vs. x

O atributo srcset suporta dois tipos de descritores. Para design responsivo onde o tamanho de uma imagem muda com a viewport, o descritor w (largura) é a escolha superior e necessária. Ele é usado com o atributo sizes para permitir que o navegador escolha a melhor imagem com base em seu tamanho renderizado no layout. O descritor mais simples x (proporção de pixels do dispositivo) considera apenas a densidade de pixels da tela, ignorando o tamanho real da imagem no layout, o que o torna adequado apenas para imagens de tamanho fixo, como ícones.

<img
  src="img.jpg"
  srcset="img-400px.jpg 400w, img-800px.jpg 800w, img-1200px.jpg 1200w"
  sizes="(max-width: 600px) 400px, (max-width: 1200px) 800px, 1200px"
  alt="Image" width="123" height="123">

4. Redimensione suas imagens para o tamanho da tela!

Evite servir imagens maiores do que o necessário. Se o elemento LCP tiver apenas 600px de largura na viewport, garanta que a imagem não seja maior do que isso. Acredite, vejo isso acontecer todos os dias! Para verificar, faça o seguinte: inspecione a imagem clicando com o botão direito nela e selecionando "Inspecionar". Você verá as ferramentas de desenvolvedor e o HTML da imagem destacado com um fundo azul. Agora você pode ver que o tamanho renderizado da imagem (443 x 139px) é muito menor do que a largura intrínseca da imagem (1090x343px). Isso é quase 3 vezes maior, e redimensionar a imagem poderia ter economizado pelo menos 50% do tamanho do arquivo.

5. Use carregamento imediato (eager loading) na imagem do LCP

Para obter o melhor desempenho do seu LCP, você deve carregar o elemento LCP visível de forma imediata (eagerly load) (e aplicar lazy loading em imagens que não estão imediatamente visíveis). Esse é um dos erros mais comuns na otimização de LCP, e o cobrimos detalhadamente em nosso artigo sobre como corrigir imagens de LCP carregadas com lazy loading.

Carregamento imediato (eager loading): O elemento LCP (geralmente conteúdo acima da dobra) deve sempre ser carregado de forma imediata (eager). Isso garante que ele apareça o mais rápido possível, reduzindo o tempo que o seu Largest Contentful Paint leva para renderizar. Por padrão, as imagens são carregadas de forma imediata, a menos que especificado de outra forma, mas verifique se você não definiu loading="lazy" na imagem do LCP. Fazer isso pode atrasar significativamente o LCP e prejudicar sua pontuação de Core Web Vitals. É importante entender que loading="eager" é o comportamento padrão do navegador, portanto, omitir o atributo completamente tem o mesmo efeito. A ação crítica é garantir que loading="lazy" não esteja presente.

Alerta geek: Imagens com lazy loading não são enfileiradas pelo preload scanner. O preload scanner é um scanner secundário de HTML super rápido que enfileira recursos importantes imediatamente. Quando o preload scanner é ignorado, o navegador precisa esperar que o mecanismo de renderização termine antes de enfileirar as "imagens visíveis". Para que o navegador avalie o loading="lazy" nativo, ele deve primeiro baixar e analisar todo o CSS render blocking para construir a árvore de renderização. Somente após o layout ser calculado, o navegador poderá determinar se a imagem está na viewport. Isso significa que todo o seu CSS se torna uma dependência bloqueante para o download da imagem do LCP, o que é um desastre de desempenho.

<img src="lcp-image.jpg" alt="Main image" width="800" height="400">

Para imagens que aparecem abaixo da dobra (aquelas não visíveis quando a página carrega pela primeira vez), o lazy loading é o caminho a seguir. Ao atrasar o carregamento dessas imagens até que o usuário role para perto delas, você libera largura de banda para conteúdos mais importantes, como o seu elemento LCP. Dessa forma, o lazy loading é uma faca de dois gumes: se usado corretamente, ele acelerará seu conteúdo de LCP; se usado incorretamente, irá desacelerá-lo!

<img src="non-visible-image.jpg"
     alt="Secondary image"
     
     width="800" height="400">

O equilíbrio? Carregue imediatamente o conteúdo crítico (como a sua imagem do LCP) e use lazy loading em recursos menos críticos e imagens abaixo da dobra!

6. Faça o preload da imagem do LCP

Fazer o preload da imagem do LCP diz ao navegador para buscá-la imediatamente, antes que ele a descubra naturalmente no HTML. Para um guia completo sobre pré-carregamento, consulte nosso artigo dedicado sobre como fazer o preload da imagem do LCP.

Por que fazer o preload da imagem do LCP?

Quando o navegador carrega uma página, ele processa o HTML, as folhas de estilo e os scripts em uma determinada ordem. Às vezes, a imagem do LCP é referenciada mais adiante na cadeia, o que significa que o navegador chega até ela mais tarde do que deveria. Fazer o preload da imagem do LCP avisa ao navegador de antemão que essa imagem é crítica e deve ser carregada imediatamente, reduzindo o atraso na renderização do seu maior elemento.

Como fazer o preload da imagem do LCP

Ao usar a tag <link rel="preload">, você garante que o navegador comece a buscar a imagem do LCP o mais cedo possível no processo de carregamento.

<link rel="preload" href="lcp-image.jpg" as="image" type="image/jpeg">

Isso garante que a imagem do LCP esteja na fila do navegador desde o início, evitando a espera que geralmente ocorre se a imagem estiver oculta no CSS ou em scripts.

<!-- In the <head> -->
<link rel="preload" as="image"
      href="lcp-image-800w.jpg"
      imagesrcset="lcp-image-400w.jpg 400w, lcp-image-800w.jpg 800w"
      imagesizes="(max-width: 600px) 400px, 800px">

<!-- In the <body> -->
<img src="lcp-image-800w.jpg"
     srcset="lcp-image-400w.jpg 400w, lcp-image-800w.jpg 800w"
     sizes="(max-width: 600px) 400px, 800px"
     alt="..." width="800" height="450" fetchpriority="high">

Lembre-se: Faça o preload apenas da imagem do LCP, pois pré-carregar recursos demais pode sobrecarregar o navegador e prejudicar o desempenho. Foque no que mais importa para o seu Core Web Vitals.

7. Remova animações de fade-in da imagem do LCP

Animações de fade-in podem ser visualmente atraentes, mas são um gargalo oculto de LCP. Se o elemento LCP (frequentemente uma imagem) usa um efeito de fade-in, o navegador não contabilizará o LCP até que a animação termine. Isso atrasa o tempo do LCP e pode prejudicar significativamente suas métricas de desempenho.

A medição do LCP acontece após o término da animação: O navegador considera o LCP concluído apenas quando o elemento está totalmente visível. Se você tiver uma animação de fade-in, o cronômetro continua rodando até que a imagem ou o conteúdo tenha aparecido por completo, o que pode facilmente adicionar segundos extras à sua pontuação de LCP.

Simplifique: Para garantir que o elemento LCP apareça o mais rápido possível, evite usar efeitos de fade-in. Deixe a imagem carregar e ser exibida imediatamente, sem qualquer transição ou animação.

Evite fade-ins na imagem do LCP. O efeito visual não compensa o custo de desempenho.

8. Faça o self-host do elemento LCP

Faça o self-host da sua imagem do LCP. Depender de servidores de terceiros introduz atrasos que estão completamente fora do seu controle, o que pode prejudicar seu LCP e o desempenho geral da página.

Pense assim: Não fazer o self-host do seu elemento LCP é como pedir açúcar emprestado ao vizinho o tempo todo. Toda vez, você tem que caminhar até lá, esperar na porta e torcer para ele estar em casa. Depender de um servidor de terceiros para o seu LCP faz seu site esperar por esse recurso externo, atrasando o carregamento. O self-host é como manter o açúcar na sua cozinha: rápido, direto e confiável.

Reduza dependências externas: Quando seu elemento LCP (como uma imagem) está hospedado em um servidor de terceiros, você fica à mercê da velocidade e disponibilidade desse servidor, além de qualquer tempo de ida e volta (RTT) adicional. O self-host elimina essa incerteza, permitindo que você sirva a imagem diretamente do seu próprio servidor, garantindo uma entrega mais rápida e confiável.

Use cache e otimizações: Ao fazer o self-host, você pode aproveitar ao máximo as estratégias de cache e servir a imagem do servidor mais próximo do usuário, especialmente se estiver usando uma CDN. Isso reduz o tempo necessário para carregar o elemento LCP, resultando em uma renderização mais rápida.

Controle sobre a otimização da imagem: O self-host dá a você controle sobre como a imagem é otimizada — seja por compressão, redimensionamento ou seleção de formato —, sem depender do processamento de terceiros. Dessa forma, você garante que a imagem esteja perfeitamente ajustada para carregar rápido.

9. Evite renderização no lado do cliente (CSR) para o elemento LCP

A renderização no lado do cliente (CSR) é uma das piores coisas que você pode fazer para o seu LCP. Se o seu elemento LCP (geralmente uma imagem grande, bloco de texto ou vídeo) for renderizado no lado do cliente via JavaScript, isso geralmente causará tempos de LCP mais lentos, pois o navegador precisa esperar que os scripts sejam baixados, analisados e executados antes de exibir o conteúdo crítico.

Atrasos na renderização: Com CSR, o elemento LCP só é exibido após o navegador processar o JavaScript, o que pode atrasar significativamente seu aparecimento. Quanto mais tempo isso levar, pior será sua pontuação de LCP. Cada segundo extra gasto no processamento de scripts se traduz em uma espera maior para seus usuários verem o conteúdo mais importante.

Mude para renderização no lado do servidor (SSR) ou renderização estática (Static Rendering): Ao renderizar o elemento LCP no lado do servidor ou como parte de uma resposta HTML estática, você permite que o navegador o carregue e o exiba imediatamente, sem esperar pelo JavaScript iniciar. Isso melhora drasticamente o tempo de LCP, pois o navegador pode renderizar o elemento LCP logo no início do carregamento do HTML.

Minimize o JavaScript no caminho crítico (critical path): Se não for possível evitar alguns scripts no lado do cliente, garanta que eles não bloqueiem a renderização do elemento LCP. Use defer ou async em scripts não críticos para evitar que eles atrasem a exibição do seu LCP.

10. Reserve espaço para evitar desvios de layout (layout shifts)

Sempre inclua atributos explícitos de width e height nas suas tags <img>. Essa é uma instrução crítica para o navegador, permitindo que ele calcule a proporção (aspect ratio) da imagem e reserve a quantidade correta de espaço no layout antes que a imagem seja baixada.

Visão de especialista: Comportamento moderno de width e height

Um equívoco comum é achar que esses atributos tornam a imagem não responsiva. Isso não é mais verdade nos navegadores modernos. O navegador usa esses atributos HTML para computar uma proporção e reservar o espaço, mas a imagem continuará perfeitamente responsiva se o seu CSS estiver configurado como width: 100%; height: auto;. Fornecer esses atributos é superior a usar apenas a propriedade CSS aspect-ratio, pois o navegador pode reservar o espaço antes de qualquer CSS render blocking ter sido baixado e analisado, garantindo uma vantagem crucial.

Lidando com imagens de fundo em CSS (Background Images)

Esse princípio também se aplica a elementos que servem como contêineres para uma background-image de CSS. Uma fonte comum de desvio de layout (layout shift) é uma <div> que colapsa para zero de altura inicialmente e depois assume o tamanho quando a imagem de fundo é aplicada. Para evitar isso, use a propriedade CSS aspect-ratio diretamente no elemento contêiner para reservar o espaço necessário desde o início.

11. Faça auditorias de bloqueio da main thread

Mesmo que sua imagem do LCP esteja perfeitamente otimizada e priorizada, a renderização final pode ser atrasada se a main thread do navegador estiver ocupada executando JavaScript pesado. Frequentemente, a origem desse bloqueio são scripts de terceiros para análises, anúncios ou widgets de suporte ao cliente. Esses scripts podem monopolizar a CPU, aumentando o atraso de renderização do elemento. Use o painel Performance do Chrome DevTools para identificar long tasks durante o carregamento inicial, atribua-as à sua origem e adie ou remova qualquer script que não seja crítico para a renderização inicial. Para saber mais sobre o assunto, consulte o nosso guia sobre Atraso de renderização do elemento.

Guias relacionados de otimização de LCP

A otimização de imagem é apenas uma peça do quebra-cabeça. Cada fase do LCP tem seu próprio guia:

• Corrigir e identificar problemas de LCP: A metodologia de diagnóstico completa para encontrar e corrigir problemas de LCP usando field data e lab data.
• Atraso no carregamento de recursos: Garanta que o navegador descubra o seu recurso LCP o mais cedo possível com preload, fetchpriority e uma estrutura HTML ideal.
• Duração do carregamento do recurso: Reduza o tempo de download por meio de compressão, configuração de CDN e otimização de rede.
• Atraso de renderização do elemento: Limpe a main thread para que o navegador possa pintar o elemento LCP imediatamente após o download.