Otimize a Imagem do Largest Contentful Paint

Otimize a Imagem do Largest Contentful Paint

Este guia faz parte da seção Largest Contentful Paint (LCP) do nosso centro de recursos Core Web Vitals. O LCP mede o tempo de renderização do maior elemento visível, e imagens são o tipo de elemento LCP mais comum. Este artigo cobre todas as técnicas para garantir que sua imagem LCP carregue e renderize o mais rápido possível.

De acordo com o Google, apenas 65% de todas as visualizações de página na internet (e isso inclui desktop e mobile) têm uma 'boa' pontuação de Largest Contentful Paint. Isso significa que 35% das visualizações de página estão falhando e isso se deve em parte a erros cometidos com imagens. Este artigo detalha padrões de boas práticas comuns e erros quando as imagens se tornam o elemento do Largest Contentful Paint.

Embora todos esses fatores importem, se o seu elemento LCP for uma imagem (e frequentemente é!), existem etapas 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á muitos 'gurus' por aí pregando informações erradas. É por isso que criei um experimento LCP totalmente automático onde você pode verificar por si mesmo o que acontece quando o elemento LCP não é carregado de forma ideal. Confira meu Teste LCP no github ou experimente a demo ao vivo!

Ele testará automaticamente vários cenários de LCP para você e mostrará os resultados. Discutirei esses cenários abaixo e explicarei como e por que isso acelerará ou desacelerará o elemento de imagem LCP.

1. Controle o Candidato LCP: A Estratégia Text-First

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

Por que o Texto é Mais Rápido Que uma Imagem. A diferença de performance se resume 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 requer sua própria requisição HTTP. Isso introduz latência de rede (DNS, TCP, TLS e tempo de download) além de ser bloqueada pelo CSS. Essa distinção é o motivo central para a diferença de performance e por que controlar o candidato LCP é uma estratégia poderosa de nível especialista.

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

Então, você deve mudar para um elemento do Largest Contentful Paint baseado em texto? Isso depende! Imagens importam e elas tornam seu site visualmente atraente. Isso significa que você não me ouvirá defender a mudança para elementos de texto velhos e chatos. Mas erros também acontecem! Eu gostaria de ter um dólar para cada página de categoria que foi vítima do **anti-pattern "LCP Acidental"**. É quando uma página "esquece" de adicionar um texto descritivo da categoria acima da dobra, fazendo com que uma imagem de produto em lazy-load se torne o LCP e atrasando os tempos de carregamento em segundos. Isso geralmente acontece quando os designers colocam um grande banner hero no topo do DOM, antes de quaisquer títulos significativos, não deixando ao navegador outra escolha a não ser selecionar um candidato LCP mais lento.

2. Use o Formato de Imagem Mais Rápido Disponível

Sem entrar em um debate acalorado sobre espremer o último byte ou as configurações perfeitas para WebP vs. AVIF, vamos concordar com 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. Se você quiser se aprofundar, este artigo detalha isso. Para uma visão geral completa das técnicas de otimização de imagens, veja nosso guia sobre otimização de imagens.

Como regra geral, você deve servir uma versão lossy 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 a WebP em cerca de 95% e o suporte a AVIF em 92%, ainda faz sentido servir imagens mais antigas de fallback também. Para fazer isso, use o 'progressive enhancement' onde servimos esses formatos modernos apenas para navegadores que os suportam.

Trade-off de Velocidade de Decodificação vs. 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. Esta é uma tarefa vinculada à CPU que acontece nas threads de Rasterização do navegador e aumenta diretamente o Element Render Delay. 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 de Performance do Chrome DevTools procurando por tarefas longas de "Decode Image" associadas ao seu elemento LCP. Se você ver isso, é um sinal claro de que a velocidade de decodificação é o seu gargalo, não apenas o tempo de download.

