Lazy loading de ads foi implementado para melhorar a viewability. Na maioria das operações que já o têm configurado, está fazendo exatamente o oposto. O problema não é a técnica. É a configuração.
O threshold errado, a posição errada, o mesmo parâmetro aplicado para mobile e desktop. Cada um desses erros gera impressões que aparecem como válidas nos relatórios mas nunca foram efetivamente vistas pelo usuário. O inventário fica contaminado, o eCPM cai progressivamente e o publisher não entende por quê, porque os números de fill rate e impressões continuam normais.
Lazy loading de ads mal configurado é uma das causas mais silenciosas de queda de viewability em operações que já têm uma infraestrutura técnica funcionando. Este post mostra onde estão os erros mais comuns e como calibrar a configuração corretamente por posição, formato e dispositivo.
Por que o lazy loading de ads mal configurado é uma das maiores causas de viewability baixa?
O lazy loading adia a requisição do anúncio até que o slot se aproxime do viewport do usuário. A lógica é correta: em vez de carregar todos os anúncios da página imediatamente, inclusive os que estão muito abaixo e que o usuário pode nunca chegar a ver, o sistema espera o usuário se aproximar antes de disparar a requisição.
O problema está no “se aproximar”. Esse threshold, a distância em pixels entre o slot e o viewport no momento em que a requisição é disparada, é o parâmetro que define se o lazy loading vai melhorar ou destruir a viewability da operação.
Quando o threshold é muito tardio, próximo demais do viewport, o anúncio não tem tempo suficiente para completar o processo de requisição, leilão e renderização antes de o usuário já estar vendo aquela posição. A impressão é contabilizada, mas o criativo ainda está carregando. O resultado é uma impressão tecnicamente válida que na prática nunca foi vista.
Quando o threshold é muito antecipado em posições above the fold, o comportamento é diferente mas igualmente problemático. O anúncio dispara a requisição cedo demais para uma posição que o usuário já estava vendo desde o momento em que a página carregou. O tempo entre a requisição e a renderização reduz o período em que o anúncio fica efetivamente visível, penalizando a viewability da posição mais valiosa do inventário.
A diferença entre impressão contabilizada e impressão vista
Uma impressão é contabilizada quando o criativo termina de carregar e o evento onLoad é registrado pelo ad server. Uma impressão é considerada viewable pelo padrão do IAB quando pelo menos 50% dos pixels do anúncio ficam visíveis na tela por no mínimo um segundo contínuo.
Lazy loading de ads mal configurado cria um gap entre esses dois eventos. O anúncio carrega, a impressão é contabilizada, mas o usuário já rolou a página para além daquele ponto antes do segundo de exposição ser atingido. O GAM registra a impressão como entregue. Os compradores registram como não viewable. O eCPM daquele inventário cai a cada leilão.
Viewability baixa derruba o eCPM leilão a leilão, mas floor prices mal calibrados aceleram esse processo ao aceitar lances abaixo do valor real do inventário. Se você quer proteger a receita nas duas frentes, vale conferir:
Quais posições devem e quais não devem ter lazy loading de ads
A regra fundamental, documentada pelo próprio Google nas práticas recomendadas de viewability do Ad Manager, é clara: posições above the fold nunca devem ter lazy loading.
Essas posições precisam carregar imediatamente porque o usuário já está visualizando aquela área no momento em que a página abre. Aplicar lazy loading em um banner above the fold atrasa o carregamento do anúncio mais valioso do inventário sem nenhum benefício de performance, já que aquela área já está no viewport. O resultado é queda direta de viewability na posição com maior potencial de CPM da operação.
Posições below the fold são onde o lazy loading de anúncios faz sentido. O usuário precisa rolar a página para chegar até elas, e o tempo de rolagem é justamente a janela que o lazy loading usa para disparar a requisição e completar o carregamento antes da posição entrar no viewport.
Sticky ads e formatos que acompanham o scroll têm lógica própria. Por ficarem fixos na tela enquanto o usuário navega, a viewability já é naturalmente alta. Aplicar lazy loading nesses formatos pode atrasar o carregamento inicial sem benefício real, especialmente em conexões mais lentas.
Lazy loading de anúncios bem configurado reduz a latência da página e melhora os Core Web Vitals, mas a relação entre performance e receita é mais complexa do que parece. Confira:
O erro de aplicar a mesma configuração para mobile e desktop
Mobile e desktop têm comportamentos de scroll completamente diferentes. Usuários mobile rolam a página mais rápido do que usuários desktop, o que significa que o threshold de lazy loading de ads precisa ser maior em mobile para compensar essa diferença de velocidade.
Uma configuração de 200px acima do viewport pode funcionar bem em desktop, onde o usuário rola devagar e o anúncio tem tempo de carregar antes de ser visto. O mesmo threshold em mobile frequentemente resulta em anúncios que começam a carregar tarde demais, gerando impressões não viewable exatamente no dispositivo que responde pela maior parte do tráfego na maioria das operações brasileiras.
O Google Publisher Tag permite configurar thresholds separados para mobile e desktop via os parâmetros fetchMarginPercent e renderMarginPercent, e essa diferenciação é uma das otimizações mais impactantes que uma operação pode fazer na configuração de lazy loading.
Como configurar os thresholds corretos por formato e dispositivo
O GPT lazy loading tem dois parâmetros principais. O fetchMarginPercent define quando a requisição de anúncio é disparada, em percentual da altura do viewport acima do slot. O renderMarginPercent define quando o criativo começa a ser renderizado na tela, que pode acontecer em um momento diferente do fetch.
Para posições below the fold em desktop, o intervalo recomendado para fetchMarginPercent fica entre 200px e 500px acima do viewport. Esse buffer dá ao sistema tempo suficiente para completar a requisição, o leilão e o início do carregamento do criativo antes de o usuário chegar àquela posição. Threshold abaixo de 200px começa a gerar risco de renderização incompleta em conexões mais lentas.
Para mobile, o threshold precisa ser significativamente maior. O intervalo recomendado fica entre 400px e 600px acima do viewport, para compensar a velocidade de scroll mais alta. Em páginas com muito conteúdo entre os ad slots, como artigos longos com vários parágrafos entre cada posição de anúncio, o threshold pode precisar ser ainda mais antecipado.
Formatos de vídeo outstream têm janela de resposta mais longa porque o processo de carregamento do player precede o do criativo. Para esses formatos, o threshold deve ser ainda mais antecipado, com valores entre 500px e 800px dependendo do peso do player utilizado.
Quer identificar quais posições da sua operação estão com viewability abaixo do esperado após a implementação de lazy loading? A Planilha de Análise de Anunciantes da AdSeleto permite visualizar o comportamento do inventário por posição, formato e dispositivo com o nível de detalhe necessário para esse diagnóstico.
Como medir se o lazy loading de ads está ajudando ou destruindo sua viewability
O diagnóstico começa no Google Ad Manager. O relatório de viewability por ad unit, cruzado com os dados de impressões por posição, revela com precisão os slots que estão sendo prejudicados pela configuração atual.
Posições below the fold com viewability abaixo de 50% após a implementação de lazy loading indicam threshold muito tardio. O anúncio está carregando tarde demais em relação ao momento em que o usuário passa por aquela área. A correção é aumentar o fetchMarginPercent para antecipar a requisição.
Posições above the fold com viewability caindo após a implementação indicam que lazy loading foi aplicado onde não deveria estar. A solução é remover o lazy loading dessas posições e garantir que elas carreguem imediatamente com a página.
No Google Analytics 4, uma verificação complementar importante é o tempo médio de engajamento por página após a implementação. Se o tempo de engajamento caiu, pode indicar que o lazy loading está causando atrasos visíveis no carregamento de anúncios que interferem na experiência de leitura. Usuários que percebem lentidão no carregamento tendem a sair mais cedo, o que reduz tanto a session depth quanto a viewability das posições mais baixas da página.
O A/B test é a forma mais precisa de medir o impacto real. Comparar a viewability média, o eCPM e o RPM de sessão entre versões com diferentes configurações de threshold permite identificar o ponto ótimo de cada posição sem depender de benchmarks genéricos.
FAQ
Lazy loading é obrigatório para todos os publishers?
Não é obrigatório, mas é recomendado para operações com páginas longas e múltiplas posições de anúncio below the fold. Para sites com páginas curtas onde todos os anúncios ficam próximos do viewport, o benefício de lazy loading é menor e o risco de configuração incorreta pode superar o ganho. A decisão deve ser baseada na análise da viewability atual por posição, não em uma regra universal.
Lazy loading afeta o header bidding?
Sim, diretamente. No header bidding client-side, a requisição para os SSPs é disparada no mesmo momento em que o fetch do anúncio acontece. Isso significa que o threshold de lazy loading também define quando os parceiros de demanda recebem a requisição. Um threshold muito antecipado aumenta o tempo entre a requisição e a renderização, o que pode fazer com que alguns bids expirem antes de o anúncio ser exibido. O parâmetro renderMarginPercent do GPT permite separar o momento do fetch do momento da renderização, o que ajuda a equilibrar a participação dos parceiros de demanda com a viewability.
O impacto do lazy loading no header bidding vai além do threshold: envolve como os parceiros de demanda recebem e respondem às requisições dentro da janela de tempo disponível. Quer entender o funcionamento completo do header bidding antes de ajustar esses parâmetros? Confira:
Por que minha viewability caiu depois de implementar lazy loading?
As causas mais comuns são threshold muito tardio para o comportamento de scroll dos usuários, lazy loading aplicado em posições above the fold, ou o mesmo threshold usado para mobile e desktop sem ajuste para a velocidade de scroll do mobile. O diagnóstico começa pelo relatório de viewability por posição no GAM: identificar qual posição específica caiu e em qual dispositivo é o ponto de partida para corrigir o parâmetro correto.
Lazy loading de ads e ad refresh podem ser usados juntos?
Sim, e a combinação é recomendada quando configurada corretamente. O lazy loading garante que o anúncio só carrega quando o usuário está próximo da posição. O ad refresh garante que o anúncio seja atualizado enquanto o usuário permanece naquela área. O detalhe importante é que o refresh deve ser ativado apenas quando o slot está efetivamente no viewport, não por tempo fixo. Isso evita que impressões sejam geradas para um anúncio que o usuário não está mais vendo, o que destruiria a viewability conquistada pelo lazy loading.
Quer estruturar a operação de monetização com as melhores práticas desde o setup inicial até configurações avançadas como lazy loading e ad refresh? O nosso guia em parceria com a MGID cobre essas decisões de forma estruturada.
Conclusão
Lazy loading de ads é uma das configurações de maior impacto na viewability de uma operação, para o bem ou para o mal. Implementado corretamente, melhora a viewability, reduz a latência da página e aumenta o eCPM ao entregar impressões de qualidade para os compradores. Já quando implementado incorretamente, gera impressões invisíveis que contaminam o histórico do inventário e reduzem o valor dos lances de forma progressiva e silenciosa.
A configuração correta começa pela regra fundamental: nunca aplicar lazy loading de ads em posições above the fold. E continua pelo ajuste de threshold por posição, formato e dispositivo, com verificação dos resultados no GAM antes de escalar para toda a operação.
