The GA insertion code that Google gives you to put on your site does a couple of bad things: First, it uses document.write, and second, it loads ga.js directly, which blocks browsers from doing any page rendering or downloading of other page components (images, scripts, stylesheets) during the whole time it takes ga.js to download and execute. In other words, Google Analytics makes your pages load slower!

Using Steve’s best practices, I’ve coded up a better version that does DOM insertion of the script tag and uses the “script onload” technique to initialize the tracker, so that it doesn’t block I/O, and you can inline it anywhere on the page or even load it from an external file. You can choose to lazy-load GA whenever you want — for instance, even after window.onload fires — so that it’s totally asynchronous and doesn’t interfere with page rendering at all.

If you’ve got no idea who Steve Souders is (former front-end optimization guru at Yahoo, and now at Google) or what I’m talking about, I strongly recommend you check out Steve’s book, High Performance Web Sites, and its 14 rules for high-performance sites, which are also summarized on Steve’s site and Yahoo’s Exceptional Performance blog. Steve is currently working on a follow-up book with 10 (so far) new rules, which you can get a sneak peak at by watching this talk on the first three and the March 5 talk on the next three (skip to 39:00 to see him bring up GA). Steve also gave a talk at SXSW (slides) yesterday.

The code

Here’s the Google Analytics insertion code that I put together from Steve’s examples — it’s pretty simple, really. Instead of the code Google tells you to use, you can just copy-paste this instead. You can use it inline, or load it from an external .js file:

(Updated 3/27 per thread)

/*
Inserts GA using DOM insertion of <script> tag and "script onload" method to
initialize the pageTracker object. Prevents GA insertion from blocking I/O!

As suggested in Steve Souder's talk. See:
http://google-code-updates.blogspot.com/2009/03/steve-souders-lifes-too-short-write.html
*/

/* acct is GA account number, i.e. "UA-5555555-1" */
function gaSSDSLoad (acct) {
  var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www."),
      pageTracker,
      s;
  s = document.createElement('script');
  s.src = gaJsHost + 'google-analytics.com/ga.js';
  s.type = 'text/javascript';
  s.onloadDone = false;
  function init () {
    pageTracker = _gat._getTracker(acct);
    pageTracker._trackPageview();
  }
  s.onload = function () {
    s.onloadDone = true;
    init();
  };
  s.onreadystatechange = function() {
    if (('loaded' === s.readyState || 'complete' === s.readyState) && !s.onloadDone) {
      s.onloadDone = true;
      init();
    }
  };
  document.getElementsByTagName('head')[0].appendChild(s);
}

/* and run it */
gaSSDSLoad("UA-5555555-1");

Be sure to use your own tracking code in place of “UA-5555555-1.”

Other things to consider

Using code like this means you could choose to load the GA tracker higher up in your pages, with less of a penalty versus Google’s insertion code, which causes serious blocking if it isn’t at the very bottom just before </body>. It’s still best to load GA last unless you really want to count every pageview possible.

You could also modify the last line of my example so that gaSSDSLoad() isn’t triggered until after window.onload (I didn’t do this in my example, because I wanted it to be a drop-in replacement for Google’s code). That way, GA doesn’t even start downloading or executing until after your page is displayed. For instance:

window.onload = function () { gaSSDSLoad("UA-5555555-1"); };

If you’re using Dojo, you might want to take a look at this Dojo module (mentioned by Steve in his talk), which also lazy-loads GA. My version is different in that (1) it’s standalone and doesn’t require Dojo and (2) it uses the “script onload” method to detect when ga.js has finished downloading (as Steve suggested), instead of polling with a timer. That means it does a slightly better job of firing _gat._getTracker() as soon as ga.js is loaded, compared to the Dojo version.

In his talk, Steve said he hoped the Dojo folks would incorporate his suggestions and improve their version. That’s all well and good, but considering where Steve works, let’s hope Google takes his suggestions! (Otherwise, the irony of “Google is the new Yahoo” will be just too much.)

I’ve been running my version for a few days and haven’t noticed any problems (no traffic drop-offs from any browsers/user agents), but no guarantees of course. Please let me know if you notice any bugs or have suggestions! (First person to tell me they already wrote this exact thing 6 months ago gets a special prize. :) )

If you’re familiar with PNG optimization, then you know about programs like advpng, optipng and pngout that optimize and recompress PNG files, making them much smaller than the likes of Photoshop can. My shell script combines all three of these utilities to achieve minimum file size, while hiding their command-line syntax and adding the ability to recursively process entire directory trees.

And, it works with JPEGs, too! It uses jpegtran (included with libjpeg) and another small utility I’ve included to optimize and strip all metadata from JPEG files. Since my script searches directories recursively, all you need to do is type, say, imgopt myproj/htdocs and it’ll take care of your entire website.

All compression is lossless, which means no pixels are changed and no information is lost, the files just get smaller — chances are your layout can shrink by as much as 50%, which is like getting free bandwidth, and it means your site will snap into place that much faster for users.