Insight de Especialista: O Caso do JPEG-XL. Um verdadeiro guia de especialistas deve abordar o JPEG XL. É um formato tecnicamente notável, especialmente por sua capacidade de recompactar sem perdas JPEGs existentes (uma grande vitória para sites legados) e seu suporte a decodificação progressiva, que o AVIF não possui. No entanto, sua desvantagem decisiva é a falta de amplo suporte em navegadores após ser abandonado pelo Chrome. Isso o torna ainda não viável para uso geral na web, mas o posiciona como um a ser observado no futuro.

Usando o elemento <picture>: O elemento <picture> permite que os navegadores pulem formatos de imagem não suportados, selecionando o primeiro que eles podem manipular. Veja como fazer isso:

<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 máxima performance, você deve combinar a seleção de formato com tamanhos de imagens responsivas em um único elemento <picture>. Isso garante que cada usuário obtenha 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, em seguida, 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 suportado obterá um pequeno arquivo AVIF, enquanto um navegador de desktop mais antigo usará o fallback para um JPEG de tamanho correto.

Usando content negotiation

A content negotiation (negociação de conteúdo) permite que seu servidor entregue diferentes formatos de imagem com base no suporte do navegador. Os navegadores anunciam os formatos suportados através do cabeçalho Accept. Por exemplo, no Chrome, o cabeçalho Accept para imagens se parece com isso:

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

Em seguida, no lado do servidor, leia o cabeçalho accept e, com base no cabeçalho, sirva o 'melhor formato'.

3. Use Imagens Responsivas

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

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

Imagens Responsivas:

Use o atributo srcset para servir tamanhos de imagem diferentes 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 o srcset com descritores w, mas omitir o atributo sizes é um erro comum e custoso. 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 massiva da sua lista de srcset, mesmo que a imagem seja exibida apenas em uma pequena coluna de 500px. Você forneceu os ingredientes certos (srcset), mas deixou de fora a receita (sizes), levando ao desperdício de largura de banda e a um LCP mais lento. O atributo sizes fornece o contexto de layout necessário, dizendo ao navegador qual será a largura real da imagem em diferentes breakpoints da viewport, permitindo que ele faça uma escolha inteligente de download.

Entendendo 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 (width) é 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 (device-pixel-ratio) considera apenas a densidade de pixels da tela, ignorando o quão grande a imagem realmente é no layout, tornando-o 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. Dimensione Suas Imagens para o Tamanho da Tela!

Evite servir imagens que sejam maiores do que o necessário. Se o elemento LCP tiver apenas 600px de largura na viewport, certifique-se de que a imagem não seja maior do que isso. Acredite, vejo isso acontecer todos os dias! Para verificar, basta fazer isso: inspecione a imagem clicando nela com o botão direito e selecionando 'inspecionar elemento' (inspect-element). Você agora verá o dev-tools 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 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 Imagens LCP Carregadas Antecipadamente (Eager Loaded)

Para obter a melhor performance do seu LCP, você deve carregar de forma "eager" o elemento LCP visível (e usar lazy load para imagens que não são imediatamente visíveis). Este é um dos erros mais comuns na otimização de LCP, e nós o cobrimos em detalhes em nosso artigo sobre como corrigir imagens LCP com lazy load.

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

Alerta Geek: Imagens "lazy" não são enfileiradas pelo scanner de preload. O scanner de preload é um scanner HTML secundário super rápido que enfileira recursos importantes imediatamente. Quando o scanner de preload é ignorado, o navegador terá que esperar que a engine 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 que bloqueia a renderização para construir a render tree. Somente depois que o layout for calculado o navegador poderá determinar se a imagem está na viewport. Isso significa que todo o seu CSS se torna uma dependência de bloqueio para o download da imagem LCP, o que é um desastre de performance.

<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 percorrer. Ao atrasar o carregamento dessas imagens até que o usuário role a tela para perto delas, você libera a largura de banda para conteúdo mais importante, como seu elemento LCP. Dessa forma, o lazy loading é uma faca de dois gumes: se usado corretamente, ele acelerará seu conteúdo LCP; se usado incorretamente, ele o atrasará!

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

