Lazy loading de anúncios: melhore os Core Web Vitals sem perder receita

Por Ataíde Penteado · Atualizado em 4 de novembro de 2026

O lazy loading de anúncios deve adiar a requisição e a renderização das posições menos prioritárias até que elas se aproximem da área visível, com margem para carregar antes de o usuário chegar. Bem implementado, ele reduz o processamento inicial e ajuda a preservar os Core Web Vitals. Sem critério, porém, deixa espaços em branco, reduz a competitividade dos leilões e derruba o RPM por posição.

Pontos principais

O lazy loading funciona melhor quando você ajusta a configuração pela prioridade de cada posição, em vez de aplicar uma regra única a todos os espaços publicitários.
O equilíbrio está no momento do carregamento: cedo o suficiente para preservar a qualidade do leilão, mas tarde o suficiente para reduzir o custo de processamento inicial.
A visibilidade pode melhorar após a adoção do lazy loading mesmo com queda na qualidade da demanda ou na receita, por isso confira também a taxa de preenchimento e o RPM.
As configurações de GAM e GPT devem corresponder ao modelo da página e ao comportamento de rolagem, não apenas ao nome da unidade de anúncio.
Após a implementação, monitore a latência, as impressões não preenchidas e o comportamento de atualização por posição antes de confiar na melhora dos Core Web Vitals.

Uma forma prática de avaliar esse equilíbrio: carregar antes, exibir antes ou melhorar a pontuação

Pontos principais: não aplique lazy loading por padrão à posição monetizada do topo. Comece pelo inventário abaixo da dobra e pelas posições mais profundas da página. Separe o disparo da requisição do início da renderização. No Google Ad Manager, valide os resultados por unidade de anúncio, dispositivo e modelo de página. O RPM da página sozinho não basta. A visibilidade subiu, mas a receita caiu? Trate isso como alerta, não como vitória.

Tipo de posição do anúncio	Abordagem usual de lazy loading	Impacto nos Core Web Vitals	Risco para a visibilidade	Sensibilidade do leilão e da receita	Recomendação prática
Leaderboard no topo, posição de destaque ou primeiro espaço de display visível	Geralmente sem lazy loading ou com configuração bastante conservadora	Baixo a moderado, porque já está no caminho crítico	Alto se a renderização atrasar depois que o usuário visualizar a área do slot	Alto para a concorrência entre AdX, venda direta e header bidding	Mantenha o carregamento imediato, a menos que a unidade fique abaixo da primeira área visível em um template específico. O lazy loading serve para adiar o carregamento de recursos não críticos, não para atrasar o inventário principal, conforme explica a Aditude.
Âncora fixa ou barra lateral fixa	Conservador	Moderado se a execução dos scripts disputar recursos com o carregamento inicial da página	Médio; o comportamento fixo pode tornar o slot visível rapidamente após a ativação	Alto porque o momento do refresh e da medição de viewability costuma depender de uma entrega estável	Antecipe a busca do anúncio o suficiente para que o slot fixo esteja pronto antes de se tornar elegível para exibição. Não deixe o lazy loading entrar em conflito com suas regras de refresh.
Primeira unidade no feed	Conservador, por dispositivo e template	Moderado, especialmente em páginas de artigos com criativos e módulos de conteúdo pesados	Alto em sessões em dispositivos móveis com rolagem rápida	Alto; leilões tardios podem reduzir a densidade de lances antes que o usuário passe pelo slot	Use uma janela de busca mais próxima da exibição do que nas unidades mais abaixo no feed. É nesse ponto que as metas de desempenho e a pressão por monetização costumam entrar em conflito.
Unidade de display ou nativa no meio do artigo	Lazy loading moderado	Alto o suficiente para ajudar, porque retira tarefas não críticas do carregamento inicial	Médio; os usuários costumam chegar até essa unidade, mas não imediatamente	Média; a latência do leilão importa, mas há mais margem	Uma boa opção padrão. A AdButler descreve o lazy loading como o carregamento de recursos apenas quando necessários, o que se encaixa bem no inventário no meio da página AdButler.
Bloco abaixo dos comentários, no rodapé ou no fim da barra lateral	Adiamento agressivo	Alto, porque o bloco não deve disputar recursos com a renderização inicial	Baixa a média; o usuário pode nunca chegar ao posicionamento	Baixa a média, a menos que faça parte de um pacote com garantia de entrega	Adie ao máximo. Carregar esses blocos na abertura da página gera custo sem uma oportunidade confiável de impressão visível.
Espaços publicitários da próxima página na rolagem infinita	Agressivo, com pré-carregamento controlado	Alto em sessões longas, porque cada página adicionada pode acumular trabalho de rede e renderização	Média; requisições tardias deixam espaços publicitários em branco durante a rolagem rápida	Média; a latência das SSPs e do header bidding pode aparecer de repente	Acione o carregamento antes de o novo bloco de conteúdo entrar na área visível, não depois. A Refinery89 descreve o lazy loading como a espera até que a área visível do navegador se aproxime do recurso Refinery89.
Patrocínios, roadblocks e campanhas diretas de alta prioridade	Geralmente isentos	Variável; o custo de desempenho pode compensar pelo valor do contrato	Muito alta se a entrega tardia afetar as metas de impressões ou o share of voice	Muito alta porque o ritmo de entrega e as garantias importam mais do que ganhos marginais de pontuação	Exclua, a menos que o posicionamento esteja claramente abaixo da dobra e os termos da campanha permitam adiar a entrega. Valide no Google Ad Manager antes de colocar em produção.

