I will start by listing the contents of the workspace directory to find the source file for "Optimize the Largest Contentful Paint Image". I will view the contents of the file `tmp_source_260703143245.json` to see if it contains the source text for the translation. I will view the `stateless_translate.py` file to understand the context of the translation process and how the input/output are structured. Otimize a imagem do Largest Contentful Paint

Otimize a imagem do Largest Contentful Paint

Este guia faz parte do hub de Largest Contentful Paint (LCP). Na maioria dos sites, o elemento LCP é uma imagem. Erre na imagem e sua pontuação de LCP sofrerá. Este artigo aborda 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 ocorre em parte por causa de erros cometidos com imagens. Este artigo detalha padrões comuns de boas práticas 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 é!), há etapas 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 na palavra de ninguém. Há "gurus" demais por aí pregando informações erradas. Por isso, criei um experimento de LCP totalmente automático onde você mesmo pode conferir o que acontece quando o elemento LCP não é carregado de forma ideal. Confira o meu LCP Test 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 desaceleram o elemento de imagem do LCP.

1. Controle o candidato a LCP: A estratégia de texto primeiro

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

Por que o texto é mais rápido do que uma imagem. A diferença de desempenho resume-se ao pipeline de requisição. Um nó de texto (como um <h1> ou <p>) faz parte do documento HTML principal. Ele não possui uma requisição de recurso separada; sua renderização é apenas bloqueada por 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 por CSS. Essa distinção é o motivo central para a diferença de desempenho e por que controlar o candidato a LCP é uma estratégia poderosa e avançada.

Então, qual é o argumento para imagens versus texto? Imagens são importantes; elas tornam 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 coocorre com o First Contentful Paint.

Então você deve mudar para um elemento Largest Contentful Paint baseado em texto? Depende! Imagens importam e tornam seu site visualmente atraente. Isso significa que você não vai me ver defendendo a mudança para elementos de texto antigos e sem graça. Mas erros acontecem! Eu gostaria de ganhar um dólar para cada página de categoria que foi vítima do anti-padrão "Accidental LCP". É aqui que uma página "se 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 o tempo de carregamento em segundos. Isso geralmente acontece quando designers posicionam um grande banner hero no topo do DOM, antes de qualquer título importante, não deixando escolha ao navegador 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 caloroso sobre economizar até o último byte ou sobre 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 de WebP ou AVIF da sua imagem de 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 também imagens de fallback mais antigas. Para fazer isso, use 'melhoria progressiva' (progressive enhancement), onde servimos esses formatos modernos apenas para navegadores que os suportam.

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 limitada pela CPU que ocorre 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 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 de especialista deve abordar o JPEG XL. É um formato tecnicamente notável, especialmente por sua capacidade de recomprimir JPEGs existentes sem perdas (uma enorme 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 dos navegadores depois de ter sido descartado pelo Chrome. Isso o torna ainda inviá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 que conseguem processar. 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 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 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, depois 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 compatível obterá um arquivo AVIF pequeno, enquanto um navegador desktop mais antigo fará 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 por meio 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

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 de 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 dos seus usuários. Imagens grandes não têm utilidade alguma: desperdiçam largura de banda e atrasam o tempo de carregamento, especialmente para usuários em 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 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 caro. 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 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, informando 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 os 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 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, o que 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. Redimensione suas imagens para o tamanho da tela!

Evite servir imagens maiores do que o necessário. Se o elemento LCP tiver apenas 600px de largura no viewport, garanta que a imagem não seja maior do que isso. Acredite, eu vejo isso acontecer todos os dias! Para verificar, basta fazer o seguinte: inspecione a imagem clicando com o botão direito nela e selecione "inspecionar". Você verá o devtools 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 do 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 de LCP com carregamento eager

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

Carregamento Eager: O elemento LCP (geralmente conteúdo acima da dobra) deve ser sempre carregado de forma eager. 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 são carregadas de forma eager, a menos que especificado de outra forma, mas verifique duas vezes se você não configurou loading="lazy" na imagem de 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 geek: Imagens com lazy loading não são enfileiradas pelo preload scanner. O preload scanner é um scanner HTML secundário ultrarrápido que enfileira recursos importantes imediatamente. Quando o preload scanner é ignorado, o navegador precisa esperar a conclusão do motor de renderização antes de enfileirar as "imagens visíveis". Para que o navegador avalie o loading="lazy" nativo, ele precisa primeiro baixar e analisar todo o CSS render blocking para construir a árvore de renderização. Somente após o layout ser calculado, o navegador poderá 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 de 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), o lazy loading é o caminho a seguir. Ao atrasar o carregamento dessas imagens até que o usuário role para perto delas, você libera largura de banda para conteúdos mais importantes, 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"
     loading="lazy" 
     width="800" height="400">

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

