So how does it work?
This is sent to a special url, along with the type of content we are decoding (js/css), and then our Minify wrapper is called. This wrapper decodes the list of files, and turns it into a format that Minify will understand. It then runs it through Minify, and sets the right output headers (such as content-type), so that in effect this special URL, if you were to view it in your browser, just outputs the optimized JS code. Think of it as a virtual JS script.
Minify also does some other magic here, along with the optimization and gzip compression. By comparing when the data was last changed, vs the date of the data in your browser’s cache, we often find that your browser’s cache is up to date! If this is the case, Minify returns an alternate set of data (setting the 302 Not Modified HTTP status code), along with no actual content for the script. Because of the 302 code, the web browser knows to look in its cache instead, saving even more bandwidth. If the cache is up to date, there is literally no code downloaded. And, of course, if the scripts change on the server side, the timestamps will change so that the browser is out of date, and the scripts reloaded.
Naturally, we do the same for CSS, though we run Minify again with a separate list, as combining CSS and JS is just asking for trouble.
So how much space do I save?
None locally, though there are massive bandwidth improvements – meaning that it’s easier on your pocket (if you pay by usage), plus you and your users spend less time downloading. We performed some tests to see how much data was downloaded when viewing the index page, when not logged in:
- Without optimization: 397.6KB
- With optimization (cold cache): 65.2KB (reduction of 83.6%!)
- With optimization (hot cache): About 0B (reduction of 100%!)
As you can see, these are massive reductions which are bound to help!