Por que o lazy loading de anúncios importa para a velocidade da página e os Core Web Vitals

Use o lazy loading para retirar do carregamento inicial as chamadas de anúncios abaixo da dobra, o processamento dos bidders, os downloads de criativos e a renderização. Só não dispare todos os leilões adiados na primeira rolagem. Confira o resultado nos dados de campo: LCP, CLS e INP no percentil 75 devem melhorar ou permanecer estáveis. Ao mesmo tempo, o fill por unidade, as impressões não preenchidas e o RPM precisam ficar dentro dos limites definidos para a implementação gradual.

Cada Core Web Vital responde a uma parte dessa mudança. O LCP pode melhorar quando GPT, header bidding, chamadas aos SSPs, código de mensuração e execução dos criativos deixam de competir com o conteúdo principal por recursos no carregamento inicial. Já o CLS exige espaço reservado: o contêiner precisa ter altura fixa, min-height ou um placeholder responsivo antes de o criativo renderizar. Para o INP, o ganho pode vir da redução da sobrecarga que o processamento inicial dos anúncios impõe à thread principal.

Onde o ganho de desempenho termina

Não aprove o lazy loading só porque ele foi bem em um teste de laboratório com condições ideais. O teste sintético pode melhorar ao retirar os slots mais abaixo do carregamento inicial. Na página real, porém, o usuário ainda pode enfrentar travamentos na rolagem se vários leilões e criativos dispararem juntos. Confira o RUM em campo ou os percentis de dados como os do CrUX. Depois, cruze esses resultados com os eventos dos slots de anúncio.

Trate o lazy loading de anúncios como uma forma de ordenar o carregamento. Ele não acelera tudo automaticamente. A Ads Interactive resume o ganho de desempenho em evitar downloads antecipados de recursos ainda desnecessários. Para o publisher, há uma condição adicional: o anúncio precisa chegar antes de o usuário alcançar o slot, como explica a Ads Interactive.

Se o gatilho ficar perto demais da área visível, você terá slots em branco, menos tempo para os bidders e alterações no momento do refresh. Se ficar longe demais, a página continuará pagando boa parte do custo no carregamento inicial. Como ponto de partida para os testes, dê mais antecedência à primeira unidade abaixo da dobra. Para o inventário mais profundo em artigos, galerias ou páginas com rolagem infinita, teste uma antecedência menor.

Como o lazy loading afeta a medição de viewability

Com o lazy loading, a requisição, a renderização e a impressão visível acontecem mais próximas umas das outras. Isso muda a leitura dos relatórios de viewability. Valide o resultado por posicionamento, cruzando impressões visíveis e mensuradas com o total de impressões do ad server, o fill e a receita. Uma taxa de viewability maior ainda não comprova sucesso: confira se o denominador e o RPM continuam fazendo sentido ao consultar o Google Active View nos relatórios.

