According to the tools at web-caching.com, which crawled one URL at my request, because each of these gifs is served with a session id cookie,
http://220.127.116.111/templates/shared/background.gif Date Fri, 26 Sep 2003 08:14:01 GMT Expires - Cache-Control - Last-Modified 24 weeks 6 days ago (Fri, 04 Apr 2003 19:42:40 GMT) validated ETag - Set-Cookie ad_session_id=4040301%2c0%20%7b34%201065168841%2009237CF575A7A017302D2B066F11A9F1D60C2F63%7d; path=/; max-age=604800 Content-Length 0.5K (514) Server AOLserver/3.3.1+ad13
"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: 4 weeks 6 days (20%), 12 weeks 3 days (50%), 24 weeks 6 days (100%)). It can be validated with Last-Modified. This object requests that a Cookie be set; this makes it and other pages affected automatically stale; clients must check them upon every request."
So for each "real page" the server has to go through 24 rounds of db perm checking and session handling chokepoints. And the client's browser can't use the curv-tl.gif in it's cache and has to ask for it anew so it can compare the last modified date.
I'm just guessing, but I suspect the site would be a lot snappier without some of this rigamarole.
One solution is just to set up another webserver (tux?) to serve these images from a different port.
But is there away w/i the OACS to designate a particular directory or set of directories as files that get served up without all the std. OACS goodness?