Carregamento Preguiçoso

TL;DR — Lazy loading diz ao navegador para adiar o download de imagens e embeds até você estar prestes a rolar até eles, então a página carrega mais rápido no início. A maneira fácil, sem código, é adicionar loading="lazy" a um <img> ou <iframe>. A única regra a lembrar: não use lazy loading na imagem grande no topo da página — isso faz a página parecer mais lenta, não mais rápida.

O que é lazy loading

Normalmente, quando um navegador abre uma página, ele tenta baixar tudo nela — cada imagem, cada mapa ou vídeo incorporado — imediatamente. Em uma página longa com muitas imagens, isso é muito download para coisas que você pode nunca rolar para ver.

Lazy loading resolve isso. Ele adia o carregamento de imagens e embeds fora da tela até você estar prestes a rolá-los para a visualização. A página mostra o que está no topo rapidamente, e o resto carrega conforme você avança. Menos dados no início significa uma primeira impressão mais rápida, além de economia de banda e bateria — o que importa mais em celulares.

A maneira fácil: o atributo loading

Antigamente, você precisava de uma biblioteca JavaScript para fazer isso. Não mais. Navegadores modernos têm isso embutido. Você só adiciona um atributo:

<img src="photo.jpg" loading="lazy" alt="…">

É isso. Funciona em <img> e <iframe> (pense em vídeos do YouTube incorporados, Google Maps, widgets sociais) em todos os navegadores principais, sem JavaScript.

O único erro a evitar

Não use lazy loading na imagem grande no topo da página — a imagem hero, a coisa que as pessoas veem primeiro. Lazy loading diz ao navegador “isso pode esperar”, então uma imagem de topo com lazy loading carrega depois do que deveria, e a página parece mais lenta. A própria orientação do Google é pular o lazy loading para qualquer coisa que esteja visível imediatamente quando a página abre.

A versão curta: use lazy loading no conteúdo abaixo da dobra, carregue o conteúdo acima da dobra normalmente.

Isso prejudica o SEO?

Por si só, não. O Google consegue indexar imagens e conteúdo com lazy loading sem problemas quando é feito da maneira normal. O problema só começa quando uma página esconde conteúdo atrás de rolagem ou cliques — porque os mecanismos de busca não rolam nem clicam. Se suas imagens apenas usam loading="lazy", você está bem. Quer os detalhes sobre como o Google realmente vê isso e como verificar? Mude para a aba Avançado.

TL;DR — Lazy loading adia imagens e iframes fora da tela até que se aproximem do viewport, reduzindo o peso inicial da página (ajuda o LCP) e o trabalho inicial na thread principal (ajuda o INP). O atributo nativo loading="lazy" em <img>/<iframe> tem substituído a maioria das bibliotecas JS; apenas lazy e eager são valores significativos (auto está obsoleto). Os erros prejudiciais: usar lazy loading na imagem LCP/acima da dobra (atrasa exatamente a métrica que você está buscando) e esconder conteúdo atrás de rolagem/clique — o que o Googlebot nunca aciona porque ele não interage com a página. Não é um fator de ranqueamento direto; o efeito passa pelo Core Web Vitals e pela rastreabilidade. Verifique na Ferramenta de Inspeção de URLs do Search Console se os URLs das imagens estão no atributo src do HTML renderizado.

O que lazy loading realmente faz

A ideia é simples: carregue recursos apenas quando precisar deles, em vez de carregar tudo de uma vez. Em uma página com muitos recursos de mídia, baixar cada imagem e embed antecipadamente mantém o navegador ocupado buscando coisas que o visitante pode nunca rolar para ver — gastando banda, memória e bateria à toa. Adiar os que estão fora da tela permite que o conteúdo acima da dobra seja pintado mais cedo. Martin Splitt fez exatamente esse ponto no episódio “Carregamento preguiçoso desmistificado” do podcast oficial do Google: o objetivo é evitar trabalho que não traz resultado, porque imagens não críticas que a página poderia dispensar apenas mantêm o navegador ocupado.

Isso se conecta aos Core Web Vitals que a maioria das pessoas busca. Menos bytes competindo pela rede no início significa que o elemento Largest Contentful Paint pode renderizar mais cedo. Para iframes — anúncios, widgets sociais, seções de comentários, mapas — adiá-los também reduz o trabalho na thread principal durante a inicialização, o que é uma vitória para Interaction to Next Paint, não apenas para LCP. A própria orientação do web.dev do Google apresenta iframes com carregamento preguiçoso como uma melhoria de INP durante o carregamento da página.

Carregamento preguiçoso nativo vs. orientado por JavaScript

