Making Autoptimize faster

One of the big changes in Autoptimize 2.0 (estimated released between Christmas & New Year) is a significant improvement in the minification speed (30% faster should be no exception). As a quick reminder, this is what Autoptimize did until now;

  1. extract code from HTML & remove original references
  2. aggregate all code into one string
  3. check if a minified version of that string exists in cache
  4. if not in cache;
    1. minify that string
    2. store the result in cache
  5. inject reference to cached autoptimized code in HTML

It is the actual minification in step (4) which can slow Autoptimize down (hence the importance of making sure your cached files are reusable). In Autoptimize 2.0 above logic was changed to improve performance;

  1. extract code from HTML & remove original references
  2. aggregate all unminified code into one string, but only put a reference to already minified files (*min.css and *min.js)
  3. check if a minified version of that string exists in cache
  4. if not in cache;
    1. minify that string
    2. replace references to minified files with (slightly optimized) contents
    3. store the result in cache
  5. inject reference to cached autoptimized code in HTML

As the to-be-minified string is smaller, the JS- & CSS-minifiers have less code to optimize, indeed speeding up the process significantly. Additionally this also reduces the chances of problems with the re-minification of already minified code (e.g. p. So nothing but advantages, right?
Now this was tested rather thoroughly and all known kinks have been ironed out, but If this “injected minified code late”-approach does not work in your context, you can simply disable it by hooking into the API and setting the autoptimize_filter_js_inject_min_late and/ or autoptimize_filter_css_inject_min_late filters to false (use code snippets rather then adding it to your functions.php);

function no_late_inject() {
	return false;

Choosing a CDN in a whim

I had to look into CDN’s some time ago, to find a suitable temporary solution for a problem at work. There are a lot of players in this field, Akamai and Amazon (Cloudfront) being market leaders of some sort, but there’s also Microsoft with their Azure CDN (which we already had some experience with), other big guns such as Rackspace and Level3 and specialized shops such as CacheFly, CDNetworks and NetDNA as well. So how to choose?

Results only relevant for Belgium (and even then …)avg. speed (ms) for 64kBspeed delta % from fastest
microsoft azure132.0109%
amazon cloudfront133.3110%
amazon s3 eu417.3344%
invalid result
575.0 NA474% NA
google appspot668.0551%
voxel nl814.0671%
amazon s3 us932.0768%
voxel ny942.0776%

Well, if you’re in a hurry, you could compare price and features via The info might not always be complete, but it does give you a good first idea and you can always visit the CDN’s proper site for more details, can’t you?
After comparing features & pricing, you really should get an idea of the speed of these CDN’s, of their performance relative to your customers. I found this CDN Speed Test on very useful; it performs a live test of approximately 20 CDN providers, requesting a 64 kilobyte file 10 times for each CDN from within your browser. So if you can get a sample of your customers to perform that test and provide you with the results, you’ll have some very useful information about performance. Together with your overview of features and price, you should be able to make at least a vaguely educated decision, no?
To have an idea about performance for our market (Belgium), I asked some Facebook-friends to provide me with the results of the CDN Speed Test. Most data I received was for Telenet or Skynet/Belgacom, not coincidentally the biggest ISP’s here. You can see the aggregated results in that ugly table on the left (or a couple of paragraphs up, if you’re subscribed to the RSS-feed).
My conclusion: as I was looking for a pay-as-you-go (no obligations, no monthly fee) CDN for static files, with support for Origin-Pull, HTTPS and some administration features (for example to purge the cache and watch nice graphs), MaxCDN fit the picture pretty well. With a great introductory price ($40 for the first Terabyte and even less if you find the coupon code) and performance that is at 113% of the fastest competitor, they seem to have found somewhat of a sweet spot for my specific context.
The only problem; I’ve got to wait for a “GO” from some people higher up the food chain. Maybe I should already implement it on my blog, just for the fun of it?

Firefox 4 beta007: the thunderball we’ve been waiting for

Although the final release of Firefox 4 has been postponed until the beginning of next year, the latest beta-iteration of our little browser-friend is a huge step forwards!
Up until beta6 a number of very nice features had already been added; tabs on top and grouped tabs, a new add-on manager, Firefox sync, lots of HTML5- and CSS3-features, support for the webm video codec, support for WebGL (3D on the canvas), hardware accelerated graphics, …
But despite all of these exiting changes, there was one elephant in the room; javascript speed. Chrome and Safari were miles ahead and even Opera and Microsoft IE9 were boosting important advances in that area. And that is where beta7 makes a huge step forward; Firefox 4 sports a new Javascript-engine and is now in the same league as Chrome and Safari even beating them in some tests and that speed difference is immediately obvious after upgrading from beta6 tot beta7.
So Firefox 4 is getting ready for prime-time; lots of great new features, fast and -in my experience- very stable. Guess it’s time to upgrade my lovely wife’s Firefox 3.6.x to the brand new 4 beta 7! I do hope she’ll find the location of the reload button though …