Category Archives: performance

Easter Bunny special: Autoptimize 1.6.0

Not sure if April Fools or the Easter Bunny are to blame, but Autoptimize 1.6.0 just got pushed out the gates.

The main new features:

  • You can now specify which JavaScript should not be Autoptimized. Just add the names (or part of the path) of the scripts in a comma-separated list and that JavaScript-file will remain untouched by Autoptimize.
  • Added support for ETag and LastModified (essentially for a better pagespeed score, as the files were already explicitly marked as cacheable for 1 year).
  • Autoptimizing for logged in users is enabled again.
  • Misc. bug fixes (see changelog)

As always; leave a reply on this post or create a new topic on the support forum if you encounter any problem.

The best WP YouTube Lyte to date!

Today WP YouTube Lyte 1.2.0 got finally pushed out the gates! This new version is beyond any doubt the best version to date, with the following new features:

  • LYTE embeds are now fully responsive
  • automatic inclusion of scheme.org microdata (VideoObject) (also known as “rich snippets”)
  • even better performance (less requests; was 5, now 3)
  • updated to the current YouTube look & feel, see this YouTube video about microdata:
Introduction to Rich Snippets

Watch this video on YouTube or on Easy Youtube.

Although I did go through a small beta-cycle, with feedback from 5 users (thanks guys), I am pretty sure there still are bugs that will rear their ugly head in the following days (some strings haven’t been translated yet, for example). Do contact me, add a comment here or create a post on the wordpress.org forum in case you encounter unexpected behavior!

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 wordpress.org 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 wordpress.org’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.

WordPress’ Twenty Twelve theme: not so fast bro!

tiny twenty twelve thumbnailWordPress 3.5 was released a couple of days ago, one of the new features being a completely new theme. Twenty Twelve, as it is called, is a responsive, html5-based theme which is just clear, simple and beautiful. I like it that much, actually, that after 5 years with Journalist, I’m considering switching to Twenty Twelve for my blog.

But as with all things web (images, social sharing widgets, fonts, themes and plugins/ modules) there’s a potential performance-cost. Some themes by default come with heavy background-images, jquery and jquery-plugins, and a handful of webfonts to download. So let’s look into Twenty Twelve’s performance, shall we?

My tweaked Journalist implementation on my testblog will serve as a baseline:

Switching to an out-of-the-box Twenty Twelve gives:

Wow, that’s pretty sad, no? The reason for this performance-hit; Twenty Twelve comes with Google webfonts, causing 5 downloads (1 CSS file and 4 font-files) totaling over 124KB of webfont-fatness. I’m not a big fan of webfonts, so I dove into the code to disable them and the results all of a sudden are a lot more pleasing:

So I’ll probably look into the creation of a child theme which will be optimized for performance (there’s some CSS and JS minimizing to be done as well, for example) before switching to Twenty Twelve.

[UPDATE 20/12/2012; 2012.FFWD, a high performance Twenty Twelve child theme, is here]

Do background-images lazy-load with display:none?

So, do background-images lazy-load with display:none? I did a quick test by loading this testpage created by Steve Souders on webpagetest.org. These are the results:

Conclusion: don’t rely on setting display:none on background-images to have them lazy load.