Infográfico que compara como o lazy loading altera a sequência temporal da requisição do anúncio, da renderização e do registro de viewability nos relatórios. — O lazy loading pode mudar a sequência temporal dos registros de viewability nos relatórios (requisição, renderização e impressão visível), então o dashboard pode parecer melhor mesmo sem mudança na atenção do usuário.

Pedir o anúncio mais tarde não significa que ele será visto mais tarde. Uma unidade no meio do artigo pode iniciar a busca perto da área visível, renderizar rápido e ficar visível quase em seguida. Outra, na mesma profundidade de rolagem, pode perder o usuário durante a espera. Verificações de consentimento, timeout dos bidders, peso do criativo ou fila do wrapper podem atrasar a renderização o suficiente para isso acontecer.

A mudança nos relatórios que você precisa acompanhar

A viewability medida por critérios como os do MRC pode mudar de leitura após a adoção do lazy loading. O motivo: o inventário mais abaixo que não chega a ser solicitado pode ficar fora do conjunto mensurado. Em display, o critério básico costuma verificar se uma quantidade suficiente de pixels ficou visível pelo tempo exigido. Mas confira também o denominador, pois ele pesa tanto quanto o numerador. Use as orientações do MRC sobre visibilidade ou Google Active View métricas ao lado do total de impressões e da receita.

O comportamento das atualizações pode mudar mesmo que você não mexa no código de refresh. Se uma unidade fixa carregar mais tarde, a primeira atualização elegível também poderá atrasar. E, se a regra depender da visibilidade, do tempo em área visível, da aba ativa ou da interação do usuário, o lazy loading poderá reduzir o volume de atualizações por posicionamento ou mudar o momento em que elas ocorrem.

O timing do Prebid abre outro ponto de falha. O leilão de um slot que antes acontecia no carregamento da página pode passar a ocorrer durante a rolagem. Se o timeout dos bidders, o fluxo de consentimento, a sincronização de IDs ou a renderização do criativo disputar recursos com o processamento da rolagem, a experiência poderá piorar. Isso vale mesmo quando o percentual de visibilidade melhora.

Avalie os ganhos e as perdas de cada posicionamento. A visibilidade subiu, mas o preenchimento, a densidade de lances ou o RPM da unidade caiu? Você provavelmente melhorou mais a qualidade da mensuração do que a monetização. Defina a tolerância antes do teste: por exemplo, revisar ou reverter a mudança em qualquer posicionamento cujo RPM do slot em 7 dias caia mais de 5% frente ao controle, sem melhora relevante nos Core Web Vitals.

Como configurar os limites de lazy loading no GAM e no GPT

Configure o lazy loading no Google Publisher Tag com margens separadas para busca e renderização. Depois, confira a veiculação nos relatórios do Google Ad Manager, com recortes por unidade de anúncio, dispositivo e template. Na API de lazy loading, o GPT oferece controles como fetchMarginPercent, renderMarginPercent e mobileScaling Lazy loading do Google Publisher Tag. Confira as impressões, as impressões não preenchidas e as métricas do Active View em Relatórios do Google Ad Manager.