Há alguns anos, os navegadores ganharam um atributo nativo loading para imagens e iframes, então você pode entregar todo o trabalho ao navegador em vez de configurar uma API JavaScript. Em meu guia de SEO JavaScript na Ahrefs faço a mesma observação: desde que escrevi esse artigo, o carregamento preguiçoso passou em grande parte de ser orientado por JavaScript para ser tratado pelos navegadores. Você ainda encontrará configurações orientadas por JS, e para imagens elas geralmente são boas — a coisa que verifico é se o conteúdo real (não apenas imagens) está sendo carregado preguiçosamente, porque essas configurações são as que causaram problemas de conteúdo não ser capturado corretamente.

A versão nativa:

<!-- Below-the-fold image: defer it -->
<img src="gallery-07.jpg" loading="lazy" width="800" height="600" alt="…">

<!-- Off-screen embed: defer it -->
<iframe src="https://www.youtube.com/embed/…" loading="lazy" title="…"></iframe>

Sempre defina width/height explícitos (ou uma proporção de aspecto) em imagens preguiçosas para que o navegador reserve o espaço antes de a imagem carregar — esse é o maior risco de mudança de layout com imagens adiadas. Dimensões reservadas não são uma garantia absoluta de CLS, no entanto: se o layout ao redor ou um corte responsivo ainda mudar depois que a imagem carregar, você ainda pode ver uma mudança, então confirme com um rastreamento real de mudança de layout em vez de assumir que dimensões fixas sozinhas resolvem isso.

Carregamento preguiçoso e iframes precisam de mais uma distinção: loading="lazy" em um <iframe> apenas adia quando a busca e a criação do embed acontecem. Não define seu title, comportamento de foco, sandbox, allow/política de permissões, referrerpolicy, tratamento de consentimento ou dimensões para você — esses ainda precisam de atenção própria, e um embed pode continuar fazendo trabalho (scripts, pixels de rastreamento, layout) uma vez que se torna elegível para carregar. E não assuma que “abaixo da dobra” se comporta igual em todos os lugares: conteúdo com display: none, slides de carrossel fora da tela, elementos transformados e contêineres de rolagem aninhados podem intersectar o viewport de forma diferente de um elemento simples abaixo da dobra, então teste o layout real e os controles de navegação em vez de assumir equivalência.

Os valores do atributo loading

Apenas dois valores importam hoje:

• loading="lazy" — adie o recurso até que esteja perto do viewport.
• loading="eager" — carregue imediatamente, o comportamento padrão. Use-o para ser explícito sobre imagens acima da dobra.

Você pode ver loading="auto" em artigos mais antigos — está obsoleto no Chrome, então não use. Não há necessidade; omitir o atributo já lhe dá o comportamento padrão (eager).

Quão perto é “perto”? loading="lazy" é uma dica, não uma garantia controlada pelo autor — a especificação deixa a decisão real de proximidade do viewport para o navegador. O Chromium tenta buscar um recurso preguiçoso cedo o suficiente para que esteja pronto quando você rolar até ele, e a distância de acionamento varia por navegador, velocidade de conexão e tipo de recurso; não é um valor fixo em pixels que você pode confiar ou reproduzir entre navegadores ou versões. Não publique — nem confie — em um número específico de “carrega N pixels antes do viewport”; trate a janela de proximidade do viewport como definida pela implementação e confirme o comportamento real com um rastreamento de rede no navegador/conexão que você se importa, em vez de assumir uma constante.

O lazy loading nativo também funciona bem com imagens responsivas: ele se aplica à seleção normal de src e srcset/sizes, então você não perde o comportamento de imagem responsiva ao adicionar loading="lazy". Se, em vez disso, você esconder a URL real apenas em um atributo data-* para um script trocar depois, o carregamento passa a depender desse script — teste o HTML renderizado e o que acontece se o script falhar (mais sobre isso nas abas Scripts e Solução de problemas).

O erro nº 1: aplicar lazy loading ao LCP / imagem acima da dobra

Este é o erro que vejo com mais frequência, e todas as fontes concordam. Se você aplicar lazy loading à imagem hero — ou a qualquer imagem que provavelmente seja o elemento LCP — você está dizendo ao navegador para esperar pelo pixel mais importante para a velocidade de carregamento percebida. O navegador também não consegue aplicar lazy loading a uma imagem até saber onde ela ficará na página, então imagens acima da dobra com lazy loading tendem a carregar mais lentamente do que as sem lazy loading. Isso atrasa diretamente o Largest Contentful Paint, a métrica que o Google diz que deve ser resolvida nos primeiros 2,5 segundos de carregamento.

Splitt colocou o outro lado claramente no episódio do SOTR: se você não está usando lazy loading onde deveria, isso provavelmente prejudicará algum aspecto do Core Web Vitals — muito provavelmente o LCP. Então é uma faca de dois gumes. A regra:

• Candidato provável ou observado a LCP → carregue com eager (omitindo loading="lazy", ou defina eager). Considere fetchpriority="high" na imagem LCP.
• Abaixo da dobra → loading="lazy".

