MWPW-201399 Preload MAS fragments

[TsayAdobe]

As more pages integrate with MAS, prefetching MAS fragment content is important for performance. This PR adds an early prefetch for MAS fragment URLs referenced on the marquee: as soon as a MAS-fragment autoblock link (merch-card, merch-card-collection, mas-compare-chart) is recognized during autoblock decoration, its fragment URL is preloaded — before the block itself would otherwise request it.

Since the locale/country derivation needed to build a matching URL depends on merch.js's GeoMap, a copy of that lookup table was added to utils.js (MAS_GEO_MAP).

Resolves: MWPW-201399

Test URLs:

• Before: https://main--milo--adobecom.aem.page/?martech=off
• After: https://MWPW-201399--milo--adobecom.aem.page/?martech=off

The following tests was done with content overrides on www.adobe.com. In the file /mas/libs/merch-cards.js, credentials:"omit" should be replaced with credentials:"same-origin". Then replace the file /libs/utils/utils.js with the one in this PR. Environment settings: CPU: 4X slowdown, Network: Fast 4G, and Disable network cache.

• https://www.adobe.com/fr/products/premiere.html?akamaiLocale=be&mep=off
  (when mep is on, the marquee is replaced and it doesn't use a MAS fragment)

• Before:
  The call /mas/io/fragment is usually taking about 200ms to 800ms blocking the LCP.

• After:
  The fragment is preloaded and the LCP is done earlier.

[aem-code-sync]

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

• Re-sync branch

Commits

• ec2b886 ✅ (latest)
• 9b08898 ✅

[github-actions]

This pull request is not passing all required checks. Please see this discussion for information on how to get all checks passing. Inconsistent checks can be manually retried. If a test absolutely can not pass for a good reason, please add a comment with an explanation to the PR.

[yesil]

fyi: @npeltier

[yesil]

@TsayAdobe I find it risky to duplicate mas GEO in a different file.
the fragment must be fetched with the right parameters once Milo initializes fully with the Lingo logic.

maybe you can move this logic around isLcpSection and import merch.js to let commerce initialize and then use it to read country/locale/api key etc.

[TsayAdobe]

@yesil For performance purposes, we should move more merch initialization services into Milo’s utils.js. We can then preload merch scripts and prefetch fragments. We can externalize mas GEO in utils.js and have the merch scripts import it.

How often do we update a fragment’s ID or country in a way that makes prefetching ineffective? If that happens less than 10% of the time, I think prefetching is still a net win.

[yesil]

I agree but we should use merch.js to initialize it.
Maybe even before decorateAutoBlock, you can check if there is merch in the LCP block, load merch.js first, init commerce and and use it to preload the fragment.

[narcis-radu]

A lot of MAS related logic that's going to be loaded by all Milo consumers, regardless of whether they use MAS or not. The code should not live inside utils.js, and should be loaded only when / if needed.

[vhargrave]

@TsayAdobe just an idea because I know we need this fix , is there a super lightweight file we could load from m@s as quickly as possible if a m@s autoblock is in LCP, which holds the mas geo information and kicks off the fragment load and everything else, so that there's still just one file in M@S with that information, but we're also kicking the load off as fast as we can ?

[TsayAdobe]

A lot of MAS related logic that's going to be loaded by all Milo consumers, regardless of whether they use MAS or not. The code should not live inside utils.js, and should be loaded only when / if needed.

@narcis-radu This needs to run synchronously inside decorateAutoBlock, before any async work, so the preload fires in the same tick a MAS link is recognized — that's what lets it win the race against the block's own fetch. Deferring it to a dynamic import would push it past that tick and defeat the purpose.

On pages that don't use MAS, the cost is just the early-return check against MAS_FRAGMENT_AUTOBLOCKS — no request, no locale/geo work runs.

[TsayAdobe]

@TsayAdobe just an idea because I know we need this fix , is there a super lightweight file we could load from m@s as quickly as possible if a m@s autoblock is in LCP, which holds the mas geo information and kicks off the fragment load and everything else, so that there's still just one file in M@S with that information, but we're also kicking the load off as fast as we can ?

@vhargrave Lightweight doesn't solve this — for a file this small, the cost is almost entirely the network round-trip (DNS + connection + request/response), not transfer time, so shrinking the payload barely helps. Any separately-hosted file still costs a full extra RTT we don't pay today. utils.js is already part of Milo's bootstrap and loads on every page regardless, so folding the geo data into it adds zero extra requests — we're just parsing a few more KB of a file already in flight. That's why this needs to live in utils.js, not a separate file, even a tiny one.

[vhargrave]

@TsayAdobe just an idea because I know we need this fix , is there a super lightweight file we could load from m@s as quickly as possible if a m@s autoblock is in LCP, which holds the mas geo information and kicks off the fragment load and everything else, so that there's still just one file in M@S with that information, but we're also kicking the load off as fast as we can ?

@vhargrave Lightweight doesn't solve this — for a file this small, the cost is almost entirely the network round-trip (DNS + connection + request/response), not transfer time, so shrinking the payload barely helps. Any separately-hosted file still costs a full extra RTT we don't pay today. utils.js is already part of Milo's bootstrap and loads on every page regardless, so folding the geo data into it adds zero extra requests — we're just parsing a few more KB of a file already in flight. That's why this needs to live in utils.js, not a separate file, even a tiny one.

@TsayAdobe fair - alright, two comments from my end then

1. if you can clean up the comments
2. if you can rewrite this a little so that the merch stuff is only preloaded if a price is in LCP (essentially only if a price is in the first section). To do that you could pass the section to processLinkDecoration , and then to the decorateAutoBlock functions and check if the section index is zero. Something like that.

If you do that then this looks good to me .

[narcis-radu]

Thanks, @TsayAdobe. Would it be possible to check whether M@S is in use before utils.js even loads? That way we'd know upfront if the extra code is actually needed. Not sure if this is feasible, but it seems worth exploring before we commit to loading additional code in utils.js.
https://github.com/adobecom/milo-college/blob/main/scripts/scripts.js#L109

[github-actions]

This PR has not been updated recently and will be closed in 7 days if no action is taken. Please ensure all checks are passing, https://github.com/orgs/adobecom/discussions/997 provides instructions. If the PR is ready to be merged, please mark it with the "Ready for Stage" label.