Feature Wiki

Information about planned and released features

Tabs

Use minify to combine javascript and css

1 Requirements

By using minify, all javascript / css files could be combined automatically into one single file.
http://code.google.com/p/minify/

This could reduce the number of round-trips and therefore speed-up pange load time in general.

1.1 Concept Leifos, 13 Jan 2014

The following text only mentions js files, but is applicable to css as well.
 
The major challenge here is to ensure that productive installations use minified version of javascripts only, if they are up-to-date, and not to rely on developers to always commit original and minified versions in one step (as this is currently the case for the SCORM RTE).
 
This means we need an automatic minification script and a concept that ensures that minified versions are only used, if they are up-to-date.
 
Checking if the minified versions are up-to-date can be done by comparing

  • the current SVN revision number of the installation (ILIAS_SVN_REV)
  • the SVN revision number of the last run of the minification script (JS_BUILD_REV)
The ILIAS templating class would only include the minified versions, if these numbers match, otherwise it would fallback to the non-minified version.
 
How to determine the current SVN revision number of an installation?
 
We cannot rely on a shell-exec solution here (trying to run svn in the background). Better would be an SVN hook that writes the number into a file:
  1. Developer commits a JS file (non-minified version)
  2. Custom SVN Hook script is started
  3. The SVN hook script determines the branch of the committed file. This could be done by searching for the "ilias.php" file in the directory path of the committed file.
  4. Within the branch, the script updates the "include/inc.ilias_version.php" file and sets the SVN revision number ("ILIAS_SVN_REV").
The minification script now:
  1. Determines the current SVN version (by reading it from include/inc.ilias_version.php) and keeps this number (START_REV) before minifying anything.
  2. Runs recursively through the ILIAS files (omitting the data directory) and creates minified version of all files.
  3. A filename script.js results in a minified version script.min.js. In this step ILIAS must ensure that any error in the minification process is noticed by the script. If this cannot be done by getting result codes or checking updated file dates, it may use a separate target file, e.g. script.START_REV.min.js for this purpose.
  4. Some files may be aggregated into one basic javascript file for ILIAS, but the modularization of the files should be kept for others. We would like to avoid one huge js file that contains a lot of code that is only used in single ILIAS components (for example no forum specific code should go to this file). We could achive this by a naming convetion, e.g. these files should start with "ilCore....js".
  5. After finishing the script writes a .php file containing the JS_BUILD_REV (using START_REV)
There are two alternatives where the minification process runs (and we have to decide on one of them, since they are not "mixable"):
  • Somewhere on the ILIAS SVN server, e.g. managed by a CI tool like Jenkins/SVN hook
    • minified files and the file containing the JS_BUILD_REV number must be committed to the SVN
    • problem "update lack": all installations that make an "svn up" during the time the minification script runs, will fallback to the non-minified versions (since they are not up-to-date)
  • on the productive installation itself
    • minified files and the file containing the JS_BUILD_REV number must not be committed to the SVN
    • admins need to run the script after calling svn-up
The "update lack" problem is somthing we need to make the admins aware of. E.g. we could display a message in the setup or in the ILIAS administration section ("Minified JS is not up-to-date. ...").

2 Status

  • Scheduled for: Not scheduled yet (will be set by Jour Fixe)
  • Funding: Required / Partly funded by / Funded by ... (please indicate if you have funding for feature)
  • Maintainer: (will be set by Jour Fixe)
  • Implementation of the feature is done by (company, developer)
  • Contract settled: (fill in "Yes" if a contract is already settled, otherwise "No" )
  • Tested by / status: (name, e-mail), (status information set after implementation)

3 Additional Information

Contact the following persons if you want to know more about this feature, its implementation or funding:

  • Information about concept: (name, e-mail)
  • Information about funding: (name, e-mail)
  • Information about implementation: (name, e-mail)

4 Discussion

JF 21 July 2014: We postpone this topic to an upcoming release. We don't have enough funding/resources to finalize this concept for 4.5.

CK 21 September 2014: IMO Minification should be possible on the productive installation (not somewhere on the ilias server). The advantage is, if the installation has customizations (maybe also affecting JS/CSS) - no complicated toolchain is needed to update the minified versions.
 
I think a cronjob would be perfect for it - because it can be run manually if needed. If some administrator does not care about minification after an update the cronjob would take care of it. Due to the intelligent fallback it would not be a big deal to have the minification happen with some delay. I think the ILIAS setup would be a good place to have some "master"-switch which enables minifcation in general (on by default - but maybe some admin doesn't like it).

CK 22 September 2014: It would be great to mimic the behaviour of Mod Pagespeed: Extend Cache, i.e.

  • Original: <... src="style.css">
  • Replace-by: <... src="style.min.v_.xo4He3gYf.css">
    Where xo4He3gYf just is some Hash-Value of the file content.
This allows for extremely high browser-cache lifetimes for minified files, like
  • HTTP header: Cache-Control:public, max-age=31536000
A change in the original css file will result in a change in the filename (=hash-part) of the cached file and immediately trigger a new transmission.
 
This concept could later also be extended to other resources (like icons) which get published in slow release-cycles but don't need to get minified. However JS/CSS are more important to cache, because they can block rendering of the page (icons don't).

5 Implementation

...

Last edited: 22. Sep 2014, 11:49, Kiegel, Colin [kiegel]