Nem toda imagem acima da dobra é o candidato a LCP — identifique o real (um trace de Performance ou o PageSpeed Insights vai nomeá-lo) e verifique o tempo de requisição dele em vez de tratar todas as imagens da primeira tela da mesma forma. E esses são hints separados, não uma configuração única: loading="eager" (ou omitir loading) só significa que o navegador não vai adiar a descoberta do recurso — isso não aumenta a prioridade de fetch por si só. fetchpriority é um hint distinto e consultivo por cima disso. Empilhar um <link rel="preload"> com loading="lazy" no mesmo recurso envia ao navegador intenções conflitantes, então verifique o waterfall real da rede em vez de assumir que a combinação faz o que você espera.

O anti-padrão geral é ativar o lazy loading para todas as imagens do site — um padrão comum em CMS. Como Splitt observou, se todas as imagens têm lazy loading, então imagens que estão (ou deveriam estar) imediatamente visíveis também têm, que é exatamente o caso que você quer evitar.

Como o Googlebot renderiza conteúdo com lazy loading

Aqui está a realidade do rastreamento que confunde as pessoas: o Googlebot não rola a página e não clica. Ele renderiza sua página com um navegador headless, mas não simula um usuário interagindo com ela. O Google afirma isso diretamente — seus métodos recomendados de lazy loading deliberadamente não dependem de ações do usuário como rolar ou clicar, porque o Google Search não interage com sua página.

É por isso que o como da sua implementação importa. O documento do Google lista três implementações que considera seguras: o lazy loading nativo do navegador para imagens e iframes, a API IntersectionObserver (com um polyfill) ou uma biblioteca JavaScript que carrega dados conforme eles entram no viewport. Todas as três dependem da interseção com o viewport — não de um evento de rolagem ou clique que o Googlebot nunca vai disparar.

O padrão de alto risco é uma biblioteca de lazy loading em JS personalizada ou de terceiros. Se a biblioteca se comportar mal e o URL da imagem nunca chegar ao atributo src, o Google simplesmente não vai captar essa imagem — Splitt descreveu exatamente esse modo de falha no episódio do SOTR. Não há nada para indexar se o URL não estiver lá. Isso é a mesma coisa que eu sinalizo em meu guia de SEO para JavaScript: lazy loading de imagens normalmente é tranquilo, mas conteúdo carregado com lazy loading é onde os problemas de indexação aparecem, e a solução é verificar o que o Google realmente renderiza.

Rolagem infinita é um problema diferente

Não confunda lazy loading básico de imagens/iframes com rolagem infinita ou carregamento paginado. Adiar imagens é uma coisa; carregar novos pedaços de conteúdo conforme o usuário rola é outra, e isso exige uma arquitetura própria. A orientação do Google: dê a cada pedaço um URL persistente e único, mantenha o conteúdo estável por URL (use números de página absolutos como ?page=12, não valores relativos como ?date=yesterday) e atualize o URL exibido com a History API conforme cada pedaço se torna o conteúdo visível principal para que possa ser atualizado, compartilhado e linkado. Pule isso e o conteúdo mais profundo por trás de uma rolagem infinita pode nunca ser rastreado ou indexado de forma confiável.

Como testar

O caminho de verificação é o mesmo no documento do Google e na minha própria metodologia: use a Ferramenta de Inspeção de URL do Search Console e observe o HTML renderizado. Se os URLs das suas imagens (ou vídeos) aparecerem no atributo src nos elementos <img>/<video> desse HTML renderizado, sua configuração funciona. O Google diz isso claramente — verifique o HTML renderizado para garantir que seu conteúdo está nele. A formulação exata da fonte é “check the rendered HTML to make sure your content is in it” (tradução) «verifique o HTML renderizado para garantir que seu conteúdo está nele». Se o URL estiver ausente do src, esse é o seu problema, e geralmente aponta para um gatilho de rolagem/clique ou uma biblioteca quebrada.

Para uma grade de produtos com lazy loading, vá além dessa verificação de presença. Execute a matriz de testes de SEO para rolagem infinita com viewports padrão e altas, navegação nova e redimensionamento pós-carregamento, execuções sem ação e com rolagem incremental, contagens de links de produtos únicos e inspeção da árvore de acessibilidade. Redimensionar uma página inicializada não é equivalente a navegar no tamanho final do viewport porque observadores e cálculos em lote podem ser registrados apenas durante a inicialização. Evidência desta afirmação Google Search does not scroll or click to trigger lazy-loaded content, so implementations should not depend on user interaction and should expose resource URLs in rendered HTML. Escopo: Google Search guidance for JavaScript-driven lazy loading. Confiança: alta · Verificado: 2026-07-14 Google Search Central: Lazy-load content

