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 sofre. Este artigo cobre todas as técnicas para deixá-la rápida.

Segundo o Google, apenas 65% de todas as visualizações de página na internet (isso inclui desktop e mobile) têm uma pontuação 'boa' de Largest Contentful Paint. Isso significa que 35% das visualizações de página reprovam. Isso ocorre em parte por erros cometidos com imagens. Este artigo detalha padrões de boas práticas comuns e erros de quando 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 ela carregue o mais rápido possível!

Experimentos com o Largest Contentful Paint

Eu sempre digo: ouça e aprenda, mas não confie cegamente em ninguém. Existem muitos 'gurus' por aí pregando informações erradas. É por isso que criei um experimento de 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 o 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 eles aceleram ou atrasam o elemento de imagem do LCP.

1. Controle o candidato a LCP: A estratégia text-first

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

Por que texto é mais rápido do que uma imagem. A diferença de desempenho se resume ao pipeline de solicitações. Um nó de texto (como um <h1> ou <p>) faz parte do documento HTML principal. Ele não possui uma solicitação de recurso separada; sua renderização é bloqueada apenas pelo CSS. Uma imagem, por outro lado, é um recurso externo que exige a sua própria solicitaçã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 desempenho e a razão de por que controlar o candidato a LCP é uma estratégia poderosa e de nível avançado.

Então, qual é o argumento para imagens versus texto? 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 é baseado em texto, ele geralmente ocorre junto com o First Contentful Paint.

Então você deve mudar para um elemento Largest Contentful Paint baseado em texto? Isso depende! As imagens importam e elas deixam o seu site visualmente atraente. Isso significa que você não me ouvirá defender a mudança para elementos de texto antigos e chatos. Mas erros também acontecem! Eu gostaria de ganhar um dólar por 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 atrase os tempos de carregamento em segundos. Isso geralmente acontece quando os designers colocam um grande banner hero no topo do DOM, antes de qualquer título significativo, 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 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 imagens, veja nosso guia sobre otimização de imagens.

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

O trade-off entre velocidade de decodificação e compactação

Embora o AVIF ofereça a melhor compactaçã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 que ocorre nas threads do Rasterizer do navegador e aumenta diretamente o Atraso de renderização do elemento. Um AVIF menor pode ser baixado mais rápido, mas seu tempo de decodificação maior 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" longas associadas ao seu elemento LCP. Se você vir isso, é um sinal claro de que a velocidade de decodificação é o seu gargalo, e 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 recompactar sem perdas JPEGs existentes (uma grande vitória para sites legados) e pelo seu suporte à decodificação progressiva, algo que o AVIF não possui. No entanto, sua desvantagem decisiva é a falta de amplo suporte nos navegadores depois de ser abandonado pelo Chrome. Isso o torna ainda não viável para uso geral na web, mas o posiciona como um formato para ficar de olho no futuro.

Usando o elemento <picture>: O elemento <picture> permite que os navegadores ignorem formatos de imagem não suportados, selecionando o primeiro com o qual 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 negociação de formato com tamanhos responsivos

Para obter o 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 o 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 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>

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 receberá um pequeno arquivo AVIF, enquanto um navegador desktop mais antigo fará o fallback para um JPEG de tamanho correto.

Usando a negociação de conteúdo

A negociação de conteúdo permite que o seu servidor sirva diferentes formatos de imagem com base no suporte do navegador. Os navegadores anunciam os formatos suportados pelo 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 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 os 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 de desktop grande, o navegador baixará uma imagem enorme 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), resultando em desperdício de largura de banda e em um LCP mais lento. O atributo sizes fornece o contexto de layout necessário, informando ao navegador qual será a largura real da imagem em diferentes breakpoints do viewport. Isso permite que ele faça uma escolha de download inteligente.

Entendendo os descritores w vs. x

O atributo srcset suporta dois tipos de descritores. Para o design responsivo, onde o tamanho de uma imagem muda com o 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 tamanho real da imagem no layout. Isso 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. Dimensione suas imagens para o tamanho da tela!

Evite servir imagens maiores que o necessário. Se o elemento LCP tiver apenas 600px de largura no viewport, certifique-se de que a imagem não seja maior do que isso. Acredite, eu 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 elemento'. Você agora verá o dev-tools e o HTML da imagem destacado com um fundo azul. Você pode ver agora 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. Redimensionar a imagem poderia ter economizado pelo menos 50% do tamanho do arquivo.

5. Carregue as imagens LCP imediatamente

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

Carregamento imediato: O elemento LCP (geralmente conteúdo acima da dobra) sempre deve ser carregado imediatamente. 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 carregam imediatamente 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 do 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 nerd: Imagens com lazy loading não são colocadas na fila 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 precisará esperar que o mecanismo de renderização termine antes de enfileirar 'imagens visíveis'. Para que o navegador avalie o loading="lazy" nativo, ele primeiro deve baixar e analisar todo o CSS render blocking para construir a árvore de renderização. 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 de bloqueio 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 um conteúdo mais importante, como o seu elemento LCP. Dessa forma, o lazy loading é uma faca de dois gumes: se usado corretamente, ele acelerará o 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 imediatamente o conteúdo crítico (como sua imagem LCP) e use lazy loading nos recursos menos críticos e imagens abaixo da dobra!

