How to make Autoptimize (even) faster

Less blogposts here lately, mostly because I’m doing custom Autoptimize-development for a partner (more on that later) and because I get a lot of support-questions on the wordpress.org support forums (with approx. between 1500-2000 downloads/ weekday that is to be expected). One of the more interesting questions I got there was about Autoptimize being slow when JS optimization was active and what would be the cause of that. The reply is of interest for a larger audience and is equally valid for CSS optimization;

Typically the majority of time spent in Autoptimize is mainly in the actual minification of code that is not minified yet (purely based on filename; if the filename ends in .min.js or -min.js).
So generally speaking, the way to avoid this is;
1. have a page cache to avoid requests triggering autoptimize (as in that case the cached HTML will have links to cached CSS/JS in it)
2. for uncached pages; make sure AO can re-use previously cached CSS/ JS (from another page), in which case no minification needs to be done (for that you will almost always want to NOT aggregate inline JS, as this almost always busts the cache)
3. for uncached CSS/ JS; make sure any minified file is recognizable as such in the filename (e.g. .min.css -min.js), this can lighten the minification-load considerably (I’ll add a filter in the next version of AO so you can tell AO a file is minified even if it does not have that in the name).
So based on this, some tips;
* make sure you’re not aggregating inline JS
* for your own code (CSS/ JS); make sure it is minified and that the filename confirms this. if you can convince the theme’s developer to do so, all the better (esp. the already minified but big wp-content/themes/bridge/js/plugins.js is a waste of precious resources)
* you could try switching to the legacy minifiers (see FAQ) to see if this improves performance
* you can also check if excluding some un-minified files from minification helps performance (e.g. that bridge/js/plugins.js)

5 valuable Cufón tips

cufon test page zoomed in: quality is less what default fonts have to offerCufón is one of the solutions available to force browsers to display a page with non-default fonts. Here are 5 tips for using Cufón, based on real-life experience:

  1. Don’t use Cufón unless you can sleep knowing that at least some of your visitors are bound to run into cufon-specific issues
  2. Be sure to include all characters you might need (e.g. €, é, ç, …) when generating your Cufón font files.
  3. Be sure to enable gzip/ deflate and to implement caching directives on your webserver to somewhat limit that often ridiculous amount of font-data users have to download
  4. Tell Cufón to render using cufon.now() before calling those nasty external javascript-includes (e.g. Google Analytics) to avoid a visible delay between the moment the DOM is loaded and your cufon-javascript applying the new fonts
  5. Try to find a “default” font that comes as close to your Cufón font as possible (in terms of size, weight, …) to limit the visual impact of any Cufón-rendering delay

As for the accompanying image (of a zoomed in Cufón demo page); don’t be surprised if someone tells you your text seems just a little bit less readable, because it will be.

Riding Google’s Wave: tips & tricks

wave on android and iphone as found on flickr (user tekalpha)So you’ve finally received your Google Wave invite, you logged on and now you’re feeling utterly lost and alone? Don’t worry, everyone does at first. Here are some tips & tricks that might help you to surf those waves fearlessly.

  • You can play with the other kids in public waves, just enter “with:public” in the search box, optionally combined with one or more keywords.
  • You can make your own wave public as well:
    • add “public@a.gwave.com” to your contacts (last time I checked pressing the submit-button didn’t work, but hitting ‘enter’ on your keyboard does the trick)
    • add that ‘public’ contact to the wave you want to make publicly accessible
    • optionally add tags to your wave for easy discovery
  • Those public waves sure are great, but there’s always a but!
    • Making an entry public can cause a lot of people to come on by (esp. if you’re waving in English and your wave has content that those darn geeks might search for).
    • And your passers-by automatically have read & write access to all content in your public wave.
  • You can add all sorts of non-human actors to your wave as well. Your can find a non-exhaustive list of such robots and gadgets on http://wave-samples-gallery.appspot.com/. The Wolfram|Alpha robot is particularly fun to interact with; ask a question (between square brackets) and it’ll (try to) answer with a reply in the wave.
  • Anxious to know if there are new replies in your waves but don’t want to keep that memory hog (yep, Wave still eats RAM for breakfast) open all day long? There’s a Firefox plugin for that, which will periodically connect with Wave and display the number of new replies.
  • You can also access Wave on your mobile, it should more or less work on Android-devices and on the iPhone. Just go oto wave.google.com on your handset and fearlessly click through when you’re presented with a warning about browser compatibility.
    • But it seems rather slow, might be too much data being pumped through that 3G+ connection?
    • It does not work entirely on my HTC Hero; the original message in a wave shows, replies don’t. Did HTC somewhat screw up when customizing the stock Android browser?

You can find more great wave tips (with a nice cheat sheet for keyboard shortcuts) on http://lifehacker.com/5376138/google-wave-101. Just one example maybe, which might save you quite some time when you’re participating in a large public wave: press ‘space’ to go to the next unread message.