Partially obsolete - AEM has included support for URL fingerprinting, and the possibility to hook in alternative CSS/JS procesors (and a Google Closure Compiler JS processor) since AEM 6.2. There is still no alternative to YUI for processing CSS, and still the whole integration with modern Node.js-based FE build tools leaves a lot room for improvements.
Aggressive aggregating as much as CSS/JS source files into one (or as view as possible)
But still use logically separated and fine-grained source files that can be activated via ?debugClientLibs mode
Allow merging with "dynamic" CSS/JS as well, that depends on the current content
Separation is only required where it is needed on the client side - e.g. separate conditional CSS/JS for IE8, or insert some scripts in header, some in body foot of the page
Support more modes than "true" in ?debugClientLibs parameter - e.g.
Only JS
Only CSS
Only JS/CSS für Touch UI/Authoring
Only JS/CSS that is not used for Touch UI/Authoring (that means the frontend used on publish side)
Allow providing a pre-minified and pre-aggregated version from the application - instead of letting the HTML Library manager doing this work
The unminified and un-aggreated files are still deployed as well for ?debugClientLibs mode
But modern JS frameworks like require.js/uglifyjs have their own optimizations that are far beyond what YUIcompressor is doing
Using a pre-minified version per JS clientlib and require.js may conflict with the goal to aggregate all clientlib results into on single big file
Support for URL fingerprinting
For the CSS/JS files included in the clientlibs
And for all references to static resources in the clientlibs as well
References from inside the CSS
And references from outside (Sightly Markup or other Sling components) - Either using a API for this, or by using Sling Rewriter features, or both
A solution for asset references in JavaScript code is required as well
This may get in conflict with pre-minified and pre-aggregated CSS/JS files because it is required to rewrite references in CSS/JS as well
Set caching headers - if URL fingerprinting is done right, it can be set to a very long time (e.g. 1 year) for all static assets (not only CSS/JS, but all static resources in clientlib)
These features are not required in the HTML Library manager, but are currently part of CQ implementation
Automatically convert Images in CSS to Data URIs (this is done in the frontend build itself e.g. in the SASS sources, because only the frontend developer knows for which resources this should be applied and to which not)
Integrated LESS compiler - this is not done inside the CQ application, but in grunt tasks outside using SASS or whatever preprocessor is required
HTML Markup Whitespace Stripping
open
Currently only CSS/JS gets minified by the HTML library manager, the Markup generated by the sling components is delivered 1:1 to the client
JSP Scripting seems to support a way of whitespace scripting, Sightly currently not?
Using a filter the HTML markup should be minified before delivering to the client
Whitespace stripping should be configured globally, but optionally switched on and off via an URL parameter like ?debugClientLibs
The Sling JSP Sling Script handler includes an option to automatically strip whitespaces (but it can only globally switched on and off supposedly)
We currently found no such option for Sightly scripting. Using a separate filter for this has the benefit of supporting all script languages. Perhaps we can propose a patch to Sling to refactor this feature out of the JSP Script Handler to a separate Servlet Filter. More research required.
Domain names for delivering content and resources
open - but perhaps not more so relevant nowadays
Allow configuration per site to use different domain names for:
Content
Media Assets
Static resources
Use "cookie-free" domains for static media assets and resources
Keep HTTP/HTTPS scenarios in mind, and scenarios with "mixed content warnings"
Preloading
Think about preloading for further load time optimization
E.g. "guess" what will the user click next, and load it in the background some seconds before he clicks - depending on the UI concept the guessing may be not so difficult, und perhaps there are JS frameworks for this already available as well
Especially usefull where navigation between pages is possible using "swipes" without a user-visible page reload cycle, mimicking the behavior of local native apps
Partially obsolete - AEM has included support for URL fingerprinting, and the possibility to hook in alternative CSS/JS procesors (and a Google Closure Compiler JS processor) since AEM 6.2.
There is still no alternative to YUI for processing CSS, and still the whole integration with modern Node.js-based FE build tools leaves a lot room for improvements.