MWPW-167717 Parallelize requests inside global-navigation.js

[sharmrj]

This is the third in a series of PRs to optimize the global-navigation load time.

1. MWPW-168334 Load georoutingv2.json and georoutingv2.js in parallel #3720 Load georoutingv2.json and georoutingv2.js in parallel
2. MWPW-167716 Remove await from both gnav and georouting #3680 Remove await from both gnav and georouting

See the discussion #3558 for details, including the results of lab performance tests. Some discussion was had whether the parallelization of calls should go in utils.js instead of global-navigation.js, but it was ultimately decided that we did not want to add too much code to utils.js.
This is the first PR that directly touches gnav code

• Except for utils.js, which is expected to already have loaded in both Milo and in Standalone contexts, the requests for all required dependencies are kicked off concurrently instead of one at a time. This was done by changing the import statements at the top of the file into dynamic imports.
• Some imports are conditional, and those conditions were lifted to the top of the file where the imports are done. This is possible since these conditions depend on global state in one form or another
  • Breadcrumbs only loads if the header element has the class has-breadcrumbs, which is added in decorateHeader inside utils.js when a breadcrumbs block is in the document.
  • Aside only loads if the metadata gnav-promo-source is present in the head.
• The fetch of the initial gnav plain.html document was also lifted to the beginning of the file. fetchAndProcessPlainHTML was modified to optionally accept a promise.
• Global navigation testing was modified somewhat
  • This PR loads certain resources when the module is loaded rather than when the init is called. The main one we're concerned with is getGnavSource.
  • This means when a certain test requires a different file (even though it's mocked) to be loaded, this would not be possible since the gnav source was set when the module was loaded.
  • The solution is to 1) dynamically import global-navigation.js in tests where it is required rather than as a top level import, and 2) to add a unique query parameter to cause the module to reload completely.

Resolves: MWPW-167717

Test URLs:

• Before: https://main--milo--adobecom.aem.page/?martech=off
• After: https://gnav-optimize-network-requests--milo--adobecom.aem.page/?martech=off

QA:
A vanilla page: https://main--cc--adobecom.aem.live/products/photoshop?milolibs=gnav-optimize-network-requests
Standalone Dark Mode: https://adobecom.github.io/nav-consumer/navigation.html?env=prod&navbranch=gnav-optimize-network-requests&theme=dark
Standalone Light mode: https://adobecom.github.io/nav-consumer/navigation.html?env=prod&navbranch=gnav-optimize-network-requests

We should also test a page with a promo, and a page with the dynamic nav enabled.
If performance is being tested, it's best to use content overrides on prod and compare it to prod.

[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

• d536f37 ✅ (latest)
• 0b6ce6f ✅
• bdb94d7 ✅
• 0214479 ✅
• 0e65f7e ✅
• 91c6202 ✅
• 12e31a4 ✅
• 39db841 ✅
• 89199cb ✅
• d8ff070 ✅
• 29147e7 ✅
• b3e4fff ✅
• daa4849 ✅
• d752143 ✅

[aem-code-sync]

	Page	Scores	Audits	Google
📱	/?martech=off
🖥️	/?martech=off

[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.

[bandana147]

Why do we need window.location.origin, any page would always have locale.contentRoot, right?

[sharmrj]

Not necessarily: some unit tests were failing because of this, which made me aware of the fact that it's possible, in certain situations, to have no locale.contentRoot. Defensive code, in general, is better than code that makes assumptions that can be wrong as it allows us to fail gracefully.

[bandana147]

Can we remove the !promoPath since it is already checked in asideJsPromise?

[sharmrj]

I'd like to leave this code a bit defensive, even if it's just for the sake of unit tests. If ever there arises a situation where asideJSPromise is null but promoPath exists, we'll still get a promo.

[bandana147]

@nishantka Can you check this once? I remember you encountered an issue while implementing this and had to explicitly use a promise.

[nishantka]

This will work, we just have to load dark-nav.css after base.css. We were using callback for adding Lana logs here - if we can catch errors also that will be great.

[sharmrj]

@bandana147 @nishantka I've added some error handling here.