Corrigir 'Defer Offscreen Images': Guia de Lazy Loading para Core Web Vitals

O que é 'defer offscreen images'?

O aviso defer offscreen images era uma auditoria do Lighthouse que sinalizava páginas com imagens que poderiam receber lazy loading. O Lighthouse sinalizava imagens que atendiam a todos estes critérios:

• A imagem termina abaixo de 3 vezes a altura do viewport.
  Quando uma imagem não tem lazy loading e termina abaixo de 3 vezes a altura da parte visível da página, e começa abaixo da parte visível da página.
• A imagem é maior que 0.02 MB ou leva mais de 50ms para carregar.
  Imagens que são pequenas ou inlined são ignoradas. Scripts de lazy loading frequentemente usam pequenas imagens de espaço reservado (placeholder) que ficam abaixo desse limite.
• A imagem não tem o atributo loading definido.
  O Lighthouse ignora imagens que têm o atributo loading="lazy" ou loading="eager".

Esta auditoria foi removida no Lighthouse 13

A partir do Lighthouse 13 (outubro de 2025), esta auditoria foi totalmente removida. A equipe do Chrome determinou que os navegadores modernos já despriorizam imagens fora da tela, então a auditoria gerava mais ruído do que feedback útil.

Mas aqui está a questão: a otimização em si ainda é importante. O lazy loading de imagens fora da tela reduz a largura de banda, libera conexões de rede para recursos críticos e melhora seu Largest Contentful Paint (LCP). O fato de o Lighthouse não sinalizar mais isso significa que você mesmo precisa verificar. Use Real User Monitoring ou audite manualmente suas páginas em busca de imagens que carregam sem loading="lazy".

Um lembrete rápido: o que é lazy loading?

Lazy loading significa que imagens que não estão na parte visível da página são carregadas em um momento posterior, geralmente logo antes de rolarem para a área de visualização. O navegador só busca a imagem quando o usuário chega perto dela. Isso economiza largura de banda e permite que o navegador se concentre nos recursos que realmente importam para a renderização inicial.

O que causa o carregamento antecipado (eager loaded) de imagens fora da tela?

As imagens não são adiadas por padrão. Imagens fora da tela que não são adiadas acabam na página porque o atributo loading está ausente ou a imagem não é tratada por uma biblioteca de lazy loading. Causas comuns:

• Plugins mal codificados no seu CMS.
• Plugins que desativam o lazy loading nativo.
• Imagens de fundo (estas precisam de uma abordagem diferente do loading="lazy").
• Construtores de páginas (page builders) que geram HTML ruim (por exemplo: Elementor ou WP Bakery).
• Texto que é copiado e colado em um editor WYSIWYG (como TinyMCE).
• Codificação ruim de templates.

Como as imagens fora da tela afetam seus Core Web Vitals?

Imagens fora da tela não impactam diretamente as métricas do Lighthouse. Mas elas tornam a renderização de uma página da web desnecessariamente complicada. Seu navegador precisará baixar mais recursos antes que a página possa ser exibida na tela. Existem 3 problemas com o carregamento antecipado de imagens fora da tela:

• Mais downloads antes da renderização. Seu navegador precisará baixar imagens que o usuário ainda não consegue ver.
• Recursos críticos são despriorizados. As imagens competem por largura de banda com recursos que são realmente necessários para a renderização, como o seu CSS e a sua imagem de LCP.
• Maior uso de memória. Decodificar imagens até as quais o usuário ainda não rolou desperdiça memória, especialmente em dispositivos móveis de baixo desempenho.

De acordo com o capítulo de Peso da Página do Web Almanac de 2025, a página móvel mediana carrega 15 imagens. No 90º percentil, esse número salta para 52. Em páginas com muitas imagens, o lazy loading daquelas que estão fora da tela pode fazer uma diferença real. Em todos os sites monitorados pelo CoreDash, 76% das páginas que aplicam corretamente o lazy loading em imagens fora da tela passam no LCP, em comparação com 59% das páginas que não o fazem.

Como corrigir 'defer offscreen images'

Para corrigir imagens fora da tela carregadas antecipadamente, adicione loading="lazy" a cada imagem que estiver abaixo da dobra (below the fold). O lazy loading nativo agora é suportado por 95% dos navegadores globalmente, incluindo Chrome, Firefox, Safari e Edge. Você não precisa de uma biblioteca para isso.

<img loading="lazy"
     src="image.webp"
     alt="uma imagem com lazy loading nativo"
     width="300" height="300">

Rastreie as origens das suas imagens carregadas antecipadamente. Verifique quais imagens carregam sem um atributo loading e descubra o que as está colocando na página. Existem 5 suspeitos habituais:

1. Plugins mal codificados no seu CMS.
   Alguns plugins adicionam HTML diretamente à página e não usam os hooks corretos que habilitam o lazy loading.
2. Plugins que desativam o lazy loading nativo.
   Alguns plugins desativam o lazy loading nativo por padrão. Verifique as configurações do seu plugin.
3. Construtores de páginas que geram HTML ruim.
   Construtores de páginas como Elementor ou WP Bakery frequentemente criam códigos inchados que estão longe da perfeição. Não há uma solução fácil para isso. A solução inclui limpar o seu código e mudar o seu fluxo de trabalho.