O equilíbrio? Carregue antecipadamente (eagerly load) o conteúdo crítico (como sua imagem LCP) e aplique lazy load em recursos menos críticos e imagens abaixo da dobra!

6. Faça o Preload da Imagem LCP

Fazer o preload da imagem do Largest Contentful Paint (LCP) é uma das maneiras mais fáceis de acelerar sua aparência na página. Isso diz ao navegador para priorizar o carregamento dessa imagem, garantindo que ela esteja pronta o mais rápido possível. Para um guia completo sobre preload, veja nosso artigo dedicado sobre preload da imagem LCP.

Por que fazer o Preload da Imagem 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 LCP é referenciada mais adiante na cadeia, o que significa que o navegador chega a ela mais tarde do que deveria. O preload da imagem LCP informa o navegador antecipadamente que esta imagem é crítica e deve ser carregada imediatamente, reduzindo o atraso na renderização do seu maior elemento.

Como fazer o Preload da Imagem LCP

Usando a tag <link rel="preload">, você pode garantir que o navegador comece a buscar a imagem 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 LCP esteja na fila do navegador desde o início, evitando a espera que geralmente ocorre se a imagem estiver oculta em CSS ou 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 LCP, pois fazer o preload de muitos recursos pode sobrecarregar o navegador e prejudicar a performance. Limite-se ao que mais importa para seus Core Web Vitals.

7. Remova as Animações de Fade-In da Imagem LCP

As animações de fade-in podem ser visualmente atraentes, mas quando se trata do seu Largest Contentful Paint, elas são um gargalo oculto. Se o elemento LCP (frequentemente uma imagem) usar um efeito de fade-in, o navegador não contará o LCP até que a animação termine. Isso atrasa o timing do LCP e pode prejudicar significativamente suas métricas de performance.

O Timing LCP Acontece Depois Que a Animação Termina: 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 continuará rodando até que a imagem ou conteúdo tenha aparecido completamente (faded in), o que pode adicionar facilmente segundos extras à sua pontuação do LCP.

Mantenha Simples: 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 exibir imediatamente, sem qualquer transição ou animação.

Ao pular os fade-ins na imagem LCP, você evitará atrasos desnecessários e melhorará seus Core Web Vitals, garantindo uma experiência mais rápida e suave para os usuários.

8. Faça Self-Host do Elemento LCP

Para obter a melhor performance do seu Largest Contentful Paint, você deve sempre considerar fazer o self-host do elemento LCP, especialmente se for uma imagem ou outro recurso crítico. Confiar em servidores de terceiros pode introduzir atrasos que estão completamente fora do seu controle, o que pode prejudicar o seu LCP e a performance geral da página.

Pense desta forma: Não fazer o self-host do seu elemento LCP é como constantemente pegar açúcar emprestado do seu vizinho. Toda vez, você tem que ir até lá, esperar na porta, e esperar que eles estejam em casa. Depender de um servidor de terceiros para o seu LCP faz seu site esperar por esse recurso externo, diminuindo os tempos de carregamento. O self-hosting é como manter o açúcar na sua cozinha: rápido, direto e confiável.

Reduza Dependências Externas: Quando o seu elemento LCP (como uma imagem) é hospedado em um servidor de terceiros, você fica à mercê da velocidade, disponibilidade e de quaisquer tempos de ida e volta adicionais (RTT) desse servidor. O self-hosting elimina essa incerteza, permitindo que você sirva a imagem diretamente do seu próprio servidor, garantindo uma entrega mais rápida e confiável.

Aproveite o Caching e Otimizações: Por meio do self-hosting, você pode aproveitar ao máximo as estratégias de caching e servir a imagem do servidor mais próximo ao usuário, especialmente se estiver usando uma CDN. Isso reduz o tempo que leva para carregar o elemento LCP, resultando em renderização mais rápida.

