seanpecor - 1:40 pm on Jun 21, 2011 (gmt 0)
This new header entry is made of win.
I've got some reasonably image intensive websites. Some years ago I added support for "parallelization" and I was amazed at the performance boost.
Typically a web page with 20 images (thumbnails, etc) will all be served from a singular domain. Example:
A web browser will only open +/- 4 simultaneous connections to a single domain. Therefore, in the above example, 4 connections will each request +/- 5 files in succession. The time required to retrieve the entire page might be +/- 1.5 seconds.
With support for "parallelization", my example web page references the following files:
In this example, a web browser creates 4 simultaneous connections to each of the 5 domains. The entire web page and it's required images are all downloaded at once. The time required to retrieve the entire page drops from +/- 1.5 seconds to +/- 0.5 seconds. A huge speed improvement.
It is not difficult in a parallel distribution of images to have the same file served from multiple domains:
This is obviously a problem for search engine spiders and - to a lesser extent - webmasters on metered bandwidth. In my example, if I have 3gb of images, the spider potentially downloads 5 copies totaling 15gb.
In my case, I would previously block indexing of my parallelized images via robots.txt files on i1.*, i2.*, etc. This worked fine. However, things have changed. Google's thumbnailing of pages in search plus the new instant preview thing makes blocking less than ideal. My instant preview thumbnails had missing images (anything loaded from i1.*, i2.* etc were just blank rectangles in the thumbnail) and didn't look quite right.
This new "Link:" header is AWESOME. For example, when any of the following images are requested:
The following header can be included in the HTTP Response:
Link: <http://www.blah.com/images/1.jpg>; rel="canonical"
I'm SO fecking excited about this, I'm having nerdgasms. Time was, the Google Page Speed plugin came out and told me how great image parallelization was and how all the cool kids are doing it. So of course I spent a few days and implemented support for it in my network. However, 3-4 weeks later I lost 15% of my traffic because I had effectively lost all of my image search referrals due to the relocation of images. I never regained these referrals. This made me sad. But my web pages were rendering on browsers so much faster that I wasn't willing to go back to the old school framework. I'm hoping that support for this header will get me back some image referrals. Image referrals are mostly empty calories, but they're good for the ego.
If there are any other uber geeks on WebmasterWorld interested in adding support for this header, here are some notes, some of which may be obvious but I'll include them anyway:
1. A lightweight web server (i.e. not Apache) should be used to serve up your static images.
2. I've previously been using thttpd that I modified slightly to support my directory structure. However, I just couldn't get it to support this new "Link:" header w/ additional code without it segmentation faulting all over the place. And I was a pretty good C programmer back in the day.
3. I tried but couldn't get lighttpd to support it. It's fast as hell though. I might try again later.
4. After development and testing in my sandbox, I'm transitioning to Cherokee for image serving. It's code is well written so it was not terribly difficult to sort out where and how to add support for this header. If you want the 6-10 lines of code I added to support my framework (shouldn't be hard to adapt to yours) then PM me.