Você também pode contar com suas ferramentas de performance web: o PageSpeed Insights sinaliza imagens fora da tela que você deveria adiar. Em meu guia de PageSpeed Insights na Ahrefs eu observo que a auditoria “adiar elementos fora da tela” está dizendo para você aplicar lazy loading em imagens — uma forma prática de conectar o diagnóstico que você já executa à solução.

Transparência sobre sinais de ranqueamento

Seja claro sobre o que lazy loading é e não é. Usá-lo não é um fator de ranqueamento direto, e não usá-lo não é uma penalidade. A conexão com o ranqueamento é indireta: ela passa pelos Core Web Vitals (principalmente LCP, às vezes INP para iframes) e pela capacidade de rastreamento, se uma implementação ruim esconder conteúdo. Splitt caracterizou o efeito no ranqueamento através dos Core Web Vitals como um fator minúsculo e ínfimo na maioria dos casos. Então otimize o lazy loading para a experiência de carregamento dos seus usuários e para uma indexação limpa — não porque você espera um aumento de ranqueamento do atributo em si.

Onde isso se encaixa

Lazy loading é uma alavanca no conjunto mais amplo de performance web. Ele combina com resource hints (preload/preconnect para os recursos que você quer antecipadamente), estratégia de carregamento de fontes, cache e uma CDN — e é avaliado, em última análise, por meio dos Core Web Vitals. Acertar a divisão acima-da-dobra/abaixo-da-dobra e é uma das vitórias mais baratas disponíveis.

Resumo de IA

Uma visão condensada da versão Avançada:

• Lazy loading adia imagens e iframes fora da tela até que se aproximem da viewport — reduzindo o peso inicial da página e o trabalho de inicialização. A forma nativa, sem JS, é loading="lazy" em <img> e <iframe>; ela substituiu em grande parte as bibliotecas JS. É uma dica do navegador, não uma distância ou tempo garantido — o ponto de acionamento varia por navegador, conexão e tipo de recurso, então não confie em um número fixo de pixels.
• Valores: apenas lazy e eager importam. auto está obsoleto no Chrome.
• Vínculo com Core Web Vitals: menos bytes iniciais ajudam o LCP; adiar iframes reduz o trabalho na thread principal na inicialização, ajudando o INP. Defina width/height para que imagens adiadas não causem CLS — embora dimensões reservadas sozinhas não garantam zero deslocamento se o layout ao redor ainda mudar.
• Erro nº 1: aplicar lazy loading na imagem provável/observada de LCP, não apenas em qualquer imagem acima da dobra. Isso atrasa a Largest Contentful Paint, que o Google diz que deve ser resolvida em 2,5s. eager/omitir loading afeta apenas a descoberta — não aumenta por si só a prioridade de busca; fetchpriority é uma dica separada, e combinar preload com loading="lazy" no mesmo recurso gera conflito. Lazy loading em todo o site é o anti-padrão comum em CMS.
• Iframes têm seu próprio contrato: loading="lazy" apenas adia o fetch/criação — título, sandbox, política de permissões, política de referrer, consentimento e dimensões ainda precisam ser definidos independentemente, e layouts ocultos/carrossel/transformados podem intersectar a viewport de forma diferente de um elemento simples abaixo da dobra.
• Googlebot não rola nem clica. Qualquer conteúdo atrás de eventos de rolagem/clique pode ficar invisível. Os métodos seguros do Google — lazy loading nativo, IntersectionObserver ou uma biblioteca JS bem comportada — todos dependem da interseção com a viewport.
• Maior risco: bibliotecas de lazy loading JS personalizadas/de terceiros. Se a URL nunca chegar ao src, o Google não indexará a imagem (segundo Martin Splitt).
• Scroll infinito é diferente: precisa de URLs paginadas únicas + History API.
• Verifique no URL Inspection do Search Console → HTML renderizado → URLs de imagem presentes no atributo src.
• Não é um fator de ranqueamento direto. O efeito é indireto, via Core Web Vitals e rastreabilidade, e Splitt chamou o efeito de ranqueamento do Core Web Vitals de pequeno.

Documentação oficial

Orientação de fonte primária dos mecanismos de busca e do web.dev do Google.

Google — Search Central

• Corrigir conteúdo com lazy loading — o documento definitivo: métodos de implementação seguros, a regra “o Google não interage com sua página”, requisitos de scroll infinito/carregamento paginado e como verificar no HTML renderizado.
• Entenda os fundamentos de SEO em JavaScript — recomenda lazy loading de imagens como uma prática recomendada de largura de banda/desempenho e linka para o guia dedicado.
• Core Web Vitals — por que aplicar lazy loading no elemento de LCP é contraproducente (a meta de LCP é 2,5s).

Google — web.dev (Aprenda Performance)

