Building imslib internally and loading it from deps folder

[narcis-radu]

We currently load imslib v2 from https://auth.services.adobe.com/imslib/imslib.min.js which works well but we have to pay some penalty for DNS lookup, SSL and connection on all pages. The new imslib v2 library can also be loaded as an npm package, multiple projects are already using this approach.
We could leverage this functionality, build imslib v2 internally, upload it to /deps and load it through miloLibs, thus ensuring that the file gets loaded from the same domain. In practice this should shave off about 50 - 400ms (depending on location) from the timeline and help with loading of other critical scripts which will improve the scores.
The downside of this approach is that we would need to manually update the library whenever there's a new change, but looking at existing releases we would only have to do this once or twice a year.

The team working on the homepage has done some testing and they get good results with this approach. I have created a POC, you can check the code: 97ef972 and test it using ?milolibs=imslib--milo--narcis-radu.

I would like to know if you see any issues with building imslib internally and loading it from /deps folder.

[mokimo]

Given this is used by personalization for entitlements and high visibility consumers or often is needed pre-LCP shaving off the TCP handshake sounds well worth the slightly increased maintenance cost.

I wonder if we should consider just proxying this via akamai? I'm not sure if there is any performance difference, either way that should get rid of the DNS lookup, SSL and initial connection

[narcis-radu]

The problem with proxying is that newer projects would have to take care of creating the proxy before going live e.g. sub.adobe.com/path/to/imslib.js whereas hosting the library would make it accessible through milo.adobe.com out of the box.
I'm not sure about performance differences between the two.

[yesil]

Since we always make a call to IMS[0] after loading imslib.js, can we check with the IMS team whether we can load imslib.js from [0]?
Thus, we don't have to support the imslib build and have 1 domains less w.r.t DNS lookup, SSL handshake.

[0] - https://ims-na1.adobelogin.com/ims/validate_token/v1

[narcis-radu]

The domains have different usages.

[yesil]

a domain can serve many purposes. why it cannot serve static js files on top of the REST endpoints.

[narcis-radu]

I'm sure it can but we would have a dependency on the imslib team to provide configurations and maintain.

[narcis-radu]

I have created a request to Identity team - https://jira.corp.adobe.com/browse/IDOPS-16077

[auniverseaway]

If this can work, I am definitely a +1.

I think the only question would be the build regularity and automation. We are not fans of required builds for D2D and local development, but in some rare cases (maybe 1?) we do adhoc builds... Preact comes to mind.

My hope would be we could some how observe new releases, run a GH action and create an automatic pr to do all of this for us.

[honstar]

I also support this effort if the aforementioned maintenance effort is low 👍

[mokimo]

Yes, we have a bunch of ideas on how to automate this process as much as possible similar to what Chris mentioned

My hope would be we could some how observe new releases, run a GH action and create an automatic pr to do all of this for us.

[narcis-radu]

Thank you all for the feedback! @auniverseaway, @honstar - would you find it acceptable to start with a manual build (imslib releases happen 2 - 3 times / year) and get this feature available on Production as soon as possible or wait until we implement a more automated process? I think we won't be able to do 100 automation because some of the internal environments, but we should be able to automatically create the file when a new release is made and send a notification.

[jedjedjedM]

@narcis-radu : I am sure the ops team can help with automation for this. A rundeck job could poll for a new version and kick off a build via circle or GH action.

[narcis-radu]

Thank you all! I will close the discussion and create a follow-up ticket to implement this feature.

[mokimo]

We've shipped this here: #1996