Extend Html library manager

[Kailash07]

Hi Everyone

 Light house is reporting unused Java scripts on our website which is causing some performance hit as well. We uses the page template which defines the possible components on this page and hence all clientlibs are loaded irrespective of authored or not.

We are thinking in direction of

1) Extending the Html library manager

2) Loading authored components clientLibs only on the fly.

Do you guys foresee performance overheads of the above approach ? Any one implemented some solutions ? It would be good to help me here.

Thanks

Kailash

[BrianKasingli · Accepted solution]

@Kailash07 
Although I've never extended the HTML library manager, I applied a manual approach. I can shed some light on the manual approach I've seen being used in production.

I understand where you are coming from. While embedding the entire client library will have pros and cons, ultimately you want to enhance the performance and only embed specific component's client libraries on the page when they are being used.

There were two manual approaches I've seen (this only works if you are creating client libraries per component):

1. Create a client library that reflects on a specific page template. This client library will only embed client libraries that have "allowed" components on the template. This approach will only load the client libraries that are allowed on the page.

PROS:

- Page performance is enhanced because you will only load what you use.
CONS:

- The page is still loading some unused component's client libraries, but this is better than loading them all.

- This approach is maintained by the developers, where if a new component's client library is required to be added into a page template, then the developers must update the specific template's client library.

- There will be lots of template specific client libraries and can be unmaintainable. (mind you that the customer only had 6-page templates)

- New page templates must be managed by developers. 

2. Utilise the page policies on the editable templates heavily. Train the content authors to edit the page policies whenever they are allowing a new component on the page.

PROS:

- Page performance is enhanced because you will only load what you use.

- Developers does not need to be involved when a new editable template is created.
CONS:

- Page maintainability will be unreliable... where template authors must never forget to include the correct component's client library in the page policies. If content authors forget to add the component's client library to the page policies, the component will not be working as expected.

Finally, we installed an Apache web server module named of `Google pageSpeed` to combine, and or minify all .js files into a single file, so there is only one .js request being made. 

I hope this gives you a broader picture of the manual approach.

[Nirmal_Jose]

Additional to what @BrianKasingli mentioned, if you use the latest maven archetype with ui.frontend module, you can take a look at dynamic loading implementation as mentioned in [1]

[1] - https://www.initialyze.com/blog/2020/11/how-to-use-dynamic-imports-with-adobe-aem/