Adopting an OSS-orphan: Autoptimize

I’m taking over support for the venerable Autoptimize WordPress plugin. Although I started out using CSS-JS-booster first, I switched to Autoptimize for my JS & CSS aggregating and minimizing pleasure somewhere in 2012, not in the least because it was the only plugin to offer conversion of background-images to data-uri’s. I hadn’t noticed back then that Autoptimize was already pretty old and that the developer announced he didn’t use WordPress any more and that he had lost most motivation. Fast-forward to December, when, while working on a Twenty Twelve child theme, I noticed that Autoptimize messed Twenty Twelve up severely. So I dug in, found some problems and fixed some others while I was at it:

  • leave html5.js be; aggregating it breaks HTML5-support in older IE versions
  • make sure the IE-specific CSS-files are loaded after the normal aggregated CSS
  • ensure both JPG and JPEG files are taken into account for conversion of background-images to data-uri’s
  • correct a bug that resulted in aggregated files not having a hash in them (having one or more autoptimize_.php can break things)
  • stop autoptimizing for logged in users (which broke the WordPress 3.5 admin bar again)

Based on feedback on the WordPress support forums, others were still using Autoptimize as well, needing bug-fixes and support so I contacted Turl a couple of days ago and proposed that I join his one-man team. He agreed, so I’ll be taking over Autoptimize as of now. The first update (1.4.1) with the fixes listed above will be pushed to SVN soon. I’ll provide support on the forums as well and release new bugfix-versions if needed. New features or other major updates however, are not on the roadmap (yet). I wouldn’t want my own children, WP YouTube Lyte and WP Donottrack, to feel neglected, now would I?

2012.FFWD; high performance Twenty Twelve child theme

Twenty Twelve is beautiful but slow, so I created 2012.FFWD. This Twenty Twelve child theme looks pretty much the same as the original, but comes with the following performance-boosting changes under the hood:

  • no webfont downloaded: loading fonts slow sites down, always. Fallback-fonts as defined in Twenty Twelve (Arial, Helvetica, Sans-Serif) are used instead.
  • minimized style.css: the amount of CSS is staggering, even minimized we’re still at 28KB!
  • minimized and inlined navigation.js: the overhead for doing a separate request for small javascript-files is bigger then the increase in filesize when inlining.

And these small changes indeed seem to have a pretty good impact on performance when comparing my previous test with Twenty Twelve with a new one for 2012.FFWD;

  • from 9 to 3 requests
  • from 142KB to 15KB downloaded size
  • loadtime from 2.457s to 0.937s

You can download the child theme here for now, but I might upload it to’s theme repository later.
Before applying 2012.FFWD on my own blog, I had to do some emergency bugfixing in Autoptimize. Autoptimize is the plugin I use to aggregate and minify JS and CSS (including data-uri magic on background images), but it is currently unmaintained. It messed Twenty Twelve (and hence 2012.FFWD) up severely when viewed in IE7 and IE8, aggregating html5.js into a javascript-file loaded at the bottom of the HTML and loading the IE-specific CSS before the aggregated generic CSS. If anyone is interested in my bugfixed version of Autoptimize (there’s some other fixes in there as well), drop me a line.

Dipping below the magical 1 second page load time

A couple of weeks ago I started looking into data-uri’s as a way to further optimize the performance of this personal playground of mine. Testing was easy enough; Autoptimize, the javascript/ css/ html opitimizing plugin I now use in conjunction with WP Super Cache, comes with support for data-uri’s in CSS and switching that option on indeed immediately resulted in less requests being made.
While testing I did find a small bug in Autoptimize (in /wp-content/autoptimize/classes/autoptimizeStyles.php) which caused jpeg images not to be taken into account. The regular expression in the code was ‘jpe?j’, while just below in a switch/case block ‘jpej’ and ‘jpg’ were referenced, resulting in neither ‘.jpg’ nor .’jpeg’ files ever being turned into data-uri’s. While reading the code I also noticed that the upper filesize limit for images to be turned into data-uri’s was set at 5120 bytes, but as base64-encoding does come with overhead, I decided to lower that limit to 2560 bytes.
So I made some minor changes in autoptimizeStyles.php on lines 207 and following:

if($path != false && preg_match('#\.(jpe?g|png|gif|bmp)$#',$path) && file_exists($path) && is_readable($path) && filesize($path) <= 2560) {
   switch(end(explode('.',$path))) {
      case 'jpeg':
         $dataurihead = 'data:image/jpeg;base64,';
      case 'jpg':
         $dataurihead = 'data:image/jpeg;base64,';
      case 'gif':

I also  switched my “subscribe” widget from a paragraph- to a bulleted list-approach with the rss- and mail-icons as background images and defined the adfreeblog and creative commons badges as background-images as well. And then I was ready to test the real impact of using data-uri’s on Behold the results for my current blog homepage (i.e. the one just before this post got published) with and without the use of data-uri’s (but excluding those dog-slow calls to

 No data-uri’sWith data-uri’s
webpagetest results URL
#requests (full page)2619
Bytes in (full page)116KB114KB
Start render (median)0.615s0.634s
Doc Complete time (median)0.969s0.870s
Full page load time (median)1.932s1.332s

Let it be clear that the use of data-uri’s for background-images is not a silver bullet, but if you have images that are on every page of your site and they’re small in file-size, migrating those into your CSS as background-images with data-uri’s can result in an important performance improvement for your site.