• Carregue imagens e elementos <iframe> com lazy loading — quando adiar e o benefício de INP de iframes com lazy loading.
• Lazy loading de imagens em nível de navegador para a web — o atributo nativo e por que não aplicar lazy loading em imagens na viewport/LCP.
• Está na hora de aplicar lazy loading em iframes fora da tela! — o caso específico de iframes (anúncios, widgets, mapas).
• Lazy loading em nível de navegador para CMSs — orientação para plataformas CMS.

Google — episódio de podcast oficial

• Podcast oficial — episódio 98, “Carregamento preguiçoso desmistificado” (21 de ago. de 2025) — John Mueller e Martin Splitt sobre lazy loading, renderização, indexação e Core Web Vitals. Também indexado na página do podcast do Google.

Referência para desenvolvedores (não específica de SEO, mas autoritativa sobre a API)

• MDN — Lazy loading (guia de desempenho)
• MDN — HTMLImageElement: propriedade loading
• caniuse — Lazy loading via atributo para imagens e iframes

Bing / Microsoft

• O Bing não publica um documento dedicado sobre lazy loading. Suas diretrizes gerais para webmasters cobrem rastreamento e renderização de JS de forma ampla. O Bingbot renderiza com um navegador headless baseado em Chromium e, como o Googlebot, não rola nem clica — portanto, a mesma abordagem nativa de loading="lazy" / IntersectionObserver que satisfaz o Google deve satisfazer o Bing. Esse último ponto é uma inferência do comportamento geral de renderização do Bingbot, não uma declaração do Bing sobre lazy loading — trate-o como tal.

Citações da fonte

Declarações oficiais da documentação do Google. Cada link é um link profundo que salta para a passagem citada na página de origem.

Google — Search Central, “Fix Lazy-Loaded Website Content”

• “Deferring loading of non-critical or non-visible content, also commonly known as ‘lazy-loading’, is a common performance and UX best practice.” (tradução) «Adiar o carregamento de conteúdo não crítico ou não visível, também conhecido como ‘lazy-loading’, é uma prática recomendada comum de desempenho e UX.» Ir para a citação
• “However, if not implemented correctly, this technique can inadvertently hide content from Google. This document explains how to make sure Google can crawl and index lazy-loaded content.” (tradução) «No entanto, se não for implementada corretamente, essa técnica pode ocultar conteúdo do Google inadvertidamente. Este documento explica como garantir que o Google possa rastrear e indexar conteúdo carregado de forma preguiçosa.» Ir para a citação
• “The methods mentioned don’t rely on user actions, such as scrolling or clicking, to load content, which is important as Google Search does not interact with your page.” (tradução) «Os métodos mencionados não dependem de ações do usuário, como rolar ou clicar, para carregar conteúdo, o que é importante, pois o Google Search não interage com sua página.» Ir para a citação
• “Don’t add lazy-loading to content that is likely to be immediately visible when a user opens a page. That might cause content to take longer to load and show up in the browser, which will be very noticeable to the user.” (tradução) «Não adicione lazy-loading a conteúdo que provavelmente ficará imediatamente visível quando o usuário abrir uma página. Isso pode fazer com que o conteúdo demore mais para carregar e aparecer no navegador, o que será muito perceptível para o usuário.» Ir para a citação
• “Give each chunk its own persistent, unique URL.” — sobre rolagem infinita / carregamento paginado. (tradução) «Dê a cada bloco seu próprio URL persistente e exclusivo.» Ir para a citação

Lista de verificação de lazy-loading

Execute isto antes de enviar uma alteração de lazy-loading:

• A imagem hero / LCP NÃO é carregada com lazy loading — ela carrega de forma eager (omitir loading="lazy"), idealmente com fetchpriority="high".
• loading="lazy" é aplicado a imagens e iframes que estão abaixo da dobra.
• Imagens com lazy loading têm width/height (ou aspect-ratio) explícitos para não causar mudança de layout (CLS) quando carregarem.
• Nenhum conteúdo é bloqueado por um evento de scroll ou clique — o Googlebot não dispara esses eventos. Use lazy loading nativo ou IntersectionObserver.
• Você não está usando o valor obsoleto loading="auto" — apenas lazy/eager.
• Iframes fora da tela (embeds, anúncios, mapas, widgets) usam loading="lazy" para reduzir o trabalho inicial na thread principal.
• Iframes com lazy loading ainda têm seus próprios title, sandbox, allow/política de permissões, referrerpolicy e dimensões explícitas — loading="lazy" apenas adia o momento do fetch, não esses atributos.
• Verificado no Inspeção de URL do Search Console → HTML renderizado que as URLs de imagem/vídeo aparecem no atributo src.
• Se estiver usando uma biblioteca JS de lazy loading de terceiros, confirmado que o src ainda é preenchido no HTML renderizado.
• Para scroll infinito, cada bloco tem uma URL paginada única, persistente e a API History atualiza a URL exibida.
• Os avisos de “adiar imagens fora da tela” do PageSpeed Insights são resolvidos.

