No Mod Required

Yeah, Even to You.

I suspect it's because the people that are most vocal about the subject are from places like Google and Yahoo!, but it seems to me that a lot of people think that front end performance really only matters for extremely high traffic sites. When talking about these kind of things with other engineers at conferences and the like I've heard something similar to the following a few times and it left me scratching my head:

"That stuff is for the Googles of the world. We don't really need to focus on that with what we do."

Where "what we do" has been anything from working full-time on a web app to building marketing sites for clients large and small.

Even people who really ought to know better get it wrong. When speaking about the number of files present in a CSS framework (and referencing performance rule #1), a certain CSS guru said something along the lines of "Yahoo! found that at their scale, this kind of thing becomes important. You don't need to worry about it."

Which is simply wrong.* You do need to worry about it. Just because it's Yahoo! and Google that are most vocal about these issues, it doesn't mean that their scale is the factor that makes performance important. What their scale means is that they can have dedicated performance teams and can spend time researching best practices. The benefits of better front end performance are for everyone with a web site.

Why? Well, if you approach it from the correct side of the issue (the one not focused on the size of the messenger), front end performance is really about the smallest web scale possible- the experience for a single user. (Even more importantly, many of the techniques are focused on the vitally important first time user.) While it's true that Google and Yahoo! can save big money in bandwidth by shrinking a heavily used file or two down by a couple of kb, and people with busy machines can save some cycles and connections by serving leaner sites, the real takeaway is NOT the bandwidth, processor or connection savings, it's the user experience gains. With better performance, you improve the overall experience of your site. All things being equal a site that responds more quickly to user commands is going to feel "better" than one that is sluggish.

So, if you speed up your site, people are happier with you, your brand or your service and, as the big boys have shown us, they do more.

Here are some oft-quoted numbers:

• Amazon found that +100 ms increase in response time equaled -1% sales (warning opens Powerpoint)
• Google found that +500ms response time meant a 20% reduction in searches
  

  So, Marissa ran an experiment where Google increased the number of search results to thirty. Traffic and revenue from Google searchers in the experimental group dropped by 20%.

  Ouch. Why? Why, when users had asked for this, did they seem to hate it?

  After a bit of looking, Marissa explained that they found an uncontrolled variable. The page with 10 results took .4 seconds to generate. The page with 30 results took .9 seconds.

  Half a second delay caused a 20% drop in traffic. Half a second delay killed user satisfaction.

• A 30% reduction in file size generated 30% more map requests
  

  The same effect happened with Google Maps. When the company trimmed the 120KB page size down by about 30 percent, the company started getting about 30 percent more map requests. "It was almost proportional. If you make a product faster, you get that back in terms of increased usage," she said.

What's the important takeaway there?

Faster sites mean users do more stuff.

So, whatever stuff you want them to do, be it buy, browse,or blog, they're going to do more of it if you can get them there faster.

And who doesn't want that?

*and he may have misspoke, which is why I'm not outing him

Yes, another CloudFront post. I'm a penny-pinching, performance minded AWS user, what do you expect?

Anyway, I'm a couple of weeks into my CloudFront experiment and while the traffic numbers are still too fresh to offer any insight on what the speed improvement might be doing for my European and Asian bounce rate (I cache everything, so it should really only affect initial page views,) I do have enough data to compare and contrast the absolute speed difference at play here.

Serving my site sprite from the three different locations I get the following results using pingdom's excellent monitoring service:

As you can see CloudFront is a significant relative improvement over the other two servers (by two and three times.)

Without researching it extensively it seems like a pretty good absolute result as well. While the sprite is slightly larger than the Lookery JS file he used to test, CloudFront performs well within the standard that CacheFly and EdgeCast set when Dave Cancel tested a few different CDN options earlier this year. Granted, his research wasn't exhaustive so someone out there might be pushing closer to 100ms for smaller files, but for the price and ease of use, I'll gladly take 134ms.

Anyone know of any broader research into CDN response times? I'd love to see it if you do, so drop it into the comments.

It made quite a splash recently so I'm sure some of you are curious about Amazon's new Content Delivery Network (CDN) service, CloudFront. I know the Amazon Web Services suite of tools can be a little intimidating for non-developers, so this article outline how pretty much any reasonably technical person can get themselves up and running on CloudFront and can start reaping the benefits of geographical optimized content delivery.

This article assumes you already have both an S3 account and a CloudFront account (or at least know how to set each up.)

The Basics

The basic process works like this:

1. Place an object (IMG, FLV, etc) in an S3 bucket and ensure that it's publicly readable
2. Create a CloudFront "distribution" based on that bucket. CloudFront will auto-generate a *.cloudfront.net domain name for you to use to reference your object
3. Link to your object using the domain name an appropriate path (e.g. http://random1234.cloudfront.net/path/to/your/object.jpg)
4. When a user requests the object and Amazon CloudFront chooses the appropriate location from which to serve your object
5. Speed ensues

Bucket Explorer

Bucket Explorer is the preferred solution around these parts. It's fast, easy to use and offers custom headers (which allows performance geeks like myself to set far future expires headers.) It also has a beta version with built-in support for CloudFront.

The only drawback is that it's a commercial product. Actually, for me, that's not a drawback as I'm happy to pay for good software. I know some people are less apt to use a commercial package for something like this, so I mention it.

That said, this is definitely the best solution, so at the very least set yourself up with a trial version and give it a go.

How to Set Up CloudFront With Bucket Explorer

1. Click Bucket : Create

   

2. Name your bucket. If you plan on using your bucket as with a CNAME, then you must name the bucket exactly as the CNAME record (e.g., media.example.com)

   

3. Make it public (people have to be able to access it) by setting the All Users checkbox

   

4. Upload your files. If needed, follow the instructions here for uploading files with far futures expires headers.
5. Make a distribution by clicking on the distribution button

   

   That opens up your distribution list.

6. Once there click new.

   

7. Select your recently created bucket

   

8. Click Create, Bucket Explorer will go about it's business, creating your distribution. This might take a few minutes.

   You'll see it in the list as "InProgress."

   

9. Even if it's InProgress, selecting it and clicking update will allow you to complete the final step, which is getting the CloudFront URL you'll need to access your files. Simply select the domain name and use your system's copy command to get the domain into you clipboard.

   

10. Now, all you have to do is reference the newly created domain name and the needed file path to access your assets.

S3 Firefox Organizer

S3 Firefox Organizer is a free, Firefox add-on that allows you to manage S3 buckets and files from the comfort of a Firefox tab. Very easy to use and priced right (although I encourage donations if you find it useful,) the only thing holding back S3 Firefox Organizer from being my main S3 tool is the lack of a few advanced features (far futures expires headers being a big one.) One advanced feature that they do have is the ability to manage CloudFront distributions.

1. In your remote window, right click and select Create Directory or click on the Create Directory button.

   

2. Give it a name. Once again remember to match the bucket name to the name of the domain if you're planning on using a CNAME with this bucket.

   

3. Right click on your newly created bucket and select Manage Distributions
   
4. This will bring up the distributions dialog. click Create Distribution:
   
5. It'll create the distribution. Refresh the list below and you'll be able to select your newly created distribution. Click Copy to get the URL onto your clipboard and you're ready to start using your new distribution.

   

And there you have it, two easy ways to get up and running with Amazon CloudFront. If you run into any problems leave a comment and I'll try to clear up any issues you might have. I can't guarantee anything (including that the above tutorial won't turn your site into a smoking wreck ), but I'm always keen to help.

I mess around with this site a lot. This week, in particular, has been interesting. In the past week I:

• Moved my interface images over to CloudFront, Amazon's new Content Delivery Network (CDN.) I'm especially hoping this will increase initial page view performance for my site in Europe and Asia, where I've always had some lag. I'll be monitoring my bounce rate to see if that's the case. The initial results are positive (an overall reduction of 1-2% in my bounce rate over the past week), but the numbers are still too small to really draw any conclusions.
• Took advantage of Firefox's Link Prefetching to speed up all those next gallery links. I tested it out and between link prefetching and all the caching I do, browsing gallery pages in Firefox 2+ is screaming fast.
• Added some copy and rewrote some of the text/labels right here on the blog. Spurred on by the blog chapter in Designing the Obvious, I decided to implement a couple of his recommendations. Within 20 minutes of having read the chapter, I'd changed the header for the comment section, added the little descriptive blurb below it and changed the label for my RSS icon from "FEED" to "Subscribe."

  Small changes all, but maybe they'll improve the experience for folks.

  Or maybe not.

  And if they don't? I'll try something else

This kind of ongoing enhancement is core to the way I approach web design/development. I often speak of sites as being living organisms and this is the kind of thing I do to keep mine growing/evolving in positive ways.

Fun times.

I was reading John Resig's Browser Page Load Performance post earlier today and followed up from there on the concept of Link prefetching. Currently supported by Firefox 2+, Link prefetching is a browser based mechanism for fetching "future" content. Considering I wrote (and ultimately scrapped*) similar functionality for my gallery pages, I was obviously intrigued.

In its basic version it looks like this:

<link rel="prefetch" href="/images/big.jpeg">

With the href being the target content and the rel attribute triggering the prefetching mechanism. Pretty simple. I've already implemented it here on my gallery pages.

One thing I would like to see, and this is hinted at on the above linked Mozilla FAQ page, is prefetching performed automatically on anchor (<a>) tags with rel attribute set appropriately. In my mind that would be any anchor with a rel attribute of next, but the prefetch value would be fine as well. Personally, if that were supported I wouldn't have any (or very little) work to do to take advantage of this feature and in a general sense it would build on what people are already doing using prev, next and toc rel attributes on gallery links.

*it was scrapped because I hated the idea of forcing bandwidth usage on people with metered accounts. Since this is a browser based mechanism, it should be relatively painless for people in that situation to control whether or not content is prefetched.

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…

Dear Internet, anyone out there have any experience with lightweight web servers that they'd like to share?

We're (meaning Cramah!) looking to set up an asset server to serve static assets like css, javascript, images, flash (destined for progressive downloads) and mp3s. We want to offload that kind of stuff from app servers as a general architecture approach going forward (my obsession with performance is spreading ) Since it's (at some level) my baby and is something I'm generally interested in, I've taken a little time and starting looking into what the set-up should entail. I've done a little bit of research and it looks like the names I already know are the names that people are using:

• lighttpd
• nginx
• LiteSpeed

Based on what I knew when I started, what I've read since, and a recommendation from a co-worker, lighttpd seems to be the way to go. Thing is, I don't want to jump into anything before asking you, the Internet, if there's anything I should know about it (or the other two) before heading down that path.

So… anyone out there using this stuff and feel like sharing an anecdote or two? Is there some other candidate I'm missing?

All comments are welcome

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 1×1px 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!