Jim Coefield — 11:25 on 01.04.2010

Spooner’s article is informative, but it leaves some details unknown. He says his method requires LG .htaccess Generator, yet doesn’t go on to specify why, or what the dependency is. And in his last paragraph, he states: “This method isn’t tied specifically to ExpressionEngine. It should work in any content management system.” Which belies his requirement for LG .htaccess Generator.

The final disconnect for me was the GET variables in the link and script tags, and their connection to the Global Variable. Where does the global variable get called or embedded for either CSS_VERSION and JS_VERSION? And how does that bust the cache?

And lastly, Adam tells us to turn on GZIP, then makes the disclaimer “the only ingredient we’re missing to make it perfect is compression.” Um, then why did we turn on GZIP?

Maybe I’ve missed something, but this method is intriguing enough to sort out the details. I’ve been holding my css files externally and individually so as to speed styling changes—I view source on a page, copy it into Dreamweaver, and style the site live. I hold my javascript in Global Variables and embed them in the head, or call the script files there.

But this article gets me to thinking about easier and more efficient ways to accomplish these tasks. Thanks!

Chad Crowell — 17:45 on 01.04.2010

I agree with Jim that the article could spell out a few more details, but the concepts are solid.  As with any technique along these lines, there are lots of correct ways to do it.

Matthew Pennell — 00:09 on 01.05.2010

The main issue I have with this article (aside from the lack of comments on his blog!) are using EE embeds to concatenate CSS and JS files.

Each embed call means another database query - so if you’re combining multiple stylesheets (layout, colour, brand, etc.) and scripts (jQuery, UI, etc.) you might be adding a dozen or more database queries to the initial page load for your users.

Personally I don’t see the need to use EE’s templates for these kind of files, although I like the idea of using global variables for cachebusting. In general, though, I’d recommend Stephen Lewis’ Combinator extension for concatenating, minifying and caching your CSS or JS files.

Erik Reagan — 02:52 on 01.05.2010

I’m with you Matthew. I wanted to leave a very similar comment to yours but was surprised to not find a comment form on his site.

I try to keep my css and javascript as flat files on the server as opposed to EE templates. Minimizing the calls to the DB and the crunch time of the template engine is always a good thing

James — 02:50 on 01.09.2010

Also agree with Matthew… any performance enhancement you get by delivering the assets with one http request will probably be eclipsed by the extra overhead of multiple embed tags.

More importantly though, who can be bothered to manually increment a cache-busting variable every time you make a minor update? Better to let the built-in {stylesheet} tag take care of that automatically.

A third criticism too… I could be wrong on this but I seem to recall reading in a W3C spec that any asset that has a variable appended on the end of the http request should NEVER be cached by the browser. Despite this, AFAIK, all the major browsers disobey that spec, and will successfully cache such requests… still - I’d rather stick to web standards and make a change to the filename, as happens with the {stylesheet} tag.

(Jim Coefield - when Adam mentioned compression he’s talking about front-end compression, not gzip (ie, removing all whitespace and optimising the css and minifying the javascript).