4. Texto copiado e colado em um editor WYSIWYG.
   A maioria dos editores WYSIWYG, como o TinyMCE, faz um péssimo trabalho ao limpar o código colado, especialmente quando colado de outra fonte de rich text como o Microsoft Word. Esses editores podem não adicionar lazy loading às suas imagens.
5. Codificação ruim de templates.
   Mesmo quando o lazy loading está habilitado, imagens hardcoded em seus templates ainda podem não receber lazy loading. Verifique seus templates em busca de imagens fora da tela e aplique lazy loading nelas.

Não aplique lazy loading na sua imagem de LCP

Esta é a regra mais importante do lazy loading: nunca aplique loading="lazy" à sua imagem de Largest Contentful Paint. A imagem de LCP é quase sempre a hero image ou o maior elemento visível no viewport. De acordo com o Web Almanac de 2025, 16% das páginas móveis ainda aplicam lazy loading na sua imagem de LCP. Esse único atributo pode adicionar de 200 a 500 milissegundos ao seu LCP.

Em vez disso, faça o oposto para sua imagem de LCP. Certifique-se de que ela carregue o mais rápido possível com fetchpriority="high":

<img fetchpriority="high"
     loading="eager"
     src="hero.webp"
     alt="Hero image"
     width="1200" height="600">

Se você acidentalmente aplicou lazy loading na sua imagem de LCP, leia como corrigir uma imagem de LCP carregada preguiçosamente (lazily loaded). Para um guia completo sobre como otimizar imagens, consulte otimizar imagens para os Core Web Vitals.

Cheatsheet de carregamento de imagens

Nem toda imagem deve ser tratada da mesma maneira. Veja como lidar com os 4 cenários mais comuns:

Lazy loading nativo vs scripts de lazy loading

Use o loading="lazy" nativo. Em 2026, não há motivo para adicionar uma biblioteca de lazy loading em JavaScript para elementos <img> padrão. O lazy loading nativo é suportado por todos os principais navegadores, incluindo o Safari (desde a versão 15.4), cobrindo 95% dos usuários globalmente. Ele requer zero JavaScript, adiciona zero sobrecarga (overhead) e funciona perfeitamente (out of the box).

Bibliotecas como o lazysizes eram essenciais antes de os navegadores suportarem o lazy loading nativo. Elas não são mais mantidas e não são mais necessárias para a maioria dos sites. Os únicos cenários em que você ainda pode precisar de uma solução em JavaScript:

• Imagens de fundo em CSS. O lazy loading nativo só funciona em elementos <img> e <iframe>. Para imagens de fundo você precisa de IntersectionObserver ou content-visibility: auto.
• Limites (thresholds) de carregamento personalizados. O Chrome começa a carregar imagens "lazy" aproximadamente 1250px abaixo do viewport em conexões rápidas e 2500px em conexões lentas. Você não pode personalizar essa distância. Se você precisa de um controle mais rigoroso, um IntersectionObserver com um rootMargin personalizado oferece isso.

Se você realmente precisa de uma biblioteca, use vanilla-lazyload em vez do lazysizes. Ela é mantida ativamente, usa IntersectionObserver e suporta imagens de fundo.

Previna a mudança de layout (layout shift) em imagens com lazy loading

Sempre inclua os atributos width e height em imagens com lazy loading. Sem dimensões explícitas, o navegador não sabe quanto espaço reservar. Quando a imagem finalmente carrega, ela empurra o conteúdo ao redor para baixo, causando Cumulative Layout Shift (CLS). De acordo com o Web Almanac de 2025, 62% das páginas móveis ainda têm pelo menos uma imagem sem dimensões.

<!-- Ruim: causa mudança de layout -->
<img loading="lazy" src="photo.webp" alt="Foto">

<!-- Bom: dimensões reservam espaço -->
<img loading="lazy" src="photo.webp" alt="Foto" width="800" height="600">

Soluções alternativas (workarounds) quando você não pode aplicar lazy loading

Às vezes não é possível adiar imagens fora da tela. Você pode não ter acesso ao template ou o seu CMS pode não suportar lazy loading. Existem algumas soluções alternativas para diminuir o impacto. Elas estão longe de serem perfeitas e podem introduzir novos desafios.

• Comprima suas imagens. Imagens menores têm um impacto menor na performance de carregamento do que imagens grandes. Use técnicas modernas de compressão para reduzir o tamanho do arquivo.
• Use formatos de imagem mais rápidos. Mude de PNG e JPEG para WebP ou AVIF. O WebP comprime para cerca de 1.3 bits por pixel em comparação com 2.0 para JPEG, de acordo com o capítulo de Mídia do Web Almanac de 2024.
• Divida páginas grandes em várias páginas. Dividir páginas grandes reduz o número de imagens que precisam carregar de uma só vez.
• Implemente scroll infinito (infinite scroll). O scroll infinito é basicamente lazy loading, apenas não para imagens, mas para partes inteiras da página da web. Para páginas com muitos elementos repetidos (pense no Pinterest), o scroll infinito pode acelerar consideravelmente o carregamento inicial.

Para considerações específicas para dispositivos móveis, imagens fora da tela são um problema ainda maior porque as conexões móveis são mais lentas e os viewports móveis são menores, o que significa que mais imagens acabam fora da tela.

Qualquer que seja a abordagem que você adote, verifique se ela funciona com usuários reais. Configure o Real User Monitoring para rastrear se as suas alterações realmente melhoram o LCP e os Core Web Vitals gerais em campo.