Mapeie seus slots por template antes de alterar o GPT. Separe o inventário de topo de página, unidades fixas, primeiro posicionamento no feed, meio do conteúdo, partes mais profundas do conteúdo e posições adicionadas pela rolagem infinita. Use os templates reais das páginas, não apenas os nomes das unidades de anúncio, porque a mesma unidade pode ficar acima da dobra no desktop e abaixo da dobra no celular.
Defina uma janela de busca que dê tempo suficiente à demanda. No lazy loading do GPT, os publishers costumam definir a que distância da área visível um slot pode estar para que a solicitação de anúncio seja disparada. A janela de busca deve considerar a latência do header bidding, a concorrência do AdX, o fluxo de consentimento, os módulos de identidade e o tempo de carregamento do criativo.
Defina uma janela de renderização separada. Buscar o anúncio mais cedo e renderizá-lo mais tarde pode preservar a participação da demanda e, ao mesmo tempo, reduzir o trabalho de renderização antecipado. Se a renderização ocorrer tarde demais, o slot poderá estar tecnicamente preenchido, mas visualmente em branco quando o usuário chegar até ele.
Coordene o GPT com o Google Ad Manager e seu wrapper de header bidding. O wrapper não deve iniciar leilões tão tarde a ponto de os bidders excederem o timeout, e o GAM não deve receber solicitações em um padrão que contrarie o comportamento esperado dos itens de linha. O guia da Cool.co voltado a SSPs descreve o objetivo central como veicular anúncios quando os usuários têm maior probabilidade de vê-los, mas isso ainda exige tempo suficiente para que a cadeia de fornecimento responda Guia de SSPs da Cool.co.
Crie exceções por slot. Desative ou flexibilize o lazy loading para patrocínios, roadblocks, unidades fixas, primeiros posicionamentos no feed e qualquer unidade de anúncio com pressão de entrega de vendas diretas. Não deixe que um limite global se sobreponha ao inventário gerenciado ativamente pelas equipes de vendas ou yield.
Ajuste conforme o comportamento em cada dispositivo. Usuários de dispositivos móveis podem passar rapidamente pela primeira tela, e páginas com rolagem infinita podem gerar picos repentinos de demanda. Barras laterais no desktop têm padrões de exposição diferentes. Use limites separados quando a profundidade de rolagem e a densidade de slots forem significativamente diferentes.
Verifique o comportamento no navegador, não apenas o arquivo de configuração. Use as ferramentas de desenvolvedor, o registro de eventos do GPT e os tempos do servidor de anúncios para confirmar que a busca pelo anúncio ocorre antes de o slot entrar na área visível e que a renderização não desloca o layout. Uma configuração aparentemente correta ainda pode estar errada se outro script atrasar a execução.

Como equilibrar o lazy loading com a demanda acima da dobra

Defina margens por faixa de posicionamento, sem aplicar um limite global a todos os slots. Deixe a unidade principal acima da dobra fora dessa configuração, salvo em um teste separado.

No primeiro slot abaixo da dobra, teste uma janela de busca mais ampla, de 300% a 600% da área visível, com renderização entre 100% e 200%. Para unidades mais abaixo em artigos ou galerias, experimente janelas menores: 200% a 400% para busca e 50% a 150% para renderização.

No mobile, cuidado com o fator de escala do GPT. Uma rolagem rápida com o dedo pode atravessar vários slots antes de os leilões terminarem.

Mantenha as unidades de destaque e as primeiras unidades visíveis fora do lazy loading agressivo. Se um leaderboard no topo ou a primeira unidade in-feed estiver visível na área inicial da tela, buscas tardias podem reduzir a concorrência antes mesmo de o usuário começar a ler.
Trate unidades sticky como inventário sensível ao tempo de carregamento. Um posicionamento sticky pode se tornar visível rapidamente e estar vinculado a regras de atualização. Carregue-o com antecedência suficiente para evitar um contêiner sticky vazio ou atraso na primeira impressão.
Deixe patrocínios e campanhas de venda direta fora do lazy loading, a menos que o contrato e o comportamento do posicionamento permitam adiar o carregamento. Um roadblock que chega depois que o usuário já passou da primeira tela pode gerar pressão por compensações que nenhum ganho em Core Web Vitals justifica.
Monitore a densidade de lances em sessões com rolagem rápida. Limites restritos demais podem deixar menos tempo para SSPs e bidders responderem antes que a oportunidade de impressão desapareça, especialmente em páginas de artigos e feeds em dispositivos móveis.
Reserve espaço para cada slot com lazy loading. Problemas de CLS costumam vir de contêineres que colapsam ou se expandem quando o anúncio chega. A correção não está apenas em adiar o carregamento; está em manter um layout previsível.
Use o inventário mais abaixo na página para economizar recursos de forma mais agressiva. Unidades de rodapé, posicionamentos abaixo dos comentários e barras laterais de baixo alcance são candidatos melhores porque a página não deve gastar recursos na inicialização com impressões que talvez nunca sejam vistas.
Separe o comportamento do AdX do comportamento do wrapper na análise. Se o preenchimento do AdX parecer estável, mas a demanda de header bidding diminuir após a implementação, o limite pode estar dando tempo suficiente à demanda do Google e deixando pouco tempo para os parceiros mais lentos.