Anti-padrões de lazy loading (mitos e erros)

Cada um destes é uma crença ou hábito comum, por que está errado e o que fazer em vez disso.

“Lazy loading é sempre bom, então aplique a todas as imagens.” Por que está errado: lazy loading em todo o site pega também a imagem hero/LCP, o que atrasa a Largest Contentful Paint — o oposto da melhoria de velocidade que você queria. Em vez disso: faça lazy loading apenas abaixo da dobra; carregue imagens acima da dobra de forma eager.

“O Google não indexa conteúdo com lazy loading de forma alguma.” Por que está errado: o Google rastreia e indexa conteúdo com lazy loading corretamente quando feito com lazy loading nativo, IntersectionObserver ou uma biblioteca bem comportada. O risco é específico para configurações bloqueadas por scroll/clique ou quebradas — segundo as próprias palavras do Google, o problema é quando está “not implemented correctly.” (tradução) «não implementado corretamente». Em vez disso: use um método de interseção com a viewport e verifique no HTML renderizado.

“loading='auto' é um bom padrão.” Por que está errado: auto está obsoleto no Chrome; recomendá-lo é um conselho desatualizado. Em vez disso: use lazy para recursos fora da tela, eager (ou nada) para o resto.

“Lazy loading e scroll infinito são a mesma correção.” Por que está errado: são distintos. Scroll infinito adicionalmente precisa de URLs paginadas únicas e atualizações da API History, ou o conteúdo mais profundo pode nunca ser rastreado de forma confiável. Em vez disso: trate o carregamento paginado/infinito como uma arquitetura própria com URLs por bloco.

“loading='lazy' funciona em qualquer elemento.” Por que está errado: é especificado para <img> e <iframe>. Suporte para outros elementos não faz parte da especificação principal da mesma forma. Em vez disso: use o atributo em imagens e iframes; lide com outras mídias com uma técnica apropriada (para vídeo, uma imagem de poster que carrega o vídeo ao entrar na viewport).

“Lazy loading prejudica o SEO.” Por que está errado: lazy loading em si não é uma penalidade. O efeito relevante para ranqueamento passa pelos Core Web Vitals e é pequeno; a má implementação é o que prejudica, não a técnica. Em vez disso: implemente corretamente, exclua a imagem LCP e verifique o que é renderizado.

Folha de referência de lazy loading

O atributo loading

Quais elementos suportam

• <img> — sim
• <iframe> — sim
• Outros elementos (vídeo/áudio) — não fazem parte da especificação principal da mesma forma; use um padrão de imagem de poster + carregar ao visualizar para vídeo.

Acima vs. abaixo da dobra

• Acima da dobra / provável LCP → eager (nunca lazy). Adicione fetchpriority="high" à imagem LCP.
• Abaixo da dobra → lazy.

Impacto nos Core Web Vitals

• Adiar imagens fora da tela → ajuda o LCP (menos bytes competem no início).
• Adiar iframes fora da tela → ajuda o INP (menos trabalho na thread principal na inicialização).
• Falta de width/height em imagens lazy → pode prejudicar o CLS (mudança de layout ao carregar).

Regras que o Googlebot considera

• O Googlebot não rola nem clica — nada de conteúdo bloqueado por rolagem ou clique.
• Métodos seguros: loading="lazy" nativo, IntersectionObserver, biblioteca JS bem comportada.
• Verifique: URL Inspection → HTML renderizado → URL da imagem no atributo src.
• Scroll infinito ≠ lazy loading de imagens — precisa de URLs paginadas únicas + History API.

Antes / depois

Correções concretas, apresentadas como você as encontraria em uma auditoria.

1. A imagem hero está com lazy loading (LCP atrasado)

Antes:

<img src="hero.jpg" loading="lazy" alt="Product hero">

Depois:

<img src="hero.jpg" fetchpriority="high" alt="Product hero">

Por quê: o hero é o elemento LCP. Carregá-lo com eager (e priorizar a busca) faz com que ele seja renderizado mais cedo. Lazy loading faz o oposto.

2. Lazy loading generalizado no site inteiro por padrão do CMS

Antes: cada <img> no template carrega loading="lazy", incluindo o logotipo do cabeçalho e a imagem em destaque no topo da página. Depois: o template carrega imagens acima da dobra com eager e só aplica loading="lazy" a imagens renderizadas abaixo da viewport inicial. Por quê: lazy loading generalizado atinge as imagens visíveis imediatamente, atrasando o que o usuário (e o LCP) vê primeiro.

3. Carregamento de embeds fora da tela ao carregar a página

Antes:

<iframe src="https://maps.google.com/…" title="Store map"></iframe>

Depois:

<iframe src="https://maps.google.com/…" loading="lazy" title="Store map"></iframe>