6. Faça o preload da imagem de LCP

Fazer o preload da imagem de LCP diz ao navegador para buscá-la imediatamente, antes que ele a descubra naturalmente no HTML. Para um guia completo sobre preload, consulte nosso artigo dedicado sobre como fazer o preload da imagem de LCP.

Por que fazer o preload da imagem de 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 de LCP é referenciada mais à frente na cadeia, o que significa que o navegador chega a ela mais tarde do que deveria. Fazer o preload da imagem de LCP informa ao navegador logo de início 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 de LCP

Ao usar a tag <link rel="preload">, você garante que o navegador comece a buscar a imagem de 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 de LCP esteja na fila do navegador desde o início, evitando a espera que geralmente ocorre se a imagem estiver enterrada em CSS ou 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 de LCP, pois fazer o preload de recursos demais pode sobrecarregar o navegador e prejudicar o desempenho. Concentre-se no que mais importa para o seu Core Web Vitals.

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

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

A medição do LCP ocorre após o término da animação: 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 continua 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 ser exibida imediatamente, sem qualquer transição ou animação.

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

8. Hospede você mesmo o elemento LCP

Hospede você mesmo sua imagem de LCP. Depender de servidores de terceiros introduz atrasos que estão completamente fora de seu controle, o que pode prejudicar seu LCP e o desempenho geral da página.

Pense assim: Não hospedar você mesmo o seu elemento LCP é como pedir açúcar emprestado ao vizinho o tempo todo. Toda vez, você precisa 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 seu site esperar por esse recurso externo, atrasando o tempo de carregamento. Hospedar você mesmo é como guardar o açúcar na sua própria 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 e disponibilidade desse servidor, além de qualquer tempo de ida e volta (RTT) adicional. Hospedar você mesmo elimina essa incerteza, permitindo que sirva a imagem diretamente do seu próprio servidor, garantindo uma entrega mais rápida e confiável.

Use caching e otimizações: Ao hospedar você mesmo, você pode tirar o máximo proveito das estratégias de cache e servir a imagem a partir 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 de imagem: Hospedar você mesmo lhe dá controle sobre como a imagem é otimizada, seja por compressão, redimensionamento ou seleção de formato, sem depender do tratamento de terceiros. Dessa forma, você garante que a imagem seja perfeitamente adaptada para um carregamento rápido.

9. Evite Client-Side Rendering para o elemento LCP

O Client-Side Rendering (CSR) é uma das piores coisas que você pode fazer para o 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, pois 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 CSR, o elemento LCP só é exibido após o navegador processar o JavaScript, o que pode atrasar significativamente seu surgimento. Quanto mais tempo isso levar, pior será sua pontuação de LCP. Cada segundo extra gasto no processamento de scripts se traduz em uma espera maior para seus usuários verem 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 exiba imediatamente, sem esperar que o JavaScript entre em ação. Isso melhora drasticamente o tempo de LCP, pois o navegador pode renderizar o elemento LCP logo de início, quando começa a carregar o HTML.

Minimize o JavaScript no caminho crítico (Critical Path): Se você não puder evitar alguns scripts no lado do cliente, garanta 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 exibição do seu LCP.

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

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

Visão de especialista: Comportamento moderno de width e height

Um mal-entendido comum é 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 a proporção (aspect ratio) e reservar o espaço, mas a imagem ainda será 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, pois o navegador pode reservar o espaço antes que qualquer CSS render blocking tenha sido baixado e analisado, dando-lhe uma vantagem de tempo crítica.

Tratando imagens de fundo (background-image) via CSS

Este princípio também se aplica a elementos que servem como contêineres para uma background-image de CSS. Uma fonte comum de mudança de layout é uma <div> que colapsa para altura zero inicialmente e depois surge no tamanho correto 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 de 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 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 do Chrome DevTools para identificar long tasks 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 informações sobre este tópico, consulte nosso guia sobre Element Render Delay.

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:

• 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.
• Resource Load Delay: Garanta que o navegador descubra o seu recurso LCP o mais cedo possível com preload, fetchpriority e uma 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: Libere a main thread para que o navegador possa pintar o elemento LCP imediatamente após o download.