6. Pré-carregue a imagem LCP

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

Por que pré-carregar a imagem LCP?

Quando o navegador carrega uma página, ele processa o HTML, os arquivos CSS e os scripts em uma certa ordem. Às vezes, a imagem LCP é referenciada mais para baixo, o que significa que o navegador a alcança mais tarde do que deveria. O pré-carregamento da imagem LCP avisa ao navegador de imediato que essa imagem é crítica e deve ser carregada imediatamente. Isso reduz o atraso na renderização do seu maior elemento.

Como pré-carregar a 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 geralmente ocorre se a imagem estiver enterrada 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: Pré-carregue apenas a imagem LCP. Pré-carregar muitos recursos pode sobrecarregar o navegador e prejudicar o desempenho. Fique com o que é mais importante 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 (geralmente uma imagem) usar 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 as suas métricas de desempenho.

O tempo do LCP acontece após a animação terminar: O navegador considera o LCP completo 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 de LCP.

Mantenha a simplicidade: 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 aparecer imediatamente, sem nenhuma transição ou animação.

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

8. Hospede o elemento LCP você mesmo

Hospede a sua imagem LCP no próprio servidor. Depender de servidores de terceiros introduz atrasos que estão completamente fora de seu controle. Isso pode prejudicar o seu LCP e o desempenho geral da página.

Pense desta forma: Não hospedar o seu elemento LCP no próprio servidor é como pedir açúcar constantemente emprestado para o seu vizinho. Toda vez, você tem que caminhar 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 o seu site espere por esse recurso externo, atrasando os tempos de carregamento. A hospedagem própria é 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 adicionais de ida e volta (RTT) desse servidor. A hospedagem própria elimina essa incerteza. Você pode servir a imagem diretamente do seu próprio servidor, garantindo uma entrega mais rápida e confiável.

Use cache e otimizações: Ao hospedar você mesmo, 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: A hospedagem própria oferece a você controle sobre como a imagem é otimizada, seja por compactação, redimensionamento ou seleção de formato, sem depender do manuseio de terceiros. Dessa forma, você pode garantir que a imagem seja perfeitamente adaptada para um carregamento rápido.

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

A renderização no lado do cliente (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 frequentemente levará a tempos de LCP mais lentos. O navegador terá que esperar que os scripts sejam baixados, analisados e executados antes de exibir o conteúdo crítico.

Atrasos na renderização: Com o CSR, o elemento LCP só é exibido após o navegador processar o JavaScript, o que pode atrasar significativamente a sua aparência. Quanto mais isso demorar, pior será a sua pontuação do LCP. Cada segundo extra gasto processando scripts se traduz em uma espera maior para que os 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 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 que o JavaScript entre em ação. Isso melhora drasticamente o tempo do LCP, pois o navegador pode renderizar o elemento LCP logo de cara quando começa a carregar o HTML.

Minimize o JavaScript no Caminho Crítico: Se você não conseguir evitar alguns scripts no lado do cliente, 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 o aparecimento do seu LCP.

10. Reserve espaço para evitar mudanças de layout

Sempre inclua atributos width e height explícitos em suas tags <img>. Esta é uma instrução crítica para o navegador. Ela permite calcular a proporção da imagem e reservar a quantidade correta de espaço no layout antes da imagem ser baixada.

Visão de especialista: O comportamento moderno do width e do height

Um erro comum é pensar que esses atributos tornam a imagem não responsiva. Isso não é mais verdade nos navegadores modernos. O navegador usa esses atributos HTML para calcular 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. O navegador consegue reservar o espaço antes de baixar e analisar qualquer CSS render blocking, o que dá a ele uma vantagem crucial.

Lidando com Background Images no CSS

Esse princípio também se aplica a elementos que servem como contêineres para uma background-image no CSS. Uma fonte comum de mudança de layout é uma <div> que inicialmente tem altura zero e depois "pula" para o tamanho final 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 a sua imagem LCP esteja perfeitamente otimizada e priorizada, a renderização final dela pode ser atrasada se a main thread do navegador estiver ocupada executando um JavaScript pesado. Muitas vezes, a fonte 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 de Performance no Chrome DevTools para identificar as long tasks durante o carregamento inicial, atribua-as à sua origem e adie ou remova as que não forem críticas para a renderização inicial. Para saber mais sobre esse tópico, veja nosso guia sobre o Atraso de renderização do elemento.

Guia passo a passo: Diagnosticar o LCP com o painel de Performance do Chrome DevTools mostra como gravar um trace com throttling e encontrar essas long tasks na trilha Main.

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:

• Como corrigir e identificar problemas de LCP: A metodologia de diagnóstico completa para encontrar e corrigir problemas de LCP usando field data e ferramentas de laboratório.
• Atraso de carregamento de recurso: 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 de recurso: Reduza o tempo de download por meio de compactaçã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.