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 do LCP é uma imagem. Erre na imagem e a sua pontuação do LCP vai sofrer. 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 falham e isso ocorre, em parte, por erros cometidos com imagens. Este artigo detalha padrões de boas práticas e erros comuns quando imagens se tornam o elemento do Largest Contentful Paint.

Embora todos esses fatores importem, se o seu elemento do 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 nas palavras dos outros. Há muitos 'gurus' por aí pregando informações erradas. É por isso que criei um experimento do LCP totalmente automático onde você pode ver por si mesmo o que acontece quando o elemento do LCP não é carregado da forma ideal. Confira o meu Teste de LCP no github ou experimente a demo ao vivo!

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

1. Controle o candidato do LCP: A estratégia de priorizar texto

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

Por que o texto é mais rápido do 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 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 pelo CSS. Essa distinção é o motivo central para a diferença de desempenho e por que controlar o candidato do LCP é uma estratégia poderosa de nível avançado.

Então, qual é o argumento das imagens em relação ao texto? As imagens são importantes; elas deixam o seu site visualmente atraente. Mas o Core Web Vitals não se importa com qual elemento se torna o LCP. Quando o elemento do LCP é um elemento baseado em texto, ele geralmente ocorre junto com o First Contentful Paint.

Então, você deve mudar para um elemento do Largest Contentful Paint baseado em texto? Depende! As imagens importam e elas deixam o seu site visualmente atraente. Isso significa que você não vai me ouvir defender a mudança para velhos e chatos elementos de texto. 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". Isso acontece 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 frequentemente ocorre quando os designers colocam um banner hero grande bem no topo do DOM, antes de quaisquer títulos significativos, deixando o navegador sem escolha a não ser selecionar um candidato de 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 em uma coisa: os formatos antigos como JPEG e PNG são maiores e mais lentos em comparação com os formatos modernos como WebP ou AVIF. Para uma visão completa sobre técnicas de otimização de imagens, veja o nosso guia de otimização de imagem.

Como regra geral, você deve servir uma versão lossy em WebP ou AVIF da sua imagem do LCP (melhor ainda, use esses formatos para todas as suas imagens, mas aqui o foco é o LCP). Com o suporte a WebP em torno de 95% e o suporte a AVIF em 92%, ainda faz sentido servir também imagens antigas de fallback. Para fazer isso, use o 'aprimoramento progressivo', onde servimos esses formatos modernos apenas para os navegadores que oferecem suporte a eles.

O 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. Esta é uma tarefa vinculada à CPU que acontece nas threads do Rasterizador 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 do 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 de especialistas precisa abordar o JPEG XL. Ele é um formato tecnicamente notável, especialmente por sua capacidade de re-comprimir JPEGs existentes de forma lossless (uma enorme vitória para sites legados) e seu suporte para decodificação progressiva, algo que o AVIF não tem. No entanto, sua desvantagem decisiva é a falta de amplo suporte por parte dos navegadores após ser abandonado pelo Chrome. Isso o torna ainda inviável para uso geral na web, mas o posiciona como algo para se observar 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 desempenho máximo, 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 mobile em um navegador compatível vai receber um arquivo AVIF pequeno, enquanto um navegador desktop mais antigo vai recorrer ao fallback de um JPEG com tamanho correto.

