Optimizing Global Navigation

[sharmrj]

Recently the feds team began to look at optimizing the load of the Global Navigation block. It's certainly possible for the block to become visible sooner than it currently does. This post describes the methodology, the code changes, and the tradeoffs to be made so that the community can comment on them before we go ahead with the changes.

A note on methodology

We throttle our network connection to "Slow 4G" provided on Chrome, and do singular runs to measure the performance using performance.mark and performance.measure. We do not throttle the CPU. While doing singular runs is not sufficient for predicting the real world performance, it is sufficient to confirm whether a specific change improved or worsened the performance. We also use content overrides to override the Response objects in Chrome DevTools. This allowed us to test on prod with the load times prod provides.

Baseline performance

Before making any changes we must establish a baseline. Gnav is loaded quite simply:

// Utils.js, inside loadPostLCP
 const header = document.querySelector('header');
  if (header) {
    header.classList.add('gnav-hide');
    await loadBlock(header);
    header.classList.remove('gnav-hide');
  } 

The LCP can be inferred by adding the start time and the duration of 'FirstSectionLoaded'. We can see that the LCP is ~5.5 seconds, the gnav starts loading in around 6 seconds in and takes another ~5.5 seconds. Further we see that, since the subsequent sections are blocked by the gnav, the second section only finishes loading ~12.5 seconds in, with the rest completing ~20 seconds in. This is undesirable since the user is unable to scroll or see any further content until further sections load.

Make the Gnav non-blocking

Our first change is to make gnav non blocking; simply remove the await. This makes it more likely that subsequent sections interfere with the load of the gnav, but the page overall feels faster since the amount of time the user waits for the second section is dramatically reduced.

We can see the LCP and the total amount of time the gnav takes is unchanged, but the second section loads ~5 seconds faster.

Parallelize requests for required assets

The next step is a little more involved. The gnav does an initial load of its main content, and loads the rest (dropdown content, unav, etc.) For the initial load, we require a few files:

• global-navigation.js and global-navigation.css
• base.css and, if enabled, dark-nav.css
• utilities.js
• breadcrumbs.js
• The first .plain.html file for the initial content
• We also need federated.js to find the correct path to the initial content; if the marquee is on the page, it should already be in memory.

The code change to do all this is a little more involved. It requires us to move logic into utils.js (see tradeoffs section below)

  const loadHeader = async () => {
    const conf = getConfig();
    header.classList.add('gnav-hide');
    const cssPromise = new Promise((resolve) => {
      loadStyle('/libs/blocks/global-navigation/global-navigation.css', resolve);
    });
    const baseStylesPromise = new Promise((resolve) => {
      const path = '/libs/blocks/global-navigation';
      loadStyle(`${path}/base.css`, () => {
        if (conf.theme === 'dark') loadStyle(`${path}/dark-nav.css`, resolve);
        else resolve();
      });
    });
    const initHeader = async () => {
      const headerUtilsPromise = import('../blocks/global-navigation/utilities/utilities.js');
      conf.gnav.utilsPromise = headerUtilsPromise;
      const breadcrumbsPromise = import('../blocks/global-navigation/features/breadcrumbs/breadcrumbs.js');
      // federated.js is generally already imported at this point
      // since decorate.js uses it and the first section usually
      // requires decorate.js. If not, we import it here.
      const plainHTMLPromise = (async () => {
        const { getFederatedUrl } = await import('./federated.js');
        const source = await conf?.gnav?.sourcePromise ?? '';
        const [url] = source.split('#');
        let federatedURL = getFederatedUrl(url);        
        const mepGnav = conf?.mep?.inBlock?.['global-navigation'];
        const mepFragment = mepGnav?.fragments?.[federatedURL];
        if (mepFragment && mepFragment.action === 'replace') {
          federatedURL = mepFragment.content;
        }
        const res = await fetch(federatedURL.replace(/(\.html$|$)/, '.plain.html'));
        return res;
      })();
      const { default: init } = await import('../blocks/global-navigation/global-navigation.js');
      await init(header, breadcrumbsPromise, plainHTMLPromise);
    };
    await Promise.all([cssPromise, baseStylesPromise, initHeader()]);
  };
  if (header) {
    loadHeader().catch((e) => console.log('Failed to load global navigation', e));
  }

