One of Drupal’s best practices is to break up the site’s CSS and JavaScript into smaller files to make maintenance easier. Along with this, many modules will include their own CSS and JS files, so before long a site may have twenty, thirty, or more CSS and JS files that are downloaded by the visitor in order for the site to look and work correctly.
According to an article by Aaron Hopkins, as referenced in the comments for the drupal_add_css() and drupal_add_js() functions, the more HTTP requests there are for different files the slower the page will load. So, having fewer HTTP requests results in faster page loading. As it has been shown time and time again, visitors are likely to leave a site if it takes too long to load. Therefore, reducing the number of HTTP requests, e.g. reducing the number of CSS and JS files, the visitor satisfaction with a given website will improve thus increasing the likelihood of them sticking around longer.
In the world of website performance, one of the most basic rules, no - one of the golden rules, has been to combine, or “aggregate" the many individual CSS and JS files into smaller bundles to reduce the number of HTTP requests. In practical terms, because there may be different media types used on the page (desktop, print, mobile, screen reader, etc), combining multiple files into one for each media type is a good starting point. This way a page load may end up with a small handful of CSS & JS files being loaded instead of twenty, thirty, or more. This is generally a good thing.
The donut’s cabbage filling
However, there’s a dark side of file aggregation that’s usually overlooked.
The problem is that Drupal’s CSS and JS aggregators are, well, kinda dumb. When it’s deciding to combine all of the files it only considers one page at a time. A site may load twenty CSS files for use on regular desktop screens for the homepage, twenty-five for a detailed page that includes custom maps, twenty-two for a landing page, and so on. On each page it combines all of those into one aggregated file, but as the visitor presumably loads multiple pages they’ll end up downloading multiple copies of the same files over and over again.
In short, Drupal core is overly optimized to reduce the number of HTTP requests on individual pages at the expense of forcing visitors to download far more data than they should need to.
That’s not all folks, there’s more!
Another problem can arise when the site caches are cleared. Each time the CSS or JS files are aggregated for a specific page the system generates a bundle of files with a specific filename. When the site caches are cleared the file is regenerated. Along with generating new files the old files are deleted. It’s this last part that can cause further problems. There can be occasions when the aggregated CSS or JS files can be removed by an admin while anonymous visitors continue to receive a static page that’s trying to load the now-deleted files.
When this happens, once gloriously detailed and typographically beautiful web pages full of perfectly positioned Nyan cat videos are turned into bleak, monochromatic shadows of their former selves, the likes of which one expects from someone discovering Notepad for the first time. Obviously, site visitors who are the customers, managers, vice presidents, board members, and CEOs really don’t like this happening, and because of it they may go elsewhere.
Enter Advanced CSS/JS Aggregation
The Advanced CSS / JS Aggregation module, or simple “AdvAgg” as I like to call it (I’m lazy, it’s less to type), aims to resolve the above problems, along with a few others. For a start, the problem of disappearing files has vanished as the aggregated CSS & JS files are generated on demand based on an internal ID - if the aggregated files happen to be deleted they’re just recreated when needed.
The bigger issue is of how the files are bundled together, and thankfully the module has some nifty logic behind it. Instead of just jumping all CSS files together, AdvAgg instead tries to be somewhat intelligent about how files are lumped together based upon their grouping, the sort order for when they’re added to the page, and when the files were last modified - neat huh! Over time, this can greatly improve the likelihood of file bundles becoming “sticky," not needing to change just as some small theming changes are made.
Add more cheese!
Not to be outdone, AdvAgg includes a few other nifty tricks. First off it provides pluggable methods of compressing each of the CSS and JS bundles to make them even smaller. The fact that the compression systems are pluggable means that when faster and/or better algorithms are found they can be easily added, e.g. in some cases there can be PHP libraries or system commands which can be used that are better than what raw PHP code itself can do. It just takes a little bit of code to add support for the improved method.
Another useful feature of AdvAgg is that it can load some of the common CSS and JS files from a 3rd party CDN. This has the benefit that instead of loading e.g. the jQuery or jQuery UI files off a Drupal site it will load them from e.g. Google’s servers; part of the hope is that the Google-hosted files might have been loaded from another site, so they don’t need to be downloaded again as the browser already has them! Additionally, this ends up being even less code that needs to be downloaded for the site itself, further improving web performance. Once again, this functionality is pluggable, so other modules can have their JS or CSS files loaded from a CDN too, or if a better CDN solution comes along it can be used instead of Google, etc.
Even more cheese!
And that’s not all! There are options for limiting how many CSS selectors are added to individual files to avoid IE bugs, stampede protection to avoid the server being overloaded when generating files, etc.
Any concerns of pedigree should remember that the D6 version of this module has been used very successfully on drupal.org for several years, and I can’t remember the last time I saw those monochromatic Nyan cats (monochromatic druplicons?). Furthermore, every effort is being put towards making the D7 module rock solid so that it can be used on the forthcoming migration of drupal.org on Drupal 7. After two years of development the module finally reached the first Release Candidate on August 2nd with the second not two weeks later, and the final release due within a few weeks, so it’s moving fast!
All told, AdvAgg is an essential module that all sites should use, especially particularly busy ones.
Additional Resources