Delayed vs. Consented

[fkakatie]

Summary

Two competing draft PRs propose different approaches to delayed.js loading. The main branch still uses a 3-second timeout.

PR	Approach	Trigger	Breaking Change	Complexity
#408	Interaction-triggered	scroll, click, touch, keydown, mousemove	No	Low (1 file)
#376	Consent-based	User consent decision	Yes (requires consent UI)	High (5 files)

Key context: @davidnuescheler (author of both) explicitly stated these are "competing approaches."

---

Current Implementation

function loadDelayed() {
  window.setTimeout(() => import('./delayed.js'), 3000);
}

Simple 3-second delay after lazy content loads. Projects extend delayed.js for analytics/marketing tech.

---

PR #408: Interaction-Triggered

PR | Demo | @davidnuescheler | Oct 2024

Loads delayed.js on first user interaction instead of timeout. Listens for scroll, click, touchstart, keydown, and mousemove events.

Review highlights:

• @freshjones asked if teams should wait for chore: change from delayed flow to include consent #376 first
• @davidnuescheler: "Even if chore: change from delayed flow to include consent #376 lands, traditional loading may still be used"
• Open question: Should consent (chore: change from delayed flow to include consent #376) also wait for interaction?

---

PR #376: Consent-Based

PR | Demo | @davidnuescheler | Jun 2024

Replaces delayed loading with consent-gated loading. Marketing tech waits for explicit user consent.

Adds:

• scripts/consent.js with handleConsent() function
• Consent banner fragment loading
• aem:consentchange event system

Open issues:

• Event naming: aem:changeconsent vs aem:consentchange
• Hardcoded consent banner path needs configuration
• Event listeners inside check functions risk duplicates

---

Decision Framework

The choice depends on boilerplate philosophy:

Priority	Recommendation
Minimal/unopinionated	Status quo (timeout)
Performance without breaking changes	#408 (interaction)
Privacy/GDPR compliance	#376 (consent)
Both performance and compliance	Hybrid (most complex)

Hybrid concept:

function loadMarketingTech() {
  Promise.all([handleConsent(), waitForInteraction()])
    .then(() => import('./delayed.js'));
}

---

Recommendation

• Merge chore: use events as trigger to load delayed.js #408 — clear performance benefit, no breaking changes, aligns with minimal boilerplate philosophy.
• Document chore: change from delayed flow to include consent #376 as a project-level pattern — consent requirements vary by region/industry; too opinionated for boilerplate core.

[ramboz]

For 1., I'd be worried that we artificially create INP with that approach. If you start loading a large martech as the user scrolls and/or clicks, it's likely to cause TBT and INP.

For 2. I'd argue that consent only applies to the martech stack and I've seen other stuff loaded in the delayed phase so I would not want to block those scripts. Also, some of the martech is not subject to cookie consent (as they have proper fallbacks in place). To me that would be a breaking change.

I would propose:

• rely on requestIdleCallback (or fallback to setTimout(, 0)) after the lazy phase so that we load the martech any time the CPU becomes idle after the page is fully rendered
• use event listeners for the consent changes that are attached immediately, but execute the handlers on a requestIdleCallback after the lazy phase as well

Alternatively, for the user interaction approach, then I'd at least make sure to fire with requestIdleCallback

[fkakatie]

Genuinely love this proposal. requestIdleCallback makes a ton of sense.

Browser support concern: requestIdleCallback is at ~83% support. You're right about the fallback, which would be... the 3-second timeout we already have? Seems like appropriate degradation to current behavior. Unless I'm missing something about the fallback strategy?

On consent vs delayed loading: Agreed these are separate concerns. I've also seen plenty of stuff in delayed.js that doesn't need consent.

I think I'm most intrigued by combining requestIdleCallback with user input. That feels like the sweet spot: doesn't load until the user is actually engaging AND the CPU has capacity. Best of both worlds without the INP risk.

[ramboz]

Unless I'm missing something about the fallback strategy?

No, that's exactly it. There are some fancy requestIdleCallback polyfills, but I think a plain setTimeout(…) is enough. It breaks up the long task and allows the browser to prioritize some frame renderings if needed.

I think I'm most intrigued by combining requestIdleCallback with user input.

I think this is more of a philosophical discussion. I feel this is trying to only load the martech if we detect an actual human, and skip collecting data for bots… which might not be what customers' marketing teams want or need. And bots will typically do some basic scrolling to trigger IntersectionObservers and load async content nowadays, so they'd likely bypass that logic.

I'd rather lean toward loading it in all cases and letting the practitioner decide how to filter the data, rather than artificially (and arbitrarily) filtering on the collection side. I feel this makes it more predictable and consistent with industry-standard data collection practices.

[fkakatie]

@ramboz Thank you so much for your proposal and patience throughout this discussion!

I've implemented your suggestion in PR #586 (hopefully). Would you mind taking a look when you get a chance? I'd really appreciate your feedback to make sure this aligns with what you had in mind.

Thanks again for taking the time to work through this with me!