Testes e monitoramento após a implementação

O lazy loading precisa melhorar os Core Web Vitals sem comprometer a entrega ou a rentabilidade. Registre uma linha de base que cubra pelo menos um ciclo normal de tráfego. Depois, avance por template e faixa de posicionamento: mantenha um controle, comece com uma pequena parcela do tráfego e amplie a exposição até a implementação completa.

Monitore LCP no p75, CLS e INP. Por unidade de anúncio, acompanhe RPM, preenchimento e impressões não preenchidas, além do tempo de resposta dos lances, das ocorrências de slots vazios e do número de atualizações.

Leia os conflitos sem rodeios. LCP melhor com RPM menor na primeira unidade in-feed indica um limite restrito demais para aquele slot. Visibilidade maior com mais impressões não preenchidas indica mudança no denominador. Já receita estável com INP pior aponta para leilões concentrados durante a rolagem.

Registre uma linha de base por template e posicionamento antes da implementação. Colete LCP, CLS, INP, visibilidade, taxa de preenchimento, RPM, número de solicitações de anúncios, impressões não preenchidas, latência dos leilões e tempo de renderização. Médias do site inteiro são pouco granulares para essa mudança.
Implemente em etapas. Comece com um template, uma propriedade ou um grupo de unidades abaixo da dobra. Não ative uma configuração para toda a rede de uma vez em várias propriedades com layouts e comportamentos de rolagem diferentes.
Compare os dados de campo com os dados de anúncios na mesma janela de tempo. Dados de campo dos Core Web Vitals, entrega no GAM, desempenho do AdX, análises do wrapper e relatórios das SSPs não vão se alinhar perfeitamente por padrão. Use intervalos de datas consistentes e evite comparar uma linha de base de dias úteis com um teste de fim de semana.
Identifique limites restritos demais. Os sinais de alerta incluem slots vazios durante a rolagem, menor preenchimento em unidades no meio do artigo, mais impressões não preenchidas, menor participação no header bidding e impressões visíveis ocorrendo mais tarde do que o esperado.
Identifique limites amplos demais. Os sinais de alerta incluem pouca melhora no LCP, congestionamento persistente da thread principal próximo ao carregamento, tráfego de rede intenso logo no início e nenhuma redução significativa nas solicitações de posicionamentos mais abaixo na página.
Ajuste primeiro a solicitação e depois a renderização na maioria dos casos sensíveis à receita. Se a demanda não estiver tendo tempo suficiente para responder, amplie primeiro a margem de solicitação. Se o desempenho continuar fraco mas o fill estiver estável, ajuste a renderização para ocorrer mais perto da entrada na área visível ou aplique um carregamento agressivo apenas aos slots mais abaixo na página.
Monitore o comportamento na primeira rolagem. Uma página pode passar em um teste sintético e ainda apresentar travamentos quando a primeira rolagem dispara vários leilões, renderizações de criativos e chamadas de mensuração ao mesmo tempo.
Mantenha um caminho de reversão. Salve os ajustes anteriores do GPT, a configuração do wrapper e as premissas de segmentação do GAM para reverter um template rapidamente se um posicionamento premium entregar abaixo do previsto.

Checklist de lançamento

Siga esta ordem para implementar o lazy loading de anúncios: 1) mapeie o inventário por template, dispositivo, posição do slot, comportamento de refresh e compromissos de venda direta; 2) mantenha fora do teste as unidades de destaque, patrocínios, takeovers, roadblocks e posicionamentos com ritmo de entrega rigoroso, até que tenham aprovação separada; 3) ajuste as margens de lazy loading do GPT ao timing dos leilões do wrapper, para solicitar a demanda do Prebid ou da Amazon antes da renderização pelo GPT; 4) registre eventos de QA para solicitação do slot, início e término do leilão, término da renderização pelo GPT, impressão visível, slot em branco e refresh; 5) avance por categoria de posicionamento, começando pelas unidades bem abaixo da dobra; 6) reverta cada posicionamento se houver aumento de slots em branco, disparada de impressões não preenchidas ou queda de RPM além do limite acordado. Reverta também se o p75 de LCP/INP não melhorar o suficiente para justificar a perda de receita.

