I thought I was going to have to dig into some PHP to set up my newly hatched CloudFront account. Not so (although that would have been kind of fun.) As I should have guessed, the folks who put out Bucket Explorer have already cooked CloudFront support into a beta of Bucket Explorer.

Bucket Explorer, for those of you who don't follow my every movement (which means basically all of you,) is the app that I praised for providing custom header support for Amazon S3.

Bravo guys.

And while I'm at it, bravo to Amazon for putting together a CDN service that even DIY guys like me can afford. Being obsessed with performance like I am, the ability to serve content from geographically opportune locations with no minimum and low rates is officially cool.

As I'm sure you've seen elsewhere, Amazon recently announced plans to offer a Content Delivery Network (CDN) service. As regular readers know, I use Amazon S3 for image hosting, so I'm excited about this development. With the kind of site I run (many images as content and prone to the occasional traffic spike) using an open-ended and incredibly cheap service to host and serve my images is a no-brainer. I've been using it for a while now and the only problem I have with S3 is that it it's a little slow. Don't take my word for it, Dave Cancel did some tests and saw a difference of around 2-300ms between S3 and true CDNs.

I know some folks are thinking "200ms, who cares?" For some you, that might not matter. Thing is, I'm a performance nerd, so to me cutting down a couple hundred milliseconds is pretty damn appealing. My home page averages between 1-1.75 seconds to load so in my case shaving off those milliseconds would make a real difference. Even beyond statistics, the perceived performance improvement I would get for having just the site sprite to load faster would be a real boost.

This is on initial load, by the way. I set far-future expires headers on my images so after the initial load none of this latency matters as we're living in cache-city.

Of course, I have to earn that second page view so every bit counts

That is the one thing I'm curious about- will I still be able to set custom headers as easily as I can now? If so, and assuming the Amazon CDN is as fairly priced as the rest of the Amazon Web Services I'll be one happy camper when this service launches.

As soon as it does I'll take it for a spin and report back…

I don't know how many of these are "breakthroughs," but if you really are getting an A (and even if you're not), you might want to take a look at the following enhancements to squeeze the most out of your site's performance:

| View | Upload your own

Looking at the list, many are already very familiar to me, but there are definitely a couple I'm interested in learning more about- more than a full bullet points in the above slideshare. Hopefully the teaser of "more detail coming soon" in the YDN blog post will come to pass sooner rather than later.

And no, I don't yet score an A, but I do get a 96 for the components I fully control, so I'm more than happy to look to other suggestions (like the ones below that I don't already practice) to get this place running a little quicker.

1. Flush the buffer early [server]
2. Use GET for AJAX requests [server]
3. Post-load components [content]
4. Preload components [content]
5. Reduce the number of DOM elements [content]
6. Split components across domains [content]
7. Minimize the number of iframes [content]
8. No 404s [content]
9. Reduce cookie size [cookie]
10. Use cookie-free domains for components [cookie]
11. Minimize DOM access [javascript]
12. Develop smart event handlers [javascript]
13. Choose over @import [css]
14. Avoid filters [css]
15. Optimize images [images]
16. Optimize CSS sprites [images]
17. Don't scale images in HTML [images]
18. Make favicon.ico small and cacheable [images]
19. Keep components under 25K [mobile]
20. Pack components into a multipart document [mobile]

More at the YDN blog:

Yahoo!'s Latest Performance Breakthroughs

One change, excluding beacons from the score, will boost everyone's grade a little bit. Everyone that uses some sort of 1x1px image based analytics package, that is. Me? My home page gained 4 points (up to an 82 )*

The other important update, to me at least, means that I can fill out the missing companies from the YSlow survey I did a couple of weeks back. There were a few sites that simply wouldn't load the score. That bug appears to be fixed, so the handful of sites that escaped my earlier scrutiny will now go under the lens.

YSlow 0.9.3 Release with Firefox 3 Support (Yahoo! Developer Network blog)

*I also started serving gzipped pages this week, which should have helped the score a little bit. Actually, cached and gzipped, which, scores aside, should speed things up considerably. With this system in place, there's less work done on the server for most requests since all the tough stuff is done once and saved in the cached version and there's significantly less to download because of the compression- my home page saves nearly 10kb, from ~13kb down to 4.6kb. The total page weight of my home page is now down to 52kb.

Faster Rob! Faster!

Got firebug? Load this test page: Simple Style Graffiti Canvas and watch as I load the "previous" and "next" pages with XHR, parse out the image tags in each, adding them to the users cache.

Is there any reason I wouldn't want to do that?

The performance benefit in the browser is a huge reason TO do it.

But what about the flip side?

I'm already thinking about the extra requests that might not be actually used by visitors who don't follow the back and next path? Those could add up maybe. If I implemented this my site would handle an extra 3 php requests per initial page load and then two cached requests and one new request each additional page. But, that doesn't seem like a big deal to me.

Again, am I missing something?

Anything else?