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. Se a imagem estiver errada, sua pontuação de LCP sofre. Este artigo cobre todas as técnicas para torná-la rápida.

Segundo o Google, apenas 65% de todas as visualizações de página na internet (e isso inclui tanto desktop quanto mobile) têm uma pontuação 'boa' 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 imagens se tornam o elemento Largest Contentful Paint.

Embora todos esses fatores importem, se o seu elemento LCP é 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 aceite a palavra de ninguém. Existem muitos 'gurus' pregando informações erradas. É por isso que criei um experimento de LCP totalmente automático onde você pode verificar por conta própria o que acontece quando o elemento LCP não é carregado de forma otimizada. Confira meu Teste de LCP no github ou experimente a demo ao vivo!

Ele testará automaticamente múltiplos cenários de LCP para você e mostrará os resultados. Discutirei esses cenários abaixo e explicarei como e por que eles aceleram ou desaceleram o elemento de imagem LCP.

1. Controle o Candidato a 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ê ouviu certo. Deixe-me explicar.

Por Que Texto é Mais Rápido Que uma Imagem. A diferença de desempenho 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 requisição de recurso separada; seu rendering é bloqueado 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 bloqueado pelo CSS. Esta distinção é a razão central para a diferença de desempenho e por que controlar o candidato a LCP é uma estratégia poderosa de nível avançado.

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

Então você deveria mudar para um elemento de Largest Contentful Paint baseado em texto? Depende! Imagens importam e tornam seu site visualmente atraente. Isso significa que você não vai me ouvir defender a mudança para elementos de texto antigos e entediantes. Mas erros também acontecem! Eu queria ter um dólar para cada página de categoria que foi vítima do antipadrão "LCP Acidental". É quando uma página "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 atrasando os tempos de carregamento em segundos. Isso frequentemente acontece quando designers colocam um grande banner hero no topo do DOM, antes de qualquer título significativo, não deixando ao navegador outra escolha senão selecionar um candidato a LCP mais lento.

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

Sem entrar em um debate acalorado sobre extrair 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 comparados a formatos modernos como WebP ou AVIF. Para uma visão geral completa das técnicas de otimização de imagem, 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 suporte a WebP em torno de 95% e suporte a AVIF em 92%, ainda faz sentido servir imagens mais antigas como fallback. Para fazer isso, use 'progressive enhancement' 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 comparado ao WebP. Esta é uma tarefa limitada por CPU que acontece nas threads do Rasterizer 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 Performance do Chrome DevTools procurando tarefas longas de "Decode Image" associadas ao seu elemento LCP. Se você ver isso, é um sinal claro de que a velocidade de decodificação é seu gargalo, não apenas o tempo de download.

Insight Avançado: O Caso do JPEG-XL. Um guia verdadeiramente avançado deve abordar o JPEG XL. É um formato tecnicamente notável, especialmente por sua capacidade de recomprimir 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 ter sido removido do Chrome. Isso o torna ainda não viável para uso geral na web, mas o posiciona como um formato 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 podem 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 máximo 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, então usa os atributos srcset e sizes para escolher a resolução correta.

<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>

Este 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 compatível receberá um arquivo AVIF pequeno, enquanto um navegador desktop mais antigo usará um JPEG do tamanho correto como fallback.

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 servem para nada: desperdiçam largura de banda e desaceleram os tempos 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 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 custoso. Sem o atributo sizes, o navegador é forçado a assumir um valor padrão de 100vw (100% da largura do viewport). Isso significa que em uma tela desktop grande, 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 deixou de fora a receita (sizes), levando a desperdício de largura de banda e 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 do 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 o 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 no 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 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 no viewport, certifique-se de que a imagem não seja maior que isso. Confie em mim, vejo isso acontecendo todos os dias! Para verificar, basta fazer o seguinte: inspecione a imagem clicando com o botão direito na imagem e selecione 'inspecionar elemento'. Você verá agora as ferramentas de desenvolvedor e o HTML da imagem estará destacado com um fundo azul. Você pode então ver 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 Carregamento Eager para Imagens LCP

Para obter o melhor desempenho do seu LCP, você deve carregar eagerly o elemento LCP visível (e usar lazy loading para imagens que não são imediatamente visíveis). Este é um dos erros mais comuns na otimização de LCP, e o cobrimos em detalhes no nosso artigo sobre corrigir imagens LCP carregadas com lazy loading.

Eager Loading: O elemento LCP (geralmente conteúdo acima da dobra) deve sempre ser carregado eagerly. Isso garante que ele apareça o mais rápido possível, reduzindo o tempo necessário para o seu Largest Contentful Paint renderizar. Por padrão, as imagens carregam eagerly 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 de Core Web Vitals. É importante entender que loading="eager" é o comportamento padrão do navegador, então 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 o motor de rendering completar antes de enfileirar 'imagens visíveis'. Para o navegador avaliar o loading="lazy" nativo, ele deve primeiro baixar e processar todo o CSS que bloqueia o rendering para construir a render tree. Somente após o layout ser calculado o navegador pode determinar se a imagem está no viewport. Isso significa que todo o seu CSS se torna uma dependência bloqueante para o download da imagem 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), lazy loading é o caminho a seguir. Ao atrasar o carregamento dessas imagens até que o usuário role perto delas, você libera largura de banda para conteúdo mais importante, como seu elemento LCP. Dessa forma, lazy loading é uma faca de dois gumes: se usado corretamente, acelerará seu conteúdo LCP; se usado incorretamente, o desacelerará!

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

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