Identifique todos os slots que devem ficar de fora: unidade de destaque, primeiro slot visível, sticky, patrocínio, roadblock e outros inventários de venda direta com alta prioridade.
Defina comportamentos distintos de solicitação e renderização para posicionamentos no topo, no meio da página, mais abaixo na página e em rolagem infinita.
Confirme que o lazy loading do GPT não inicia os leilões de header bidding tarde demais para a competição entre AdX e SSPs.
Reserve espaço fixo para as unidades com lazy loading para que o CLS não volte a subir com o colapso dos contêineres.
Avalie LCP, CLS e INP junto com viewability, fill, RPM, latência e impressões não preenchidas.
Segmente os resultados por template, dispositivo e unidade de anúncio em vez de confiar nas médias do site inteiro.
Verifique se a viewability melhorou porque os usuários viram anúncios melhores ou porque impressões com baixa probabilidade de visualização deixaram de entrar na mensuração.
Ajuste os limites de acionamento após o lançamento com base na profundidade de rolagem e no timing de renderização, sem achismos.
Mantenha a demanda premium acima da dobra rápida, previsível e plenamente apta a competir.

Perguntas frequentes

O lazy loading de anúncios melhora os Core Web Vitals?

FAQ: O lazy loading de anúncios melhora os Core Web Vitals? Em geral, sim. Para isso, o processamento dos anúncios abaixo da dobra precisa ficar fora do carregamento inicial, e todos os contêineres devem reservar espaço antes da renderização. Essa configuração pode melhorar o LCP, reduzir o risco de CLS e aliviar a carga sobre a thread principal que afeta o INP. Mas o ganho desaparece se leilões, renderização e mensuração se acumularem durante a rolagem.

O lazy loading pode prejudicar a viewability dos anúncios?

FAQ: O lazy loading de anúncios pode prejudicar a receita? Sim. Se o acionamento vier tarde demais, o usuário poderá chegar ao slot antes de haver tempo para solicitar o anúncio, concluir o leilão e renderizar o criativo. O risco aumenta com rolagem rápida, margens curtas de acionamento e rotas de demanda em que bidders ou criativos demoram mais a responder. Ajuste primeiro o limite de acionamento daquele posicionamento, em vez de abandonar o lazy loading.

Os anúncios acima da dobra devem usar lazy loading?

FAQ: Anúncios acima da dobra devem usar lazy loading? Em geral, não no slot principal de destaque nem no slot monetizado mais próximo do topo. Esses posicionamentos precisam de tempo para concluir a solicitação de demanda, os leilões e a renderização dos criativos antes da primeira oportunidade de impressão. Comece testando margens mais restritas nas unidades abaixo da dobra. Ali, o ganho de desempenho é maior, e fica mais fácil conter o risco para a receita.

O que devo monitorar depois de ativar o lazy loading?

FAQ: Quais métricas comprovam que o lazy loading funcionou? Cruze os Core Web Vitals com os dados de entrega e rentabilidade. LCP, CLS e INP indicam se a página ficou mais leve. Para conferir se a monetização se manteve, acompanhe Active View, RPM por unidade de anúncio, taxa de preenchimento, tempo de resposta dos lances, impressões não preenchidas e contagem de atualizações. Consulte os relatórios do Google Ad Manager e o Google Active View por slot, sem se limitar aos dados do site inteiro.

O GPT é suficiente para o lazy loading ou preciso de lógica adicional?

FAQ: O lazy loading do GPT é suficiente por si só? O GPT pode cuidar das margens de busca e renderização, mas geralmente deixa regras operacionais de fora.

Você ainda precisa de lógica na página para definir limites por slot e coordenar o wrapper, além de tratar exclusões de patrocínios, rolagem infinita, regras de atualização e reversão. No QA, confira os eventos no navegador.

A ordem precisa ser a esperada: solicitação do slot, início do leilão, fim do leilão, renderização pelo GPT, impressão visível e atualização.

Como fizemos a pesquisa

Fontes consultadas para este artigo:

Ataíde Penteado