Blog

While working on some front end optimizations for a venture of mine I went on the lookout for a better bundling strategy then that provided with the default rails stack.

While rails does provide bundling of CSS and Javascript it does not support minification. Which in my opinion is a huge win for site performance, and a less needed feature for this particular project; but a nice to have is the concept of bundles. Specific sets of pages may need the same 3 Javascript files etc. So it would be nice to just keep track of these common bundles and include them as necessary in my layouts and views.

Enter asset_packager. asset_packager is a project created by Scott Becker. Which does exactly what I was looking for. You configure your bundles and the order in which files are placed in the bundle through an easy to configure yml file. And you just run a rake task when deploying to create the bundles. I won’t go into detail here about how to use it; but feel free to follow the link to the project page here http://synthesis.sbecker.net/pages/asset_packager

One thing that I did notice while looking into this project was that it uses JSMIN ported to ruby. I am personally a fan of YUI Compressor so I opted to go with a fork of asset_packager by Erik Andrejko found here http://github.com/eandrejko/asset_packager/tree/master which uses YUI Compressor for its minification process.

On to the good stuff.

As happy as I was with what I had found, it seemed to still have some inherent problems.

1. When bundling CSS if you are using relative paths, when they get bundled into a file in your base directory your paths will no longer work, so you need to manually modify your CSS files to have absolute paths to your images. Which can often be part of plugin or library that you are making use of like jQuery UI.
2. If you have implemented far forward expiration dates like you should on your media (my next post will talk about this), your CSS files do not have a cache buster to ensure that when your media is updated the cache is expired
3. Rails has the concept of an asset_host, it creates a key based on your asset name which will always map to the same domain, and spread the media across asset_hosts by supplying a configuration option in your environment file to help overcome the limit of connections per domain. Well if you design sites the way I do, I have very minimal links to media inside my markup, its all contained in the CSS, so I make very little use of the image_tag helper and therefore little use of the rotating asset_hosts

I have created a fork of Erik Andrejko’s repository for asset_packager and implemented solutions for all of the problems I found above.

During the bundling process it will now determine absolute paths of your assets and use those in the bundled file only. Leaving your originals untouched.

Paths to images are now appended with a cache buster using the same approach as rails, determining the last modified date and appending a timestamp to the url. Now when running your rake task for bundling you can rest assured that new versions of your media will be seen if you have set far forward expiration dates.

If the environment you are running the rake task against has an asset_host set for rails to use asset_packager will pick up on it the same way rails does replacing %d with 0-3, the same asset will always get the same hostname to ensure caching works properly.

While my fork with these changes is of Erik Andrejko’s repository none of the changes are specific to this fork. They can easily be added to Scott Becker’s original implementation. The only changes were the addition of a single method, and calls to it from within the bundle method, as well as a change to the rakefile to include the environment so that the method would have access to the rails configuration.

my github repo can be found here: http://github.com/erikstmartin/asset_packager/tree

I’m open to any comments or questions you may have. Let me know if you find any problems or if you just want to tell me how useful you have found the changes.

update: Erik Andrejko is quick! It appears my changes have already been merged into his branch