We also need to modify the gnav init function and the fetchAndProcessPlainHTML function to accept promises instead of making the network calls themselves.

We see some improvement: gnav now loads in ~3.8 seconds.

Show the Gnav Earlier

Finally we see that the gnav can only become visible after the following code finishes executing:

  init = () => logErrorFor(async () => {
    this.elements.curtain = toFragment`<div class="feds-curtain"></div>`;    // Order is important, decorateTopnavWrapper will render the nav
    const tasks = [
      this.decorateAside,
      this.decorateMainNav,
      this.decorateTopNav,
      this.decorateTopnavWrapper,
      loadBaseStyles,
      this.ims,
      this.addChangeEventListeners,
    ];
    const fetchKeyboardNav = () => {
      setupKeyboardNav(this.isLocalNav());
    };
    this.block.addEventListener('click', this.loadDelayed);
    this.block.addEventListener('keydown', fetchKeyboardNav);
    setTimeout(this.loadDelayed, CONFIG.delays.loadDelayed);
    setTimeout(fetchKeyboardNav, CONFIG.delays.keyboardNav);
    for (const task of tasks) {
      await yieldToMain();
      await task();
    }    document.addEventListener('click', (e) => closeOnClickOutside(e, this.isLocalNav(), this.elements.navWrapper));
    isDesktop.addEventListener('change', closeAllDropdowns);
  }, 'Error in global navigation init', 'errorType=error,module=gnav'); 

The problem is that this.ims will load the universal nav, and we won't be able to show anything until the promise for the unav js and css resolves (though we don't wait for them to be executed). The solution, then, is

    const tasks = [
      this.decorateAside,
      this.decorateMainNav,
      this.decorateTopNav,
      this.decorateTopnavWrapper,
      () => {
        this.block.classList.add('ready');
        this.block.classList.remove('gnav-hide');
        performance.mark('Gnav');
        console.info(performance.measure('LoadAreaStartToGnavVisible', 'LoadAreaStart', 'Gnav'));
        console.info(performance.measure('TotalGnavTime', 'Georouting', 'Gnav'));
      },
      this.ims,
      this.addChangeEventListeners,
    ];

Upon measurement:

We see the gnav takes only ~650ms to become visible. If we move the gnav load before georouting (or make that async as well), we could pull back the gnav to load another ~600ms earlier. We can't move the gnav load any earlier without affecting the LCP (since the gnav is unlikely to be the LCP unless the user interacts with the page).

Tradeoffs

There are a couple of tradeoffs we make for this optimization

• More code in utils.js: We resist adding code to utils.js, especially code that isn't required on every page load. However, this is mitigated since presumably there are no pages where gnav is not loaded
• Increased complexity and tech debt: this makes the flow of how gnav is loaded a little harder to understand if one has no context.
• Since Gnav appears visible earlier but only starts loading dropdowns 3 seconds later or after the user clicks on the gnav, we potentially have to make the user wait a significant amount of time to show them content if they click early enough. We may have to introduce a loader to mitigate this and re-assure the user that something is happening. EDIT: here're the designs for the loader: https://www.figma.com/design/UPkBzzfG2NaLGWlhhLdcJ6/Adobe-GNav-UX_UI?node-id=1057-29480&m=dev&focus-id=4768-21903

In exchange we get

• Gnav now becomes visible ~650ms after it starts loading.
• Subsequent sections load faster and are no longer blocked by the gnav

Are these tradeoffs worth it? It's possible to pick and choose which optimizations we want.

You can see all the changes here: https://github.com/adobecom/milo/compare/gnav-performance?expand=1

cc: @salonijain3 @skambi @bandana147

[amitbikram]

I believe we should avoid adding GNAV-specific logic to utils.js, as it would be hard to maintain and understand how GNAV is loaded. Instead, could we handle this optimization within global-navigation.js? This might result in global-navigation.js and global-navigation.css being loaded via loadBlock(), causing a slight performance trade-off. However, this should be acceptable since CWV isn’t our primary focus for this improvement.

I tested the changes locally and noticed flickering while loading GNAV, though I’m not sure if it’s just on my end. We also need to align with the business to ensure the right loading experience for the dropdown and UNAV container, as these components are delayed.

[mokimo]