Por quê: o mapa está abaixo da dobra. Adiá-lo remove o custo de inicialização e ajuda o INP, já que embeds fazem trabalho na thread principal enquanto a página carrega.

4. Lazy load via JS customizado deixa src vazio para o Googlebot

Antes: uma biblioteca armazena a URL real em data-src e a troca para src em um evento de rolagem — que o Googlebot nunca dispara, então o HTML renderizado mostra um src vazio/placeholder. Depois: use loading="lazy" nativo (URL real em src desde o início), ou uma biblioteca baseada em IntersectionObserver, e confirme no URL Inspection que a URL está presente no src renderizado. Por quê: se a URL não estiver no src no HTML renderizado, o Google não consegue captar a imagem.

Encontre imagens que devem (ou não) ter lazy loading

Um snippet de Console DevTools que você pode colar em qualquer página para auditar o atributo loading. Ele lista imagens com o valor de loading e se elas estão atualmente na viewport — para você identificar uma imagem acima da dobra marcada como lazy, ou uma abaixo da dobra que não está.

Chrome DevTools Console

// Audit loading attributes vs. viewport position
[...document.images].forEach(img => {
  const r = img.getBoundingClientRect();
  const inView = r.top < innerHeight && r.bottom > 0;
  const loading = img.getAttribute('loading') || '(none/eager)';
  // Flag the two mistakes: in-view + lazy, or off-view + not lazy
  const flag =
    (inView && loading === 'lazy') ? '⚠ above-the-fold but LAZY' :
    (!inView && loading !== 'lazy') ? '· off-screen, not lazy' : '';
  console.log(loading.padEnd(14), inView ? 'in-view ' : 'off-view', flag, img.currentSrc || img.src);
});

Grep no seu código em busca de padrões de lazy load arriscados

Verifique seus templates/saída de build para o valor obsoleto auto e para lazy loading via JS no estilo data-src (que pode deixar src vazio para o Googlebot).

macOS / Linux (bash)

# Deprecated loading="auto"
grep -rn 'loading="auto"' ./src

# JS-driven lazy load leaving real URL in data-src (verify these render into src)
grep -rn 'data-src=' ./src

Windows (PowerShell)

# Deprecated loading="auto"
Get-ChildItem -Recurse .\src | Select-String -Pattern 'loading="auto"'

# JS-driven lazy load using data-src
Get-ChildItem -Recurse .\src | Select-String -Pattern 'data-src='

Lembre-se: data-src não é automaticamente um problema — é um lembrete para confirmar que a URL real acaba no src renderizado, o que você verifica no URL Inspection do Search Console.

Imagem hero começa mais tarde após ativar lazy loading

Sintoma: o LCP fica mais lento e a requisição do hero começa tarde no waterfall.

Causa provável: uma regra global do CMS adicionou loading="lazy" a uma imagem acima da dobra ou LCP.

Correção e confirmação: Remova o atributo lazy dessa imagem, adicione opcionalmente fetchpriority="high" e confirme que a solicitação começa mais cedo em um trace correspondente.

Imagem lazy aparece, mas desloca a página

Sintoma: O conteúdo pula quando uma imagem adiada entra no viewport.

Causa provável: A imagem não tem dimensões explícitas ou proporção de aspecto reservada.

Correção e confirmação: Adicione os atributos width e height ou reserve a mesma proporção de aspecto no CSS. Recarregue com as regiões de mudança de layout habilitadas e verifique se a imagem não move mais o conteúdo ao redor.

O Google não vê conteúdo adiado

Sintoma: Uma inspeção renderizada está faltando a URL da imagem ou o conteúdo que aparece após um scroll humano.

Causa provável: Um manipulador de scroll/clique nunca é executado para o Googlebot, ou uma biblioteca de lazy-load deixa a URL real em data-src em vez do src renderizado.

Correção e confirmação: Use lazy loading nativo ou uma implementação baseada em IntersectionObserver, depois inspecione o HTML renderizado e confirme que a URL final e o conteúdo estão presentes sem interação.

Embed fora da tela ainda carrega imediatamente

Sintoma: Um iframe abaixo da dobra aparece no waterfall inicial apesar de uma mudança de lazy-loading.

Causa provável: O atributo está ausente no iframe implantado, um wrapper cria o iframe ansiosamente, ou o embed está próximo o suficiente do viewport para o limite de carregamento do navegador.

Correção e confirmação: Inspecione o DOM ao vivo e o iniciador da solicitação, teste em uma página longa com cache frio e verifique se a solicitação é adiada até o limite próximo ao viewport do navegador.

Ferramentas para implementação e prova