6. Faça Preload da Imagem LCP

Fazer preload da imagem LCP diz ao navegador para buscá-la imediatamente, antes de descobri-la naturalmente no HTML. Para um guia completo sobre preloading, veja nosso artigo dedicado sobre preload da imagem LCP.

Por Que Fazer Preload da Imagem LCP?

Quando o navegador carrega uma página, ele processa o HTML, folhas de estilo e 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. Fazer preload da imagem LCP informa ao navegador antecipadamente que esta imagem é crítica e deve ser carregada imediatamente, reduzindo o atraso na renderização do seu maior elemento.

Como Fazer 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 frequentemente ocorre se a imagem estiver escondida 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 preload apenas da imagem LCP, pois fazer preload de muitos recursos pode sobrecarregar o navegador e prejudicar o desempenho. Foque no que mais importa para seus Core Web Vitals.

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

Animações de fade-in podem ser visualmente atraentes, mas são um gargalo oculto do LCP. Se o elemento LCP (frequentemente uma imagem) usa 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 desempenho.

O Timing do LCP Acontece Após o Fim da Animação: O navegador considera o LCP completo apenas quando o elemento está totalmente visível. Se você tem uma animação de fade-in, o cronômetro continua rodando até que a imagem ou conteúdo tenha completamente aparecido com o fade, o que pode facilmente adicionar segundos extras à sua pontuação de 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 qualquer transição ou animação.

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

8. Hospede o Elemento LCP no Seu Próprio Servidor

Hospede sua imagem LCP no seu próprio servidor. 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 hospedar seu elemento LCP no seu próprio servidor é como constantemente pedir açúcar emprestado ao 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 seu LCP faz seu site esperar por esse recurso externo, desacelerando os tempos de carregamento. Hospedar no seu próprio servidor é 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) é hospedado em um servidor de terceiros, você fica à mercê da velocidade desse servidor, disponibilidade e quaisquer tempos de ida e volta (RTT) adicionais. Hospedar no seu próprio servidor elimina essa incerteza, permitindo que você sirva a imagem diretamente do seu próprio servidor, garantindo entrega mais rápida e confiável.

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

Controle Sobre Otimização de Imagem: Hospedar no seu próprio servidor dá a você controle sobre como a imagem é otimizada, seja compressão, redimensionamento ou seleção de formato, sem depender do tratamento de terceiros. Dessa forma, você pode garantir que a imagem esteja perfeitamente preparada para carregamento rápido.

9. Evite Rendering do Lado do Cliente para o Elemento LCP

Rendering do lado do cliente (CSR) é uma das piores coisas que você pode fazer com seu LCP. Se seu elemento LCP (geralmente uma imagem grande, bloco de texto ou vídeo) é renderizado no lado do cliente via JavaScript, isso frequentemente leva a tempos de LCP mais lentos, pois o navegador tem que esperar os scripts serem baixados, processados e executados antes de exibir o conteúdo crítico.

Atrasos na Renderização: Com CSR, o elemento LCP é exibido apenas após o navegador processar JavaScript, o que pode atrasar significativamente sua aparição. 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 seus usuários verem o conteúdo mais importante.

Mude para Server-Side Rendering (SSR) ou Rendering Estático: Ao renderizar o elemento LCP no lado do servidor ou como parte de uma resposta HTML estática, você permite que o navegador carregue e exiba-o imediatamente, sem esperar o JavaScript entrar em ação. Isso melhora drasticamente o timing do LCP, pois o navegador pode renderizar o elemento LCP imediatamente quando começa a carregar o HTML.

Minimize 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 o elemento LCP de ser renderizado. Adie ou use 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 atributos explícitos width e height nas suas tags <img>. Esta é uma instrução crítica para o navegador, permitindo que ele calcule a proporção da imagem e reserve a quantidade correta de espaço no layout antes que a imagem tenha sido baixada.

Insight Avançado: 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 reservar 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 de qualquer CSS que bloqueia o rendering ter sido baixado e processado, dando-lhe uma vantagem crítica.

Lidando com Imagens de Fundo CSS

Este princípio também se aplica a elementos que servem como contêineres para uma background-image CSS. Uma fonte comum de layout shift é um <div> que colapsa para altura zero inicialmente e depois aparece em tamanho quando a imagem de fundo é aplicada. Para prevenir 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 Thread Principal

Mesmo que sua imagem LCP esteja perfeitamente otimizada e priorizada, sua renderização final pode ser atrasada se a thread principal do navegador estiver ocupada executando JavaScript pesado. Frequentemente, a fonte desse bloqueio são scripts de terceiros para analytics, 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, atribuí-las à sua fonte e adiar ou remover quaisquer scripts que não sejam críticos para o rendering inicial. Para mais sobre este tópico, veja nosso guia sobre Element Render Delay.

Guias Relacionados de Otimização de LCP

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

• Corrigir e Identificar Problemas de LCP: A metodologia completa de diagnóstico 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 otimizada.
• Resource Load Duration: Reduza o tempo de download através 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.