I had the same thought, IMO all the loading optimization should be encapsulated within the global-navigation and the utils should just ensure we load that file.

While we do lose some time on loading the global-navigation as we need to wait for the initial JS/CSS to be loaded, I believe from a maintenance perspective it's better to trying to keep the utils as slim as they can be...

[salonijain3]

The main downside of loading everything from the global navigation file is losing the ~400-600ms performance gain. In my opinion, the performance benefit is worth preserving if we can simplify the approach.

@amitbikram @mokimo do you have any ideas on reducing complexity while still loading it from utils.js?

[vhargrave]

@salonijain3 If we have data that a lot of users are interacting with the gnav then I agree with you that we shouldn't be ignoring these performance gains. What if we did the following :
In the loadPostLCP method, I'm already seeing quite a lot of potential to get some performance improvments. We're importing and awaiting one js file after the other and running code from there.
I think we could absolutely parallalise the imports that are taking place, so that this all runs a lot faster.

In addition, even though I fully support @mokimo & @amitbikram that this is not great from a maintenance perspective, if it's one extra method we're adding and that makes both the gnav & the rest of the page load about 400 - 600 milliseconds faster, then I unfortunately think it's worth it (especially if a lot of users are interacting with the CTA in the gnav, which is something I've heard they're doing).

[narcis-radu]

I remember we had some conversations about Milo consumers who are not using the Global Navigation, they would get the extra code even if it's not used. If we have good data that shows the Global Navigation should be loaded faster, then I think it's a good tradeoff, we just need to make sure the code is properly handled.

[salonijain3]

@narcis-radu are there any milo consumers who are not using the global navigation?

[salonijain3]

@vhargrave We are thinking of pulling in global navigation before geo routing or making it async so that the global navigation loads faster. This is for improving the global navigation experience. Do you see any risk in this approach?

[salonijain3]

@sharmrj Can we gather these data points, then lets speak with Roland and figure this out?

[sharmrj]

We probably should get the georoutingV2.json file while waiting for the js file, but removing the await as well shouldn't affect the load times significantly because the amount of time spent waiting for network requests is at least one order of magnitude greater than the time spent in code parsing and execution (the difference is even greater on slower networks).
So if we remove the await, while we wait on the georouting javascript file we can kickoff the request for global-navigation.js. And while we wait for geourouting.json, the code for global-navigation is already in the event queue so we can make the request for gnav.plain.html. And while we're waiting on gnav.plain.html, the control flow can go back to georouting.
I've been testing with slow 4G, and with that amount of network throttling here's the result we get

If we remove the await from georouting:

We can see the the georouting takes ~200ms extra in this run (on slow 4G) but the global-navigation and the subsequent sections get a little faster. That 200ms can be more than gained back by loading georouting.js and georouting.json simultaneously like you suggested @vhargrave.

[vhargrave]

if there's no change to the current impact on pages, then I'm also in agreement with removing the await on the georouting 👍

[narcis-radu]

@sharmrj - would be helpful to inform all parties about this change, even if it does not have any impact. They can keep an eye on it to make sure there's no impact on business.
cc @salonijain3

[salonijain3]

@narcis-radu sure, will inform the pdms as part of the JIRA ticket.

cc: @sharmrj

[salonijain3]

I wanted to provide more context on the focus on loading the global navigation earlier:

1. A quantitative analysis from first-click data and user interviews (2024) highlighted this as a key outcome:
   More than half of users clicked “Try Now” in the global navigation on Illustrator product pages.

Reference: Qualitative Research Findings

2. Leadership has also expressed interest in displaying the global navigation sooner than the current experience.

[mokimo]

One more note/FYI/consideration... We have multiple possible LCP elements, so it can also be that the same page has an LCP in the first, second and third section. So if the second and third section compete against loading all the post LCP code (gnav, privacy, etcetc), you might hurt the overall LCP.

[sharmrj]

They do. Currently we await both georouting and global-navigation which results in the second and third sections loading much later than they need to. When we remove the await on just the gnav, we a ~5 second differential when the network is throttled to Slow 4G. I've documented that here

[sharmrj]

There's another thing to consider here, which is INP. Since we're showing everything early, and dropdowns are even less likely to arrive by the time the user can click a dropdown, we are liable to have a high INP. This is solved also by the introduction of a loading state.