Firebug's 'cached' label is misleading

It's beyond me how anyone could develop without Firebug; it's like assembling something from Ikea without an allen wrench. On occasion I find myself relying on Firebug a bit to much though, and today was one of those days.

I was troubleshooting a JavaScript heavy Intranet application and the first thing I did was double-check that Apache was using mod_deflate to compress content sent to the browse - it wasn't. I enabled that, albeit sloppily, since I can guarantee the versions of IE in use.

LoadModule deflate_module modules/mod_deflate.so
 
AddOutputFiterByType DEFLATE text/html text/plain text/xml text/css text/javascript application/x-javascript

I browsed to the site in question with Firefox and IE and it was significantly faster on a fresh, uncached load, but for some reason Firebug was only reporting that content was coming from cache on a reload of a page, not on visits to previously visited pages. I'd never dug too deep into the caching settings of Apache, but I did notice that no ETag headers were being sent. Not a problem, it's only one line in my Apache conf file.

FileETag All

No change though. I opened up LiveHTTPHeaders and to my surprise I only saw a single request for the page itself. Reloading without caching enabled showed me all of the requests for my JavaScript, CSS and images. My Apache access_log confirmed both tests, so it was definitely something to do with Firebug. I searched the Firebug Group and found a few posts that provided some insight:

I didn't feel like learning about how to write Firefox extensions, or digging into the Firebug source, but it looks like Firebug updates the Net tab based on a hook to http-on-modify-request whereas LiveHTTPHeaders and TamperData use http-on-examine-response. From the Mozilla Developer Center:

  • http-on-modify-request - Called as a http request is made. The channel is available to allow you to modify headers and such.
  • http-on-examine-response - Called after a response has been received from the webserver. Headers are available on the channel.

According to Adam in this thread, you don't have access to the caching information until onExamineResponse, so it sounds like Firebug updates the Net tab when onModifyRequest is triggered.

In short, you can't trust Firebug's Net tab to accurately tell you if an item was loaded from cache. It sounds like this is a problem with what Firefox sends to an nsiObserver object, but I'd love to have someone confirm that.

CSS Selector Speed tests using SlickSpeed

Jack Slocum - creator of my favorite JavaScript library1 Ext JS - ran some tests using SlickSpeed from the MooTools developers with the latest development release of Ext JS, 1.1 RC1.

I ran a few additional tests with the following configurations:

  • Firefox 2.0.0.4, Safari 3.0.22.522.12: OS X 10.4.10 on a Mac Book Pro 2.33GHz Core 2 Duo, 3GB RAM.
  • Safari 3.0.2.522.13.1: IE 6 on XP, dual-core Opteron 175, 4GB RAM.
  • IE 7: XP, VMWare Workstation 6.0.0.457312, 1 CPU from the dual-core Opteron 175, 512MB RAM
Library IE 7 Firefox 2 Safari 3 (Mac) Safari 3 (Win) IE 6
Ext 183 ms 314 ms 116 ms 64 ms 461 ms
jQuery 362 ms 442 ms 197 ms 160 ms 861 ms
Dojo 427 ms 363 ms 188 ms 191 ms 780 ms
MooTools 838 ms (4 err) 194 ms (2 err) 158 ms (2 err) 128 ms (2 err) 1333 ms
Prototype 1097 ms 198 ms (2 err) 158 ms 88 ms 1674 ms

I didn't count zero results as errors, in retrospect I probably should have.

  1. "Library" doesn't really do it justice, it's a tremendous collection of "JavaScript, Ajax and UI components" [back]
  2. Not really fair, I know, but it still outperformed IE 6 [back]