Zooomr Mark III launches with some hiccups

After what seems like a long week of false starts and unfortunate hardware melt downs the new Zooomr launched this weekend. I haven’t logged in yet but I’m looking forward to exploring all the new features Kristopher has been working on.

I do have a bone to pick with them. They are still not caching images properly! Run any Zooomr hosted image through the Cacheability Engine to test it and you’ll get a report like the following:

Expires 1 day from now (Mon, 04 Jun 2007 19:04:14 GMT)
Cache-Control max-age=86400
Last-Modified 2 hr ago (Sun, 03 Jun 2007 17:04:14 GMT) validation returned same object
ETag –
Content-Length 65.4K (66953)
Server lighttpd/1.4.15

It makes no sense for the image to be sent again. Your browser should be allowed to cache the image. Besides the caching issue, the image is still slow to load and it’s only 67k.

Way back in December I asked, Is Zooomr slow for you too? and was heartened when Kristopher Tate said he was working on a fix. Hopefully the fix is part of an as-yet-unreleased part of Mark III. Without it, using Zooomr for image hosting is really not recommended. Please fix the caching. I really want to like Zooomr!

Now, if only Robert would evangelize fixing their image hosting I’d be a happy camper!

Is Zooomr slow for you too?

One of the things stopping me hugging and embracing Zooomr is how slow it is for me to view images off their servers. Take for example the image on this post on Thomas Hawk’s blog. There are two things wrong with it:

  1. It’s 241k, but it downloads on my fast shiny broadband connection like it’s ten times bigger. Brings me back to the good old days of dialup and a modem connection. Remember how that was? Oh, there’s the connection made, first bit of the image, oh oh, a small bit more, half way there, yawn, zzzzzz. I’ve fallen asleep.
  2. It’s not cachable. Every time you reload that page the whole image has to download again. Go check out what the cacheability engine thinks.

    Date Thu, 14 Dec 2006 09:22:30 GMT
    Expires –
    Cache-Control –
    Last-Modified –
    ETag –
    Content-Length 241.9K (247754)
    Server lighttpd/1.4.13

    This object will be considered stale, because it doesn’t have any freshness information assigned. It doesn’t have a validator present.

    Compare that with the image from my previous post:

    Date Thu, 14 Dec 2006 09:24:50 GMT
    Expires –
    Cache-Control –
    Last-Modified 2 min 28 sec ago (Thu, 14 Dec 2006 09:22:22 GMT) validated
    ETag –
    Content-Length 127.2K (130220)
    Server Apache/2.0.52 (Red Hat)

    This object doesn’t have any explicit freshness information set, so a cache may use Last-Modified to determine how fresh it is with an adaptive TTL (at this time, it could be, depending on the adaptive percent used, considered fresh for: 29 sec (20%), 1 min 14 sec (50%), 2 min 28 sec (100%)). It can be validated with Last-Modified. The clock on this Web server appears to be set incorrectly; this can cause problems when calculating freshness.

    Despite the problems reported above the image is cached by my browser and even with a force reload, it loads quicky.

I’m not sure how to fix the first problem except by adding a faster pipe to the servers hosting the data or upgrading the hosting hardware, but the second problem is very easy to fix using eTags and better headers. There are numerous tutorials and even code examples out there. Please, please, please look into it and make your images more cacheable! Your European neighbours will really appreciate it!