Rui CarmoSo, here I was casually looking at this site’s traffic with Firebug, and I noticed that Firefox, for whatever reason, apparently wasn’t caching Yaki’s static content.
This was in the midst of a discussion with Melo regarding using lighttpd as a reverse proxy to boost Snakelets’s ability to deal with large static files, and he was horrified to see (in Firebug) that my site appeared to serve oodles of JavaScript and minute images per each page request. But all is not as it appears to be…
Looking at the HTTP headers displayed by Firebug, it seemed that there were in fact a lot more things going on than there should be – images were apparently requested and retrieved every time, Etag headers seemed to be ignored, etc., etc.
Looking at the wire with good old tcpdump, however, I could see none of it. So I installed LiveHTTPHeaders and had a look at things again, and lo and behold, things were actually being cached – and the LiveHTTPHeaders output matched what I could see on the wire.
Now, I haven’t been the first to notice this, but it’s been a good while since it’s come to light, and some sort of fix or note ought to be present someplace – but it isn’t, so take my advice:
Until Firebug is fixed or gains some sort of menu option to display cached content properly in the network timeline, and if you’re trying to tweak a site for cacheability, don’t rely on Firebug to do so – by all means use it for just about everything else and to get a feel for overall page load times, but get LiveHTTPHeaders too and use that.
Anyway, as an interesting side effect of all this debugging, Yaki has been proven to run snappily on an NSLU2 with 32MB of RAM.
Can’t beat that, I guess. And I haven’t even installed sendfile() support on it yet.