Controle Sobre Otimização de Imagem: O self-hosting oferece controle sobre como a imagem é otimizada, seja compressão, redimensionamento ou seleção de formato, sem depender do manuseio de terceiros. Dessa forma, você pode garantir que a imagem seja perfeitamente ajustada para carregamento rápido.

9. Evite a Renderização no Lado do Cliente para o Elemento LCP

A renderização no lado do cliente (Client-side rendering - CSR) pode ser um grande obstáculo quando se trata de otimizar o seu Largest Contentful Paint. 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 leva a tempos LCP mais lentos, já que 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 sua aparência. Quanto mais isso demora, pior fica sua pontuação de LCP. Cada segundo extra gasto processando scripts se traduz em uma espera mais longa para que seus usuários vejam o conteúdo mais importante.

Mude para Renderização no Lado do Servidor (SSR) ou Renderização Estática: 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 exiba imediatamente, sem esperar pelo início do JavaScript. Isso melhora drasticamente o timing do LCP, já que o navegador pode renderizar o elemento LCP imediatamente quando ele começa a carregar o HTML.

Minimize o JavaScript no Caminho Crítico: Se você não pode evitar alguns scripts do lado do cliente, certifique-se de que eles não bloqueiem a renderização do elemento LCP. Adie (defer) ou utilize async em scripts não críticos para evitar que eles atrasem a aparência do seu LCP.

10. Reserve Espaço para Prevenir Layout Shifts

Sempre inclua os atributos explícitos width e height nas suas tags <img>. Esta é uma instrução crítica para o navegador, permitindo-lhe calcular o aspect ratio (proporção) da imagem e reservar a quantidade correta de espaço no layout *antes* de a imagem ter sido baixada.

Insight de Especialista: Comportamento Moderno de width e height

Um equívoco comum é que esses atributos tornam uma imagem não responsiva. Isso não é mais verdade em navegadores modernos. O navegador usa esses atributos HTML para calcular uma proporção e manter o espaço, mas a imagem ainda será perfeitamente responsiva se seu CSS for definido 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 que bloqueia a renderização ter sido baixado e analisado, dando-lhe uma vantagem crítica inicial.

Tratando Imagens de Fundo CSS (Background Images)

Esse princípio também se aplica aos elementos que servem como containers para um background-image CSS. Uma fonte comum de layout shift é uma <div> que inicialmente colapsa para a altura zero e então atinge o tamanho quando a imagem de fundo é aplicada. Para evitar isso, use a propriedade CSS aspect-ratio diretamente no elemento container para reservar o espaço necessário desde o início.

11. Audite o Bloqueio da Main-Thread

Mesmo se sua imagem LCP estiver perfeitamente otimizada e priorizada, sua renderização final pode ser atrasada se a thread principal (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 Element Render Delay. Use o painel Performance no Chrome DevTools para identificar tarefas de longa duração durante o carregamento inicial, atribua-as à sua origem e adie ou remova qualquer uma que não seja crítica para a renderização inicial. Para mais detalhes sobre este tópico, consulte nosso guia sobre Element Render Delay.

Guias Relacionados de Otimização LCP

A otimização de imagens é apenas uma parte para alcançar um LCP rápido. Explore as outras fases do LCP para uma estratégia de otimização completa:

• Corrigir e Identificar Problemas LCP: A metodologia de diagnóstico completa para encontrar e corrigir problemas de LCP usando dados de campo e ferramentas de laboratório.
• Resource Load Delay: Garanta que o navegador descubra seu recurso LCP o mais cedo possível com preload, fetchpriority e estrutura HTML ideal.
• Resource Load Duration: Reduza o tempo de download por meio de compressão, configuração de CDN e otimização de rede.
• Element Render Delay: Limpe a thread principal para que o navegador possa pintar o elemento LCP imediatamente após o download.