Page specific clientlibs in AEM

[#1]

Page specific clientlibs in AEM

  by @MukeshYadav_ 

Dear AEM Community,
I would like to share a useful solution for enabling page-level control over Client-Side Libraries (Clientlibs) in AEM.

Problem Overview:

AEM by default allows authors to manage Clientlibs at the template level and component level but there are cases where authors may need the same level of control at the page level. For example, when using JavaScript libraries like Vue.js or React or any micro-frontend module, it is inefficient to load these libraries globally for every page. Additionally, managing the order and placement of these Clientlibs for optimized DOM rendering  that is it should load the clientlibs in footer which is ideal for perfect DOM rendering and performance of the page

Solution Overview:

The solution involves creating a custom page properties that allows authors to control the Clientlibs at the page level without affecting other pages of the same templates.

Key Steps:

1. Create a Data Source for Clientlibs – A servlet to list all available Clientlibs and expose them as a data source that can be used in page properties.

2. Add Clientlibs to Page Properties – Modify the page dialog to include a dropdown field, allowing authors to select which Clientlibs which is fetch via Servlet create din step 1.

3. Fetch and Display Clientlibs in Page HTML– A Sling model is created to add the selected Clientlibsto the page htm and load them in the page’s footer(for js) or header(for css) for optimized DOM rendering.

Full Article

Read the full article on https://www.tothenew.com/blog/page-specific-clientlibs-in-aem/  to find out more, including the complete code and step-by-step implementation guide, Thanks.

Q&A

Please use this thread to ask questions relating to this article

[#2]

Thanks for sharing this, @MukeshYadav_. Efficient solution! Page-specific control of clientlibs is such a common real-world need, especially when working with frameworks like Vue or React, where you don’t want global loading overhead. I like how your approach balances flexibility for authors with optimized DOM rendering by loading JS in the footer and CSS in the header.

Quick Question: in your experience, what’s the best way to prevent authors from unintentionally overloading a page with too many clientlibs? Do you usually handle that with governance, validation rules, or more?

[#3]

Hi @kautuk_sahni ,

Thank you for your suggestions to restrict / have an validation on the number of clientlibs that can be added on a given page by the authors.
If required we can either restrict the rendering of this proeprty to certain group, lets say 'super-author' or we can have validation in backend ( & frontend). Even we can implement both restrictions.

Thanks

[#4]

@MukeshYadav_ can you please enlighten us the benefits between this approach vs automated loading of chunks via react importer as described below

https://blog.3sharecorp.com/aem-code-splitting-dynamic-imports-typescript

[#5]

Hi @Shashi_Mulugu 

Thanks for you feedback, there is always a trade-off between the number of JavaScript requests and the size of the JavaScript files being loaded.

It depends on how granularly we divide the JS files. Splitting them into smaller chunks can help reduce initial load size and improve perceived performance, but it may also increase the number of requests—especially if multiple components are authored on the same page, even though only a few might be used.

Alternatively, we can logically group multiple component JS files into a shared module. While this may result in a larger overall file size, it can reduce the number of HTTP requests, which is beneficial in certain scenarios.

Additionally, when using micro-frontend components (especially from third parties), leveraging the page properties approach provides flexibility to dynamically include and reorder client libraries based on the components being used on the page.

In one of our project business owner has flexiblity to deploy clientlibs of new (future micro-frontent) component and add to the page.

Ultimately, the right strategy depends on the specific use case and project requirements.

Thanks,