removed loadAlloy function; deferred instruments.js

[maxn-adobe]

Summary

Modified scripts.js, removed loadAlloy function; deferred loading of instruments.js.

Here are explanations of both changes that were made:

Fix 1: Defer instrument.js import until after loadArea()

Previously, instrument.js was imported as a fire-and-forget dynamic import immediately before await loadArea() — meaning the browser was simultaneously trying to download, parse, and execute the analytics module at the same time it was painting the LCP element. This created two forms of contention during the most performance-sensitive window on the page: network bandwidth competition (the Demdex audience segment fetch in instrument.js races against the LCP image fetch) and main thread pressure (the alloy_all data layer setup and event listener registration add JS execution cost while the browser is trying to complete layout and paint).

The fix moves the instrument.js import to after await loadArea() completes, placing it alongside express-delayed.js where deferred work already lands. This is also semantically more correct: instrument.js's default export (martechLoadedCB) calls decorateAnalyticsEvents() which sets data-analytics attributes on DOM elements — work that requires the full DOM to be present anyway. No analytics fidelity is lost by this change; click tracking listeners attached after LCP miss no meaningful interactions during the page-load phase, and the audience segment data for the ratings block arrives only marginally later with no user-visible effect.

Fix 2: Remove listenAlloy()

listenAlloy() was a function introduced to expose window.alloyLoader — a Promise that was intended to resolve when alloy dispatched a pageView event. The function had a // TODO this method should be removed about two weeks after going live comment indicating it was always meant to be temporary. Investigation confirms it is now dead code for two independent reasons: first, the event listener inside it checks e.detail.type === 'pageView', but the alloy_sendEvent custom event dispatched by milo's helpers.js has a detail object of { destinations, propositions, inferences, decisions } with no type field — so the condition is never true and the promise is never resolved via the event. Second, a codebase-wide search found zero consumers of window.alloyLoader in either da-express-milo or milo, confirming nothing awaits it.

The practical consequence was that the setTimeout(..., 3000) fallback — the only code path that ever resolved the promise — fired unconditionally on every page load at exactly 3 seconds, creating a guaranteed JS task right in the middle of the LCP and TTI measurement windows. Removing the function and its call site eliminates this timer entirely with no effect on analytics, click tracking (which operates through Launch rules and the safelyFireAnalyticsEvent pattern in instrument.js independently), or any other runtime behavior.

---

Jira Ticket

Resolves: MWPW-192838

---

Test URLs

Env	URL
Before	https://main--da-express-milo--adobecom.aem.page/express/
After	https://mwpw-192838--da-express-milo--adobecom.aem.page/express/

---

Verification Steps

These updates should have no visible or functional effect, other than increasing the pageload speed and improving the CWV's of our pages.

---

Potential Regressions

N/A

---

Additional Notes

[aem-code-sync]

Hello, I'm the AEM Code Sync Bot and I will run some actions to deploy your branch and validate page speed.
In case there are problems, just click a checkbox below to rerun the respective action.

• Re-run PSI checks
• Re-sync branch

Commits

• 8cbc831 ✅ (latest)

[aem-code-sync]

	Page	Scores	Audits
📱	/express/
🖥️	/express/

[maxn-adobe]

Ran the PR-review tool, including it's output here:
2026-04-17-PR371.md

[fullcolorcoder]

Can we move that to delayed?

[fullcolorcoder]

This PR gets instrument.js out of the LCP window which is the main win, but it still fires immediately after loadArea() rather than inside express-delayed.js where true Phase D work lands. Since you've already shown the DOM needs to be complete anyway and no fidelity is lost by deferring, would it make sense to move this entirely into express-delayed.js? Not a blocker — the current improvement is substantial — just curious if there's a reason to keep it in the middle.