/
Web Performance Optimization

Web Performance Optimization

Sept 22, 2017

Prio 2 HTML Library Manager and URL Fingerprinting

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

Prio 2 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.

Prio 2 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"

Later 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