Usando 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 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 do LCP, o tamanho realmente importa. Uma das vitórias mais fáceis é servir as imagens com as menores dimensões possíveis, desde que ainda fiquem boas nas telas dos seus usuários. Imagens grandes não têm utilidade nenhuma: 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 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 é fundamental

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 grande de desktop, o navegador baixará uma imagem enorme da sua lista do srcset, mesmo que a imagem seja exibida apenas em uma pequena coluna de 500px. Você forneceu os ingredientes certos (srcset), mas deixou a receita de fora (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, o que 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 um design responsivo onde o tamanho de uma imagem muda com o viewport, o descritor w (largura) é a escolha superior e necessária. Ele é usado junto 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. 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 que sejam maiores do que o necessário. Se o elemento do LCP tem apenas 600px de largura no viewport, certifique-se de que a imagem não seja maior do que isso. Acredite em mim, eu vejo isso acontecer todos os dias! Para verificar, basta fazer o seguinte: inspecione a imagem clicando com o botão direito sobre ela e selecione '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 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 do LCP com Eager Loading

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

Carregamento imediato (Eager Loading): O elemento do LCP (geralmente o 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 de renderização do Largest Contentful Paint. Por padrão, as imagens carregam de forma eager, a menos que especificado o contrário, mas verifique novamente se você não definiu loading="lazy" na imagem do LCP. Fazer isso pode atrasar significativamente o LCP e prejudicar a sua pontuação do Core Web Vitals. É importante entender que loading="eager" é o comportamento padrão do navegador, então omitir totalmente o atributo 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 precisará esperar a conclusão do mecanismo de renderização antes de enfileirar 'imagens visíveis'. Para que o navegador avalie o loading="lazy" nativo, ele primeiro precisa baixar e processar todo o CSS render blocking para construir a árvore de renderização. Somente depois que o layout é calculado o navegador consegue 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 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 inicialmente), o 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údos mais importantes, como o seu elemento do LCP. Dessa forma, o lazy loading é uma faca de dois gumes: se usado corretamente, ele vai acelerar o seu conteúdo do LCP; se usado incorretamente, ele vai atrasá-lo!

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

O equilíbrio? Carregue de forma imediata (eager) o conteúdo crítico (como a sua imagem do LCP) e use o 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 preload, veja o 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 para baixo na cadeia, o que significa que o navegador chega a ela mais tarde do que deveria. Fazer o preload da imagem do LCP avisa o navegador antecipadamente de 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ê pode garantir 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 frequentemente ocorre se a imagem estiver enterrada no CSS ou em scripts.

<!-- No <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">

<!-- No <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, já que fazer o preload de muitos recursos pode sobrecarregar o navegador e prejudicar o desempenho. Concentre-se no que mais importa para o seu Core Web Vitals.

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

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

O timing 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 o conteúdo tenha aparecido completamente, o que pode facilmente adicionar segundos extras à sua pontuação do LCP.

Mantenha a simplicidade: Para garantir que o elemento do 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 os fade-ins na imagem do LCP. O efeito visual não vale o custo de desempenho.

8. Faça o self-host do elemento do 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 o seu LCP e o desempenho geral da página.

Pense da seguinte forma: Não fazer o self-host do seu elemento do LCP é como pedir açúcar emprestado constantemente para o seu vizinho. Toda vez, você tem que andar 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. O self-host é como manter o açúcar na sua cozinha: rápido, direto e confiável.

Reduza as dependências externas: Quando o seu elemento do LCP (como uma imagem) é hospedado em um servidor de terceiros, você fica à mercê da velocidade, da disponibilidade e de quaisquer tempos de ida e volta (RTT) adicionais desse servidor. O self-host elimina essa incerteza, permitindo que você sirva a imagem diretamente do seu próprio servidor, o que garante 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 ao usuário, especialmente se você estiver usando um CDN. Isso reduz o tempo que leva para carregar o elemento do LCP, o que resulta em uma renderização mais rápida.

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

9. Evite o Client-Side Rendering para o elemento do LCP

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

Atrasos na renderização: Com o CSR, o elemento do LCP só é exibido depois que o navegador processa o JavaScript, o que pode atrasar significativamente a sua aparência. Quanto mais tempo isso demorar, pior será a sua pontuação do LCP. Cada segundo extra gasto processando scripts se traduz em uma espera maior para os seus usuários verem o conteúdo mais importante.

Mude para Server-Side Rendering (SSR) ou Renderização Estática: Ao renderizar o elemento do 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 timing do LCP, pois o navegador pode renderizar o elemento do LCP imediatamente quando ele começa a carregar o HTML.

Minimize o JavaScript no caminho crítico: Se você não puder evitar alguns scripts no lado do cliente, certifique-se de que eles não bloqueiem a renderização do elemento do 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 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 da imagem (aspect ratio) e reserve a quantidade correta de espaço no layout antes que a imagem seja baixada.

Visão de especialista: O comportamento moderno do width e do 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 o seu CSS estiver definido como width: 100%; height: auto;. Fornecer esses atributos é superior a usar apenas a propriedade CSS aspect-ratio, pois o navegador consegue reservar o espaço antes que qualquer CSS render blocking tenha sido baixado e processado, dando a ele uma vantagem crítica.

Lidando com imagens de background no CSS

Esse princípio também se aplica aos elementos que servem como contêineres para um background-image no CSS. Uma fonte comum de layout shift é uma <div> que colapsa para uma altura zero inicialmente e depois surge com o seu tamanho real quando a imagem de background é 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 uma auditoria para bloqueios na main thread

Mesmo se a sua imagem do LCP estiver perfeitamente otimizada e priorizada, a sua renderização final pode ser atrasada se a main thread do navegador estiver ocupada executando um JavaScript pesado. Frequentemente, a origem 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 as long tasks durante o carregamento inicial, atribua-as à sua origem e adie ou remova aquelas que não são críticas para a renderização inicial. Para mais detalhes sobre este tópico, veja nosso guia sobre Element Render Delay.

Guia passo a passo: O guia Diagnostique o LCP com o painel Performance do Chrome DevTools mostra como gravar um trace com throttling (limitação de velocidade) e encontrar essas long tasks na trilha Main.

Guias de otimização de LCP relacionados

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

• Corrija &amp; Identifique Problemas do LCP: A metodologia de diagnóstico completa para encontrar e corrigir problemas de LCP usando field data e ferramentas de laboratório.
• Resource Load Delay: Garanta que o navegador descubra o seu recurso do LCP o mais cedo possível com preload, fetchpriority e uma estrutura HTML ideal.
• 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 main thread para que o navegador possa pintar o elemento do LCP imediatamente após o download.