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

O que é 'defer offscreen images'?

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

• A imagem termina abaixo de 3 vezes a altura da 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 inline são ignoradas. Scripts de lazy loading frequentemente usam pequenas imagens de placeholder que ficam abaixo desse limite.
• A imagem não tem o atributo de carregamento (loading) definido.
  O Lighthouse ignora imagens que tenham 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. Fazer lazy loading de imagens fora da tela reduz a largura de banda, libera conexões de rede para recursos críticos e melhora o 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 posteriormente, 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 imagens fora da tela carregadas de forma eager?

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á faltando 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 (Background images) (estas precisam de uma abordagem diferente de 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 de template ruim.

Como as imagens fora da tela afetam os 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. O seu navegador precisará baixar mais recursos antes que a página possa ser exibida na tela. Existem 3 problemas com imagens fora da tela carregadas de forma eager:

• Mais downloads antes da renderização. O seu navegador precisará baixar imagens que o usuário ainda nem 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 Page Weight do Web Almanac 2025, a página móvel mediana carrega 15 imagens. No percentil 90, esse número salta para 52. Em páginas pesadas em imagens, o lazy loading daquelas fora da tela pode fazer uma diferença real. Em todos os sites monitorados pela CoreDash, [CD:placeholder]% das páginas que aplicam corretamente o lazy loading em imagens fora da tela passam no LCP, em comparação com [CD:placeholder]% das páginas que não o fazem.

Como corrigir 'defer offscreen images'

Para corrigir imagens fora da tela carregadas de forma eager, adicione loading="lazy" a cada imagem que estiver abaixo da dobra. 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 nativa com lazy loading"
     width="300" height="300">

Rastreie as origens das suas imagens carregadas de forma eager. 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 na página e não usam os hooks corretos que ativam 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 (Page builders) que geram HTML ruim.
   Construtores de páginas como o Elementor ou o WP Bakery frequentemente criam códigos inchados que estão longe de serem perfeitos. Não há uma correçã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 trabalho ruim 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 de template ruim.
   Mesmo quando o lazy loading está ativado, imagens hardcoded nos seus templates ainda podem não receber lazy loading. Verifique seus templates em busca de imagens fora da tela e aplique o lazy loading a elas.

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 na viewport. De acordo com o Web Almanac 2025, 16% das páginas móveis ainda aplicam lazy loading à 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 a 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 à sua imagem de LCP, leia como corrigir uma imagem de LCP carregada de forma preguiçosa (lazily loaded). Para um guia completo sobre otimização de imagens, veja otimizar imagens para Core Web Vitals.

Cheatsheet de carregamento de imagens

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

Lazy loading nativo vs scripts de lazy loading

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

Bibliotecas como lazysizes eram essenciais antes que os navegadores suportassem 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 JavaScript:

• CSS background images. O lazy loading nativo só funciona em elementos <img> e <iframe>. Para background images você precisa de IntersectionObserver ou content-visibility: auto.
• Limites de carregamento customizados. O Chrome começa a carregar imagens "lazy" aproximadamente 1250px abaixo da viewport em conexões rápidas e 2500px em conexões lentas. Você não pode customizar esta distância. Se você precisa de um controle mais rigoroso, um IntersectionObserver com uma rootMargin customizada te dá isso.

Se você realmente precisar de uma biblioteca, use o vanilla-lazyload em vez do lazysizes. Ele é ativamente mantido, usa IntersectionObserver e suporta background images.

Evite o layout shift em imagens com lazy loading

Sempre inclua os atributos width e height nas 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 o Cumulative Layout Shift (CLS). De acordo com o Web Almanac 2025, 62% das páginas móveis ainda têm pelo menos uma imagem sem dimensões.

<!-- Ruim: causa layout shift -->
<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 quando você não pode aplicar lazy loading

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

• Comprima suas imagens. Imagens menores têm menos impacto no desempenho 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 em aproximadamente 1.3 bits por pixel em comparação com 2.0 do JPEG de acordo com o capítulo Media do Web Almanac 2024.
• Divida páginas grandes em múltiplas páginas. Dividir páginas grandes reduz o número de imagens que precisam carregar de uma só vez.
• Implemente o infinite scroll. Infinite scroll é basicamente um lazy loading, só que não para imagens e sim para partes inteiras da página web. Para páginas com muitos elementos repetidos (pense no Pinterest), o infinite scroll pode acelerar consideravelmente o carregamento inicial.

Para considerações específicas para mobile, imagens fora da tela são um problema ainda maior porque as conexões móveis são mais lentas e as 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 Real User Monitoring para acompanhar se suas alterações realmente melhoram o LCP e os Core Web Vitals em geral no campo (in the field).