• Painéis Elements e Network do Chrome DevTools: confirme o atributo loading implantado, identifique qual script criou um iframe e compare os tempos de início da solicitação antes e depois de uma mudança.
• Painel Performance do Chrome DevTools: grave um carregamento e verifique se adiar um embed reduz o trabalho da thread principal na inicialização sem atrasar a imagem LCP.
• PageSpeed Insights: use o diagnóstico de imagem fora da tela como lista inicial e depois separe os candidatos verdadeiros abaixo da dobra do hero ou de outro conteúdo imediato.
• Inspeção de URL do Search Console: inspecione o HTML renderizado e verifique se as URLs de imagem adiadas acabam em src e se o conteúdo lazy-loaded existe sem scroll ou clique.
• O viewport do navegador e o filmstrip: teste mais de um tamanho de viewport. Uma imagem abaixo da dobra no desktop pode estar acima da dobra em um dispositivo menor ou com formato diferente.

Adiamento de imagem abaixo da dobra

Teste a executar: Grave um trace de Network com cache frio antes e depois de adicionar lazy loading nativo a uma imagem bem abaixo do viewport inicial.

Resultado esperado: A solicitação da imagem está ausente do waterfall crítico inicial e começa conforme o viewport se aproxima dela.

Interpretação de falha: O markup implantado não tem o atributo, o JavaScript cria ou busca a imagem ansiosamente, ou a imagem de teste está dentro do limite próximo ao viewport do navegador.

Janela de monitoramento: Verifique imediatamente após a implantação em tamanhos de viewport móvel e desktop representativos.

Gatilho de rollback: Reverta se uma imagem visível no carregamento inicial for adiada ou se a imagem falhar rotineiramente em aparecer antes que o usuário a alcance.

Exclusão da imagem LCP

Teste a executar: Compare traces de performance correspondentes e waterfalls de solicitação para a imagem LCP da página após remover o lazy loading genérico.

Resultado esperado: A imagem LCP carrega ansiosamente, sua solicitação começa mais cedo e o LCP não regride.

Interpretação de falha: Outro template ou camada de otimização re-adiciona o atributo, ou a descoberta ainda é atrasada por CSS, JavaScript ou markup.

Janela de monitoramento: Verifique execuções de laboratório repetidas imediatamente e depois observe o LCP de campo na janela de relatório seguinte.

Gatilho de rollback: Reverta o rollout ao redor se a mudança atrasar outros recursos críticos o suficiente para causar uma regressão de LCP repetível.

Visibilidade do conteúdo renderizado

Teste a executar: Use a Inspeção de URLs para visualizar o HTML renderizado sem interagir com a página e procure pela URL da imagem adiada e pelo conteúdo associado.

Resultado esperado: A URL final aparece em src, e o conteúdo importante está presente no HTML renderizado.

Interpretação de falha: A implementação depende de um evento de rolagem/clique ou o script de carregamento lento falhou durante a renderização.

Janela de monitoramento: Teste cada modelo afetado após o lançamento e após alterar a biblioteca de carregamento lento ou o pipeline de imagens do CMS.

Gatilho de reversão: Reverta se o conteúdo indexável ou as URLs de imagem desaparecerem da saída renderizada.

Teste-se: Carregamento lento

Cinco perguntas rápidas sobre adiar imagens e iframes sem prejudicar o Core Web Vitals ou a indexação. Escolha uma resposta para cada uma e depois confira.

Recursos que valem seu tempo

Meus escritos relacionados

• Problemas e práticas recomendadas de JavaScript SEO — onde abordo a mudança do carregamento lento orientado por JS para o nativo do navegador e por que o conteúdo com carregamento lento (não apenas imagens) é o risco de indexação.
• Google PageSpeed Insights para SEOs e desenvolvedores — conecta a auditoria “adiar imagens fora da tela” ao carregamento lento, além do restante do relatório do PSI.
• O guia do iniciante para SEO técnico — onde desempenho e renderização se encaixam no panorama geral.

Da indústria

• Corrigir conteúdo de site com carregamento lento (Google Search Central) — o documento definitivo de implementação e teste.
• Carregamento lento de imagens em nível de navegador para a web (web.dev) — o atributo nativo e a ressalva do LCP, direto da equipe de desempenho do Google.
• Está na hora de carregar iframes fora da tela lentamente! (web.dev) — o caso do iframe e seu benefício de inicialização/INP.
• Carregamento preguiçoso desmistificado — podcast oficial do Google, episódio 98 (Google) — o episódio completo de Mueller e Splitt sobre carregamento lento, renderização, indexação e Core Web Vitals.
• Carregamento lento explicado: Acelere seu site e UX rapidamente (Search Engine Land) — um guia completo da indústria com notas específicas para CMS.
• Carregamento lento (Guia de desempenho) (MDN) — a visão de referência do desenvolvedor sobre a API.
• Uma introdução ao carregamento lento para sucesso de rastreabilidade e indexação (Oncrawl) — o ângulo de rastreamento/indexação em profundidade.

Registro de alterações