Read on for:

• How to use
• What it does exactly, and why you should care
• In action: How much can we optimize Reddit?

How to use: the quick and dirty

imgopt is a command-line bash shell script, so it’ll run on *nix systems like Mac OS X, Linux, BSD, and Windows running cygwin. I’ve been running it on OS X and Linux (both running bash 2.05), but please let me know if you run into any problems on your platform.

The current version is 0.1.2, released on 2009-04-02 (see changelog for details). This post has been updated to reflect the current version, but some comments (especially those regarding bugs) are about prior releases. New bug reports and feature requests in the comments are welcome!

Download imgopt-0.1.2.tar.gz and check out the included README. Basically, you just copy the imgopt script into your path and download and install all the helper programs if you don’t have them already.

Then you can use imgopt to optimize any combination of files, directories and wildcards in one fell swoop. Examples:

$ imgopt A30.jpg
A30.jpg reduced 40 bytes to 1327 bytes

$ imgopt under60.jpg files/*png
under60.jpg reduced 36559 bytes to 49510 bytes
files/A11.png reduced 130 bytes to 669 bytes
files/A256.png reduced 55 bytes to 2106 bytes

# It is totally fine to run imgopt on the same file more than once, since it checks
# and only overwrites files when they have been reduced in size.
$ imgopt *
A30.jpg unchanged at 1327 bytes
A60.jpg reduced 36 bytes to 2119 bytes
files/A11.png unchanged at 669 bytes
files/A256.png unchanged at 2106 bytes
under50.jpg reduced 48 bytes to 18499 bytes
under60.jpg unchanged at 49510 bytes

Really, that’s all you need to know. Keep reading only if you’re curious or have time to kill.

What it does and why you should care

If you’re a website builder, hopefully you already understand the value of keeping website graphics as small as possible — even though it’s 2009 and most of us have megabit connections at home, each byte saved multiplied by every website visitor adds up to a huge reduction in bandwidth and server load, and a faster experience for users. (See: rules for exceptional performance)

Hopefully, your image workflow looks like this. First, you know to sprite your images, especially those with shared color palettes, to minimize total file size and reduce HTTP request overhead. And you are a total expert at Photoshop or Illustrator’s “Save for Web” feature — you know when to save graphics as JPEG (continuous-tone images like photos) and when to use indexed-color PNG (line art, so probably most of the images in your website’s theme). You know a few of the manual color palette reduction tricks (like deleting colors with R/G/B values all > 250, which reduces palette size and increases edge sharpness of type), so your PNGs only have 13 colors when that’s all they need, and not 256 just because that’s the default setting of some wizard thingy used by children and former print designers.

My imgopt script steps in at this point and further optimizes all the files that Photoshop (or whatever your graphics program is) spits out. Unfortunately, typical web graphics production software doesn’t really compress image data as much as it could — it doesn’t take the CPU time to really optimize the way the image data is ordered (because that would take too long), it inserts gamma and empty metadata structure that’s wasted on web layout graphics (yes, even in “Save for Web” mode), and, last but probably most important, uses an inferior zip compression algorithm.

One warning: My script strips all metadata (i.e. EXIF and JFIF) and gamma channels (which you should be removing for web use anyway; otherwise people running IE or Safari will complain about the color in your PNGs being “off”), so if you have image files with metadata, color profiles, masks or channels you want to keep, definitely make backup copies before optimizing!

I’ve commented the script and made it easy for you to go in and customize the helper programs I’m using and the parameters they’re passed. I’ve chosen options that minimize file size, so you could, for instance, make things run faster by choosing less compression, or you could opt to preserve some metadata, like photo credit information.

Here’s what it’s doing, to PNG and JPEG files, respectively …

PNG

My script piggybacks on the excellent work done by optipng, advpng and pngout. Now, I could go into a long explanation about how one of these (pngout) is good because it has a proprietary deflate algorithm that’s superior to zlib, while another is great at optimizing IDAT order (optipng), but the bottom line is that running all three of these utilities on your PNG files will produce smaller files than any one of them separately.

Very occasionally, you’ll be able to get a few more bytes of compression on PNGs just by running files through imgopt twice. So, feel free to try this and make it part of your routine if you like. Since it’s 2x the execution time to run the program twice, and the savings are very small, I elected not to just have imgopt do this on its own (and it’s so easy to just hit up arrow to run the command again). The reason a second pass occasionally works is related to the order the utilities are run in — sometimes a file, once deflated by pngout, can then be further optimized on a second pass thru optipng — and just doing a second run of the whole script is the easiest way to take care of any and all interaction cases like these. (FYI, in no instance have I ever found a third pass to do any good.)

JPEG

Here, the story is simpler: imgopt uses jpegtran (probably already on your system, since it’s part of libjpeg) to optimize the Huffman table and strip color profiles, EXIF data and other metadata. Second, it uses a small utility called jfifremove to remove JFIF metadata (jpegtran leaves at least a minimal 18-byte JFIF segment in place).

Results will depend mostly on how much metadata there is to strip from your images. If you’re running imgopt on files produced by Photoshop’s “Save for Web,” the savings may only be a few dozen bytes. Whereas, running it on random photos uploaded by users, files produced by Photoshop’s regular “Save” command or files straight from your digital camera will easily save 10-30K or more.

A word again about lossy compression vs. lossless. JPEG is a lossy format — most of the benefit of JPEG compression comes when you choose a compression level (of course it is more complicated than that and there are some techniques you can use to get better control than what Photoshop provides, but I digress), and ultimately that’s what’s going to make the biggest difference to the final sizes of your JPEG files. My script and jpegtran are lossless and do not decode/recompress the JPEG image, they just optimize the existing JPEG data. Of course, if you want imgopt to automatically recompress JPEGs at a different quality setting, you could easily add that feature to the script by inserting a line before jpegtran that calls something like ImageMagick’s convert, but I’ll leave that to you.

About jfifremove — this is a very simple utility written in C that I found here, debugged and compared against the JFIF standard. So, while I don’t claim authorship, I am the maintainer of the version included with my script. I’ve tested it thoroughly only as it is used in imgopt — i.e., for deleting the JFIF segment from files that already have had all other optional headers stripped by jpegtran. I have not tested it for standalone use (i.e. on files containing color profiles, thumbnails, EXIF data etc.), so I don’t recommend you use it outside my script unless you know what you’re doing. (I suspect it might fail to strip the JFIF segment from a file where the EXIF APP1 precedes the JFIF APP0, but at least do nothing destructive … but I’m only speculating.)

In action: How much can we optimize Reddit?

OK, let’s have some fun and optimize the graphics from a real website. I picked Reddit because it uses very few images, so this won’t take long. :)

Reddit is doing a pretty good job at performance optimization already, because they’re not overusing images, and the images they do use are small with few colors. But, they aren’t spriting their images or reducing colors effectively. Now, I’m not going to rebuild their website for them, but let’s see what happened when I ran imgopt on their homepage’s images, and also when I took another 5 minutes to do basic indexed color reductions on their PNGs. For the autogenerated thumbnail images, it would be unfair to do any manual reductions — but, it turns out they’re making another big mistake by using PNG instead of JPEG for these files. So, for these images, the third column is just a batch convert to JPEG with quality=60 (actually a pretty high setting for small thumbnails) to show what would happen if they fixed this.

So, the site’s main theme graphics shrunk by 50% just using imgopt alone, and another 25% on top of that with just a few minutes’ common-sense color reduction. The autogenerated PNG thumbnails shrunk 20% — or, make them JPEGs and they’re down 70%. Reddit is a pretty graphics-sparse site, so saving 42K per page visitor isn’t too shabby. (Here’s a tarball of the end results, in case anyone from Condé is reading.)

What about a site with a graphics-rich design? I gave the same experiment a whirl on a former top-20 blog that I used to be tech lead for. Naturally, when I was there, the theme images were sprited and optimized and added to a total of maybe a dozen files and 20K — since then, there’s been a redesign and it’s now about 60 files and 150K (including some bad reminders of the dark ages, like sliced images and “blank.gif”). Result of a quick optimization on those files: I got them down to 50K, 1/3 the original size — so you know that with spriting and some sense you could get them down to 10-20 files and 30-40K pretty easily. I sent the result to a buddy, so hopefully the optimized versions will be making an appearance soon.

Still reading? Well, thanks for hanging in there. Now it’s time to go and make your own website go fast!

What’s changed? Well, nothing important. There have been some changes to WP Super Cache that caused parts of my patch not to apply automatically, so the patch is updated and tested against WP Super Cache 0.9. There’s also a tiny cosmetic change to the submit button on the WordPress configuration panel, so that it matches the WordPress 2.7+ backend.

Direct links to the new files:

• WPSCMinify 0.2, my standalone class and patch, which you can install into your existing Super Cache plugin
• wp-super-cache-with-WPSCMin-0.2.tar.gz, which is a complete modded WP Super Cache 0.9 plugin that you can use if you don’t want to fiddle with patches

And FYI

Be aware that recent versions of WP Super Cache fiddle with the advanced-cache.php file in wp-content, which previously you could just symlink to plugins/wp-super-cache/wp-cache-phase1.php (or you could copy the file if you don’t know what a symlink is). Now, instead of a symlink to wp-cache-phase1.php, it’s a PHP script that does a require_once of wp-cache-phase1.php. Whoop-de-do! I’m pretty sure the symlink is more efficient than doing a require in PHP, and it’s definitely annoying to have to copy and edit a file into a place outside the plugin directory, instead of a symlink that you could make once and leave alone forever, but whatever, it’s spaghetti code.

This doesn’t actually have anything to do with my mod, I just thought I’d mention it in case you’re upgrading WP Super Cache like I was — if so, be aware you’re going to have to manually shuffle this file around and edit it to look like this:

<?php
# WP SUPER CACHE 0.8.9.1
require_once( dirname(__FILE__).'/plugins/wp-super-cache/wp-cache-phase1.php' );
?>

Don’t ask me why the dirname(__FILE__).'/plugins/wp-super-cache/ isn’t already in there by default instead of a random placeholder string that you have to fix yourself (or else the plugin dies). Hey, it’s more fun this way!

Poker Copilot is currently the only actively developed poker software for Mac OS X folks like me, since Mac Poker Pro is apparent abandonware and Poker Tracker’s Mac port has been repeatedly postponed. Given that, I can say first of all, without hesitation, that Copilot is absolutely worth a look if you’re on a Mac and not using any analysis software at all (it’s a snap to download and install, and you can use it for 30 days without registering). It works with both PokerStars and Full Tilt Poker (the only two online poker rooms with native Mac software).

Poker Copilot can be used on its own, purely as an analysis tool for your past games. It maintains a database of all the hands you’ve played and calculates a bunch of standard summary statistics (% flops seen, % aggression) that you can use to study your own play and your opponents’, and analyze using both sortable tables and pretty line graphs. But Copilot also offers a HUD (or heads-up display) that overlays your opponents’ stats right on the poker table while you’re playing, which is the main reason I wanted it and the feature I use most. Here’s what the HUD looks like (click to enlarge):

There’s also a short video of the HUD on the Poker Copilot blog. One thing you’ll notice about my screenshot is that the hole cards of the upper-right player are obscured by the HUD, which I found to be super annoying because the hole cards only flash for a second or so. I was about to file a bug/feature report about it, but then I found that Steve’s already fixed it in version 1.62 — and now you can drag and drop the HUD boxes anywhere you want. Awesome!

The HUD works perfectly well for my needs. I’d love it if I could input custom functions for analysis (I’ll say more on this later), and I suppose it would be cool if it integrated note-taking and did some other things Poker Tracker does, although those aren’t a priority for me (I just make notes directly in PokerStars).

One drawback is that when you click on an opponent (either in the HUD or main program), you don’t get nearly the same depth of information you can about yourself, or that programs like Poker Tracker provide. For instance, I’d like to see an opponents’ hand history along with things like position and hole cards, to try to figure out, say, how/why they’re varying their preflop raises. Ideally, from the HUD I’d be able to click an opponent and get a sortable hand-history window with columns like hole cards (if known), preflop action (raise/limp/call/RR/fold/raise+fold to RR etc.), total preflop bet, position, flop action and outcome (folded on turn, lost at showdown to QQ etc.). Minimally, it would be nice to just be able to use the main program’s Hands, Recent Hands and Position views for opponents as well as yourself.

As far as the main program goes, its summary statistics and line charts are pretty slick, as you can see from the video walkthrough on the Poker Copilot homepage. Here’s where I have to be honest and say that I haven’t used the program enough to give a useful critique — part of that is the statistician in me, wary of drawing conclusions from too little data (~1000 hands) or of projecting my own biases or conclusions onto data that could be interpreted in many ways (see the voodoo science of “technical analysis” stock traders, for example). So, I’ll wait until I have something more substantive to offer before critiquing the main program in depth.

In general, though, I will say that I’m initially a bit underwhelmed by the relatively simple aggregate statistics that most poker software (this isn’t unique to Poker Copilot) reports. These stats (VPiP, agression etc.) are fine for making overall judgments about your game (too tight, playing too many hands from the SB, not continuation betting enough), judgments mostly relating to hand selection. But poker is about so much more than picking what hands to throw away — it’s about playing your opponents, not your cards — and often these kinds of aggregate stats can be very similar for both a winning and losing (say, somebody like me who holds on to his KK too long) player. For instance, cbetting to loose players is basically throwing money away (unless you get lucky and draw out), but it’s usually a winning strategy against tight players who see you betting with a K on the board and assume that, if you’re betting, you’ve got a hand with at least another K in it.

Software can’t play the game for you, but it can do a better job of highlighting the most relevant information for you in a given game situation than just aggregate stats, which also have room for improvement (for instance, a statistic to identify a player’s slowplay tendency).

I’m something of a stats nerd, so personally I’d love to be able to plug in my own custom functions (for both analysis in the main program and for use in the HUD). Of course this is probably not a common feature request (and as a programmer I know it’s a lot harder than saying “make it work like Excel” … I’d be fine just using Java but there’s the obvious security/stability issue with letting people execute arbitrary code, and the “right” way of adding a language parser is far from trivial), but I would really love it!

As a programmer, one of the things I really love about Poker Copilot is that it’s a one-man startup project (good on you Steve!). I mean, the author even wrote something about the Listener or Producer/Consumer design pattern on his blog (nerdgasm!). But as such, along with the benefit of very rapid development (new features and improvements all the time), you get drawbacks such as sparse documentation that’s little more than a command reference. Happily, Copilot is looking for a technical writer, so hopefully the documentation will improve. Personally, I’d love to see more use cases and practical examples that explain how to use the stats to change your play and improve your game.

Conclusion

The underpinnings are all there in Poker Copilot for a very solid product, even if it doesn’t yet measure up to Poker Tracker 3’s feature set — if PT3 is Photoshop, then Copilot is iPhoto. It’s well-designed, very easy to install and get rolling with, and at least worth my $49. So, it’s already a viable niche product for us second-class Mac users. Only time will tell if it matures into a competitor to the serious pro software out there.

I did this on my Powerbook, so these directions should work fine on any Mac/Linux/BSD/Unix system.

There is a handy command-line utility for combining MP3 files, mp3wrap. Unfortunately, it doesn’t correct the audio duration tags/headers (so iTunes/iPod will only see the first part of the file), and it clobbers your ID3 tags with its own (so that the file can later be unmerged with mp3split — this is a “feature”). There’s also the easy cat solution (cat 1.mp3 2.mp3 > all.mp3), but it doesn’t correct the duration, either. Maybe you don’t care about ID3 tags, and your playback software doesn’t care about a wrong duration header (some ignore it) — in that case, go away! But if you want to get your MP3 files right or you’re using something like iTunes, which does care, read on.

Instructions

Install mp3wrap, ffmpeg and id3lib if you don’t have them already. On Linux, you’ll likely just use your distro’s package manager to do this in a few seconds. On my Mac, I just installed mp3wrap and id3lib from source (easy “./configure && make && make install”) and used the ffmpeg binary from ffmpegX (since Fink mangled dependencies).

Do this (combines 1.mp3, 2.mp3 and 3.mp3 into all.mp3, and copies ID3 tags from 1.mp3):

mp3wrap tmp.mp3 1.mp3 2.mp3 3.mp3
ffmpeg -i tmp_MP3WRAP.mp3 -acodec copy all.mp3 && rm tmp_MP3WRAP.mp3
id3cp 1.mp3 all.mp3

Here’s what’s happening:

1. mp3wrap merges the files. Unfortunately, it also leaves wrong file duration headers and clobbers any original ID3 tags.
2. ffmpeg fixes the file duration. You could also use something else, like mplayer/mencoder (-oac copy option) here.
3. id3cp copies the ID3 tags from 1.mp3 to all.mp3

Aside: I happen to be transferring domains to Dreamhost, a web hosting company I’ve been using for many years that offers great pro features at good value. If you’re looking to park a bazillion domains, that’s not what they’re really for, but for hosting small- to mid-traffic sites, I totally recommend them. One thing that’s nice is that they anonymize your domain record for free, so your name and address aren’t crawled by a million spiders (many registrars like the aforementioned GoDaddy charge extra for “privacy”). If you’re transferring to a new registrar that’s not Dreamhost, don’t worry, these are generic directions and all about how to transfer away from GoDaddy.

1. Make sure your domain is at least 90 days old

GoDaddy fabulously won’t let you transfer a domain name you just registered. (OK, there are some ICANN regulations at work, too.) Of course, if you’re about saving money, you’ll probably wait until your domain is close to expiring before you transfer it — you’ve already paid your year’s rent.

2. Change your GoDaddy settings and get your auth code

In the GoDaddy Domain Manager, find the domain you want to transfer and click it’s lock icon to unlock it (if it’s already unlocked, you can just click on the domain name to manage the domain). Here’s what I’m talking about (click the screenshot to see it full size):

Now you should be in the domain’s detail screen:

1. Make sure that “Privacy” and “Domain Ownership Protection” are Off and that the domain is unlocked (if you just did this, it will still show up as “Locked” as in the screenshot, but don’t worry, if you just unlocked it, then it’s unlocked).
2. Make sure your email address is correct in the administrative contact, because GoDaddy will be emailing your transfer authorization code (Email!?!?! What is this, 1995? @%&*$#@ GoDaddy!)
3. DNS settings: Chances are, you’re using GoDaddy’s free DNS service, as shown in the screenshot (ns23.domaincontrol.com means GoDaddy). If you’re already using your own or some other 3rd party DNS servers, you don’t need to do anything and can skip to step 4.

   The important thing to know here is that this setting is part of your domain record, and will transfer over to the new registrar (i.e, it won’t automagically switch to your new registrar’s DNS servers, because there’s nothing about being a domain host that says you also provide DNS), so if you are using GoDaddy’s servers you need to change these now, before you transfer the domain! If you’re using GoDaddy’s DNS and you transfer the domain with the record still pointing to ns.domaincontrol.com, then your site will go dark because ns.domaincontrol.com will start telling folks it’s never heard of your domain.

   So, if you’re using GoDaddy’s free DNS service, here’s what you need to do:

   • Easy: If you’ve just got a parked domain or you’re only using the domain name for a website — you only care about example.com and www.example.com (and you’re not using subdomains like mail.example.com for your email) — just change these to your new registrar or DNS host’s nameservers. For Dreamhost, these are ns1.dreamhost.com and ns2.dreamhost.com.
   • Hard: If you do have special DNS records (like mail.example.com or ones you’ve manually created), you need to load these into your new registrar/DNS host before you change the nameservers. Unfortunately, some big registrars like Network Solutions have crappy systems and won’t let you start setting DNS records on a domain until after you’ve transferred the domain — so if you’re in a situation like this you can either half-ass it and just live with a few hours of downtime while you scurry to reinput your DNS records, or you can use a “real” DNS host like UltraDNS or run your own DNS (which you could just do temporarily — just for a few days and then change nameservers to your new registrar’s free DNS once you’re registered with them). Anyway, once you’ve got your special DNS records set up with your new nameservers (or have decided to half-ass it), follow the directions above in “Easy” to update your domain record with the new nameservers.
4. Click “Send by Email” and GoDaddy will email you the transfer authorization code you need to give to your new registrar

3. Transfer the name into your new registrar

Your new domain name registrar’s website will walk you through this. You’ll need to give them the auth code that GoDaddy just sent you.

Once your new registrar has verified the auth code with GoDaddy, it may ask you to confirm the transfer. Dreamhost usually does the verification in a few seconds, then sends you an email with a link you have to click to confirm.

4. Wait (Or, go back to GoDaddy Domain Manager and confirm)

You’re done! After you complete the previous step, GoDaddy will send you an email written by someone barely proficient in English to say that the domain transfer is approved and the domain will automatically transfer over in 5 days.

So, you really don’t have to do anything more at this point, I promise. But if you’re totally OCD, you can go back to GoDaddy’s Domain Manager, select Pending Transfers, check the checkbox next to your name(s) and use the Accept/Decline button to Accept the transfer. Naturally, GoDaddy has intentionally worded this to confuse you, so on the confirmation screen I think you actually have to select “Cancel” as in “Cancel this domain from my GoDaddy account” to “Accept” the transfer. So, just don’t get caught by their trap and accidentally cancel the transfer, or you’ll really feel like an idiot.

Cadbury Ornament Creme Eggs on the shelf at Walgreens

It’s true, the fabulous ornament creme egg of last year is back, and I just picked up a bundle of them for only 39 cents an egg at Walgreens (they were marked at 2/$1), so now my head is floating and my muscles are twitching from all the cremey goodness.

If you only know about the regular, easter-time Cadbury creme egg, never fear, these are 100% the same as the easter eggs — still laid by a bunny in the 1.2-oz. size that Cadbury moved to a couple of years ago, only with a red wrapper instead of the regular one. They aren’t supposed to hang on your tree or any nonsense like that.

I do miss the old, slightly larger size, but you have to figure that the smaller ones are easier on that bunny. And there are plenty of places like Powell’s that import the original-size eggs from the UK and stock them year-round, a valuable service for aspiring diabetics like me, because no matter how many cases of eggs I have stashed in the freezer at easter, I will nom them all by summer.

You know it is only a matter of time before Santa realizes the jig is up, and his lousy presents have been bested by a superior product, the creme egg. He will hand over the sleigh’s reins to the Cadbury xmas bunny, and then Cadbury can turn its attention to taking over some other secondary holiday, like Halloween or Bastille Day.

What does that mean exactly? Well, the most awesome part is that we don’t even know yet. But don’t be surprised to see, say, 1-gigabit wifi that makes 802.11 look like dial-up or wireless HDMI so that the video game or Hulu video you were about to see on your laptop screen shows up on your flat screen TV, too. Imagine the data connection and streaming video on your mobile phone 100 times faster, and imagine not having to go through one of the big 4 wireless carriers to get it!

Übernerds from across the tech-religious landscape (from Cerf to Gates) lobbied on behalf of this change, not to mention our favorite tech-focused public interest groups, like EFF, and it’s been in the works a long time. Happily, this is a decision so obviously in the public interest that even the Bush administration’s FCC made it. Thanks!

In a bizarre twist at the last minute, foes of the proposal brought out a bunch of celebrity sock puppets like Dolly Parton to argue against it, on the basis that all these fancy new wireless gizmos might cause interference for the analog radios used by wireless microphones in stage shows, concerts and megachurches. What??? Are you for serious? I’m sorry, but your ability not to find digital, error-correcting microphones on the shelf at Guitar Center should not block something that literally tens of millions of Americans will be using and benefitting from by the end of next year. It’s seriously like saying we should all give up our microwave ovens because there’s a slim chance Axl Rose might be in our neighborhood one day and in that event our oven might cause a little bit of static on the 20-year-old analog cordless phone he still insists on using! This is why we have actual engineers and technologists informing technology policy, not somebody who (no offense, Dolly) doesn’t know TCP/IP from morse code.

Now we just have to wait until after the analog-to-digital TV switchover in February for all of this luscious spectrum to free up.

What does this mean? Well, it means your HTML (and gzipped HTML) pages can be 5-20% smaller with just a few minutes’ setup. If that sounds good, skip to the install instructions. If you want to hear more blabber first, read on.

What this does, pros and cons

Minify strips unnecessary whitespace and comments to reduce the size of CSS, Javascript and HTML files, most often to shrink and combine multiple CSS and JS files to reduce HTTP connections and save bandwidth, important optimizations for high-performance websites. This is the same longstanding technique that, for instance, Googles uses on its famously simple www.google.com homepage to squeeze out every last byte.

Minify can also use PHP to do on-the-fly compression of CSS/JS (So convenient! But a drag because it touches PHP!) and send HTTP headers to enable aggressive browser-caching of components (Awesome! Especially with an upstream accelerator like Varnish or Squid! But not as useful a technique for HTML, especially with time-sensitive content like on a blog, and where permalinks matter).

HTML only … for now

So what my plugin mod WPSCMinify does, it does only for HTML pages — not for CSS/JS. Why? Because I prefer to pre-Minify these helper files as part of a build process so they’re fast, small and static, instead of being relayed through the big slow PHP interpreter (Minify foresees something like this in current project goal #3). So, if you’re looking for seamless static-served CSS/JS minification with WordPress, sorry. That’s not what my mod does. I suppose I might be persuaded to tackle that in future. :)

If you’re reading this, then hopefully you’re familiar with WP Super Cache. What it does is save complete WordPress pages to the filesystem as both HTML and gzipped HTML, so that the web server can serve them directly and not have to touch PHP or (god forbid) initialize WordPress (authenticated visitors still get dynamic pages).

All my modification does is to run these pages through Minify first, so they wind up a bit smaller. How much smaller? Well, it depends what’s in your pages. In my testing I found the gzipped versions to end up 5-10% smaller, and the plain HTML versions to end up 10-20% smaller. So, we’re not talking miracles here, we’re talking 10%. If your site isn’t under the kind of load where that matters to you then, by all means, adhere to the KISS principle and don’t Minify your HTML.

The tradeoff: file size for CPU

The cost associated here is the CPU used to run Minify through your page the first time it is rendered before it is saved to the filesystem — and Minify is basically just a lot of regex, so this cost isn’t negligible.

Imagine an alternative scenario, with no WP Super Cache: You could implement WordPress+Minify much more simply, in about 3 lines of code — just turn PHP output buffering on at the beginning and end of your WordPress template, and Minify the result. That way all of your pages, even the dynamic ones, would be minified (this is basically what the minify-html plugin does). Sounds great! But it isn’t, because it would be robbing Peter to pay Paul, churning your CPU on every request a lot more than the 10% in bandwidth you’d save.

In my testing, the CPU cost of running Minify on HTML was about 0.05 seconds of execution time on a medium-slow desktop machine running idle, with very little variance (+/- 0.002) due to page size. 1/20th of a second may not sound like much, but that number translated to a busy web server under load (even a powerful one) equals something you don’t want to be doing on every request (render delay due to minification will be 5-10x the transfer time saved). But never fear, it’s perfectly within reason in concert with something like WP Super Cache, where Minify only runs once to generate each static page, and never on dynamic pages.

The whole point is to make things faster for users. We’ve all seen the Yahoo! exceptional performance team’s presentations, with its CEO takeaways that Amazon loses 1% of customers for every 100ms and Google 20% for every 500ms. Must make more faster!

Installation

Updated 3/15/09: This section and all file links are updated for version 0.3 of my mod, which is compatible with WP Super Cache 0.9.1, see changelog. If you’re using version 0.2 (compatible with Super Cache 0.9) without issue, then there’s no reason to move to 0.3 unless you also want to update Super Cache to 0.9.1. For more information on older versions, see below.

Requirement: You must be running PHP5. Minify is written in PHP5, and my class is written in PHP5.

I’ve tried to keep hacking of Super Cache to a bare minimum, so nearly all of my modifications are in a separate class I’ve implemented as a singleton. However, there is a patch that must be applied that adds hooks into Super Cache, to perform the minification at the correct time and to insert an “on/off” control onto the Super Cache admin settings screen.

If this talk of patches makes you nervous and you’d rather just download a tarball, here it is: wp-super-cache-with-WPSCMin-0.3.tar.gz. Just untar it into your WordPress plugins directory (move any existing wp-super-cache directory out of the way first), and you’re done. (Follow the standard Super Cache install instructions if it isn’t already installed.)

Otherwise, I’d recommend you follow these instructions instead — my patch should preserve any of your own custom mods.

1. Download WP Super Cache (if you aren’t already running it) and follow its installation instructions.
2. Download Minify. Unzip and move the min/ directory into the main wp-super-cache directory.
3. Download my mod, WPSCMinify v0.3 and untar. Apply the patch wp-super-cache.diff to the wp-super-cache directory and move WPSCMin.php into that directory.
4. Log into WordPress, go to the Settings/WP Super Cache page, scroll down to the HTML Minify section, and enable!

That’s it! Here’s the shortcut version with commands to paste into your shell:

# WP Super Cache
# (Skip and cd to the wp-super-cache directory if already installed)
# Read http://wordpress.org/extend/plugins/wp-super-cache/installation/
cd [your WordPress install]/wp-content/plugins # OK, from here just paste
wget http://downloads.wordpress.org/plugin/wp-super-cache.0.9.1.zip
unzip wp-super-cache.0.9.1.zip && rm wp-super-cache.0.9.1.zip
cd wp-super-cache

# Minify
mkdir tmp && cd tmp
wget http://minify.googlecode.com/files/minify_2.1.2.zip
unzip minify_2.1.2.zip
mv min ../

# WPSCMinify
wget http://lyncd.com/files/WPSCMin-0.3.tar.gz
tar -xzf WPSCMin-0.3.tar.gz
patch -p1 -d ../ < WPSCMin/wp-super-cache.diff
mv WPSCMin/WPSCMin.php ../

# Clean up
cd ..
rm -fr ./tmp

# Now you just need to log into WordPress and enable!

Versions

With a couple of exceptions (see changelog) the only changes from one version to the next are that they patch against newer versions of WP Super Cache — my code hasn’t changed. Since my patch only makes a few surgical edits, you can always just download the latest version and apply these edits manually.

• 0.3 (current) tested against WP Super Cache 0.9.1 and packaged with Minify 2.1.2. Will not patch against older versions of WP Super Cache.
• 0.2 patches WP Super Cache 0.9 only and packaged with Minify 2.1.1.
• 0.1 patches WP Super Cache 0.8.4 (may also patch similar versions, this is untested) and packaged with Minify 2.1.1.

Suggestions, bug reports

Yes, I know it’s only like 100 lines of code! Still, I welcome any suggestions and bug reports. Just add a comment here.

These pages are compressed and saved once on the server, and then sent many times to user’s browsers. So, what compression level makes the most sense for pre-compressed HTML?

Full disclosure: This whole thing started because I saw that Super Cache is using Level 1 and thought: “Level 1? That’s terrible, no one uses level 1. Everyone knows levels 2-4 are virtually as fast and compress several percentage points better!”

But then I told myself: “Sticks, you are a dumbass, so you are probably wrong. And now you’re even talking to yourself in your avatar name! Better put away the LSD and test it out!”

Whether you use Super Cache or the ugly code hairball that is WordPress doesn’t really matter.

Hopefully you’re familiar with how zlib works, and why you’d want to pre-compress HTML and page components (and not just do it on-the-fly with mod_gzip or mod_deflate). The use case here is also a little special because we’re not talking about gzipping the transport stream on every request (mod_deflate) or truly static components (do “gzip -9,” duh), but HTML pages that are cached on the server for an indeterminate number of requests. In addition, the cache can be invalidated at any time by various actions (i.e. user edits page, visitor posts comment, admin feels like it) regardless of time expiry or number of requests.

Anyway, here’s the data for a sample 5,201-byte page. Using gzip level 1 it compresses to 2,049 bytes, or 61%. But what we’re concerned with here is the marginal improvement and CPU cost of increasing the gzip level:

The test machine is a medium-slow single-CPU desktop box, running idle.

The big takeaway here for the WordPress use case is that the δ millisecond times are all way too small to matter — 1/3 of a millisecond is not significant when WordPress takes 500 ms just to initialize on the same machine!

But a 6% reduction in HTML bandwidth, that is a significant savings.

Conclusion

I’m going to stick with level 6, gzip’s default, in semi-static gzipping applications of this kind. The additional space savings of going to level 9 (0.1% in the table above) equates to only a handful of bytes for a 5K page.

If you’re a WP Super Cache user and want to change the compression level, here’s a patch, or you can edit wp-super-cache/wp-cache-phase2.php yourself:

--- wp-cache-phase2.php-old  2008-11-01 15:26:09.000000000 -0700
+++ wp-cache-phase2.php-new  2008-11-01 15:25:04.000000000 -0700
@@ -236,12 +236,12 @@
    if( $fr2 )
      fputs($fr2, $store . '<!-- super cache -->' );
    if( $gz )
-     fputs($gz, gzencode( $store . '<!-- super cache gz -->', 1, FORCE_GZIP ) );
+     fputs($gz, gzencode( $store . '<!-- super cache gz -->'));
  } else {
    $log = "\n";

    if( $gz || $wp_cache_gzip_encoding ) {
-     $gzdata = gzencode( $buffer . $log . "<!-- Compression = gzip -->", 1, FORCE_GZIP );
+     $gzdata = gzencode( $buffer . $log . "<!-- Compression = gzip -->");
      $gzsize = strlen($gzdata);
    }

(If you don’t want to change to 6, just change the 1 to some other number. And the FORCE_GZIP parameter is both optional and the default, so just leave it off.)