Otimize a Imagem do Largest Contentful Paint

Otimize a Imagem do Largest Contentful Paint

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

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 analisa padrões comuns de boas práticas e erros quando as imagens se tornam o elemento Largest Contentful Paint.

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

Experimentos com o Largest Contentful Paint

Eu sempre digo: ouça e aprenda, mas não acredite cegamente na palavra de ninguém. Existem 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 de LCP no github ou experimente a demonstração 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 atrasará o elemento de imagem LCP.

1. Controle o Candidato ao 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 bem. Deixe-me explicar.

Por que o Texto é Mais Rápido que uma Imagem. A diferença de performance se resume ao pipeline de requisições. 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 principal da diferença de performance e por que controlar o candidato ao LCP é uma estratégia poderosa e de nível especialista.

Então, qual é o argumento para imagens em vez de texto? As imagens são importantes; elas tornam o seu site visualmente atraente. Mas o Core Web Vitals não se importa com 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 Largest Contentful Paint baseado em texto? Isso depende! Imagens importam e elas tornam o seu site visualmente atraente. Isso significa que você não me ouvirá defender a mudança para velhos elementos de texto chatos. Mas erros também acontecem! Eu queria ter um dólar para cada página de categoria que foi vítima do anti-padrão "LCP Acidental". É quando uma página "esquece" de adicionar um texto de categoria descritivo above the fold (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 designers colocam um grande hero banner 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 até 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 geral 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 (com perdas) 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 torno de 95% e o suporte a AVIF em 92%, ainda faz sentido servir imagens fallback mais antigas também. Para fazer isso, use 'progressive enhancement' (aprimoramento progressivo) onde servimos esses formatos modernos apenas para navegadores que os suportam.

Trade-off 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 limitada pela CPU (CPU-bound) 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 "Decode Image" de longa duração 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.

Visão de Especialista: O Caso do JPEG-XL. Um verdadeiro guia de especialista deve abordar o JPEG XL. É um formato tecnicamente notável, especialmente por sua capacidade de recomprimir JPEGs existentes sem perdas (uma grande vitória para sites legados) e seu suporte para decodificação progressiva, algo que falta no AVIF. No entanto, sua desvantagem decisiva é a falta de amplo suporte pelos navegadores após ter sido 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 ignorem formatos de imagem não suportados, selecionando o primeiro que eles conseguem lidar. 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 a Negociação de Formato com Tamanhos Responsivos

Para obter o máximo de performance, você deve combinar a seleção de formato com tamanhos de imagem responsivos em um único elemento <picture>. Isso garante que cada usuário obtenha o formato ideal e o tamanho ideal para o 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 mobile em um navegador suportado obterá 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 através do cabeçalho Accept. Por exemplo, no Chrome, o cabeçalho Accept para imagens é assim:

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

Então, 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 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 têm nenhuma função: elas desperdiçam largura de banda e atrasam os tempos de carregamento, especialmente para usuários em conexões mais lentas ou dispositivos móveis.

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

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 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 de desktop grande, o navegador fará o download de uma imagem massiva da sua lista 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 quão larga a imagem realmente será 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 um 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 x (device-pixel-ratio) mais simples 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 maiores que o necessário. Se o elemento LCP tem apenas 600px de largura na viewport, certifique-se de que a imagem não seja maior do que isso. Acredite, vejo isso acontecendo todos os dias! Para verificar, basta fazer o seguinte: inspecione a imagem clicando com o botão direito nela e selecionando 'inspecionar elemento' (inspect). 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 com Eager Loading

Para obter a melhor performance do seu LCP, você deve aplicar o eager loading no elemento LCP visível (e aplicar o lazy load em imagens que não são imediatamente visíveis). Este é um dos erros mais comuns na otimização do LCP, e nós o abordamos em detalhes em nosso artigo sobre como consertar imagens LCP carregadas com lazy loading.

Eager Loading: O elemento LCP (geralmente conteúdo acima da dobra) deve sempre ser carregado de forma antecipada (eagerly). Isso garante que ele apareça o mais rápido possível, reduzindo o tempo que leva para o seu Largest Contentful Paint ser renderizado. Por padrão, as imagens carregam antecipadamente 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 sua pontuação no Core Web Vitals. É importante entender que loading="eager" é o comportamento padrão do navegador, portanto, omitir o atributo inteiramente 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 HTML secundário super rápido que enfileira recursos importantes imediatamente. Quando o preload scanner é ignorado, o navegador terá que esperar que o mecanismo de renderização seja concluído antes de enfileirar '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 é calculado, o navegador pode 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 seguir. Ao atrasar o carregamento dessas imagens até que o usuário role a página 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 LCP; se usado incorretamente, ele o atrasará!

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

O equilíbrio? Carregue de forma antecipada (eager load) o conteúdo crítico (como a 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 LCP diz ao navegador para buscá-la imediatamente, antes que ele a descubra naturalmente no HTML. Para um guia completo sobre preloading, veja nosso artigo dedicado sobre como fazer 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 certa ordem. Às vezes, a imagem LCP é referenciada mais abaixo na cadeia, o que significa que o navegador chega a ela mais tarde do que deveria. Fazer o preload da imagem LCP permite que o navegador saiba antecipadamente 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 LCP

Ao usar 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 muitas vezes ocorre se a imagem estiver enterrada 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. Atenha-se ao que mais importa para o seu Core Web Vitals.

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

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

O Tempo do 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, o que pode facilmente adicionar 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 ser exibida imediatamente, sem nenhuma transição ou animação.

Pule os fade-ins na imagem LCP. O efeito visual não vale o custo de performance.

8. Faça o Self-Host do Elemento LCP

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

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

Reduza as Dependências Externas: Quando o seu elemento LCP (como uma imagem) está 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.

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

Controle Sobre a Otimização de Imagem: O self-hosting lhe dá 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 o Client-Side Rendering para o Elemento LCP

Client-side rendering (CSR) é uma das piores coisas que você pode fazer ao 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 leva a 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 é exibido apenas depois que o navegador processa o JavaScript, o que pode atrasar significativamente sua aparência. Quanto mais tempo isso leva, 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 Server-Side Rendering (SSR) ou Renderização Estática: Ao renderizar o elemento LCP no server-side ou como parte de uma resposta HTML estática, você permite que o navegador o carregue e o exiba imediatamente, sem esperar o JavaScript entrar em ação. Isso melhora drasticamente o tempo do LCP, pois o navegador pode renderizar o elemento LCP imediatamente quando ele começa a carregar o HTML.

Minimize o JavaScript no Caminho Crítico (Critical Path): Se você não conseguir evitar alguns scripts no client-side, certifique-se de 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 aparição do seu LCP.

10. Reserve Espaço para Prevenir Layout Shifts

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

Visão de Especialista: O 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 um aspect ratio e manter o espaço, mas a imagem ainda será perfeitamente responsiva se seu CSS estiver 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 que qualquer CSS que bloqueie a renderização seja baixado e analisado, dando a ele uma vantagem crítica.

Lidando com Imagens de Fundo (Background Images) em CSS

Esse princípio também se aplica a elementos que servem como contêineres para um background-image CSS. Uma fonte comum de layout shift é uma <div> que colapsa para altura zero inicialmente e, em seguida, salta para 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. Audite o Bloqueio da Main-Thread

Mesmo que sua imagem LCP esteja perfeitamente otimizada e priorizada, sua renderização final pode ser atrasada se a main thread do navegador estiver ocupada executando JavaScript pesado. Frequentemente, a fonte desse bloqueio são scripts de terceiros para análises (analytics), anúncios ou widgets de suporte ao cliente. Esses scripts podem monopolizar a CPU, aumentando o Element Render Delay. Use o painel de Performance no Chrome DevTools para identificar tarefas de longa duração durante o carregamento inicial, atribua-as à sua fonte e adie ou remova qualquer uma que não seja crítica para a renderização inicial. Para saber mais sobre esse tópico, consulte nosso guia sobre Element Render Delay.

Guias Relacionados de Otimização de LCP

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

• Corrija &amp; Identifique Problemas de 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 uma estrutura HTML otimizada.
• 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 main thread para que o navegador possa pintar o elemento LCP imediatamente após o download.