analytics: observeAll re-observa elementos já disparados a cada mutação do DOM — loop infinito de eventos view

[viniciusventura29]

Versão: presente em @decocms/blocks@7.51.0 e idêntico em 7.55.0 (mais recente).
Arquivo: src/sdk/analytics.ts, dentro de ANALYTICS_SCRIPT.

O bug

var viewObserver = new IntersectionObserver(function(entries) {
  entries.forEach(function(entry) {
    if (entry.isIntersecting) {
      var event = getEvent(entry.target);
      if (event) dispatch(event);
      viewObserver.unobserve(entry.target);   // desobserva...
    }
  });
}, { threshold: 0.5 });

function observeAll() {
  document.querySelectorAll("[data-event-trigger='view']").forEach(function(el) {
    viewObserver.observe(el);                  // ...mas re-observa tudo de novo
  });
}
observeAll();
var mo = new MutationObserver(observeAll);
mo.observe(document.body, { childList: true, subtree: true });

unobserve marca o elemento como já disparado, mas nada persiste esse estado. Qualquer mutação no body chama observeAll(), que re-observa todos os elementos — inclusive os que já dispararam. Se o elemento ainda está na viewport, o IntersectionObserver notifica de novo e o evento dispara de novo.

E o dispatch faz window.dataLayer.push(...), que faz o GTM disparar tags, que injetam nós no body, que geram mutação, que chama observeAll(). O ciclo se auto-alimenta.

Impacto medido

Loja VTEX real (deco-sites/farmrio-storefront), PLP, navegador parado, sem scroll nem clique:

	GTM ativo	GTM bloqueado
long tasks em 20s	245 tarefas, 15887 ms bloqueados	6 tarefas, 458 ms
chamadas a observe()	2340	108
exceptions não tratadas	133	1
clique num card → PDP	1146 ms	209 ms

79% da main thread consumida em loop, numa página parada. O view_item_list e o view_category dispararam 175 vezes cada em 30 segundos (deveriam disparar uma vez), cada um levando junto um TypeError: Cannot read properties of undefined (reading 'split') de dentro do gtm.js.

Além do custo do loop, o observeAll roda um querySelectorAll no documento inteiro a cada mutação — nesta PLP são 611 elementos com data-event-trigger, e 1181 callbacks de mutação em 20s.

Efeito colateral relevante: como o evento é re-enviado centenas de vezes, os relatórios de analytics ficam inflados — view_item_list reportado 175x por pageview.

Proposta

Persistir o "já disparou" no próprio elemento e excluí-lo do seletor:

    if (entry.isIntersecting) {
      var event = getEvent(entry.target);
      if (event) dispatch(event);
      entry.target.setAttribute('data-event-fired', '');
      viewObserver.unobserve(entry.target);
    }
...
function observeAll() {
  document.querySelectorAll("[data-event-trigger='view']:not([data-event-fired])")
    .forEach(function(el) { viewObserver.observe(el); });
}

Sugiro também agrupar o observeAll do MutationObserver num requestAnimationFrame/debounce — mesmo corrigido o loop, um querySelectorAll de documento inteiro por mutação é caro em página com muita tag de terceiro.

Feliz em mandar PR.

[viniciusventura29]

Validei o patch proposto medindo direto no navegador, com o GTM inteiro rodando nos dois cenários — a única variável é a correção. Simulei o fix interceptando o IntersectionObserver com escopo restrito a [data-event-trigger], que é exatamente o que o patch faz (elemento que já disparou não volta a ser observado), sem tocar em nenhum outro observer da página.

PLP, 20s, navegador parado, sem scroll nem clique:

	como está	com o fix
main thread bloqueado	15665 ms (248 long tasks)	1423 ms (23 long tasks)
chamadas a observe()	2331	270
view_item_list no dataLayer	118x	2x
exceptions não tratadas	134	6
clique num card → PDP	1699 ms	330 ms

Como referência de piso, bloquear o GTM por completo dá 458 ms de main thread. Ou seja: dos ~15,2s de excesso, ~14,2s são o loop e ~1s é o custo normal das tags. O loop é o responsável, não o volume de terceiros.

Duas ressalvas de contexto, pra ninguém priorizar errado:

1. As medições são num preview da migração da loja pro @decocms/blocks, não em produção. A produção da farmrio.com.br roda o runtime de analytics antigo, que não tem o observeAll, e está limpa. Corrigindo o "loja VTEX real" que escrevi na issue — o bug não está afetando tráfego real hoje, mas bloqueia o cutover.
2. O view_item_list cai pra 2x e não 1x. Essa duplicação restante é nossa, não de vocês: o dispatch empurra pro dataLayer e pro DECO.events, e o subscriber da loja re-empurra pro dataLayer os eventos que ele não trata. Vou tratar do nosso lado.

Se ajudar, mando o PR com o patch.

[viniciusventura29]

Complemento importante, e ele afeta o escopo do patch.

Testando com o fix aplicado, sobrou uma duplicação 2x por evento. Investiguei achando que fosse do nosso lado e não é — os elementos são substituídos por nós novos depois do carregamento.

Rastreei a identidade de cada nó, atribuindo um serial na primeira vez que ele é observado:

[1] view_category   nó #1   já_disparou=false
[2] view_item_list  nó #2   já_disparou=false
[3] view_category   nó #10  já_disparou=false   <- nó novo, dispara de novo
[4] view_item_list  nó #11  já_disparou=false   <- idem

elementos no DOM ao final: #10 a #18  (o conjunto inicial #1-#9 sumiu inteiro)

O HTML do servidor vem com 9 elementos (#1–#9), eles disparam, e em seguida a página troca o conjunto inteiro por nós novos (#10–#18), que disparam outra vez.

Consequência pro patch: marcar o elemento com data-event-fired resolve o loop infinito (118x → 2x, que é o que importa), mas não cobre esse caso — o nó novo nasce sem a marca. Se a intenção for garantir "um evento por pageview", o dedupe precisa sobreviver à substituição do nó, o que sugere chavear por conteúdo do evento e não por identidade do elemento.

Não estou pedindo que isso entre no mesmo patch — o loop é de longe o problema grave e vale corrigir sozinho. Só registrando pra não fechar como resolvido e o 2x passar batido.

Estou investigando do nosso lado por que a página substitui esses nós; se descobrir algo que seja do framework, comento aqui.