It’s been a while since I last had a tutorial up here, so here’s a new one about the
<ttl> tag in RSS 2.0. It’s an optional element that gives to the ‘time to live’ time, in minutes, for the channel in question. It might not sound that interesting, but if you have a very popular RSS feed, it may save you a bit of cash on bandwidth costs.
To quote from the official RSS 2.0 spec:
<ttl>is an optional sub-element of
ttl stands for time to live. It’s a number of minutes that indicates how long a channel can be cached before refreshing from the source. This makes it possible for RSS sources to be managed by a file-sharing network such as Gnutella.
Is that gibberish to you? It didn’t mean much to me until I did some further investigation. If a user has a newsreader that understands the
<ttl> tag, then that newsreader should not let the user poll your feed more often than the time limit you specify. The example given above is ’60’, meaning that a compliant newsreader should only poll your site every 60 minutes, or less frequently (say 120 minutes). If you don’t blog frequently, then by setting this to 180 or 240 (3 and 4 hours respectively), then you may well save on bandwidth usage from people using compliant software.
I’ve set the tag on my own feed to 180 minutes, since (at least at the moment) I’m only posting one or two entries per day – while that still allows a newsreader to poll it 8 times in a day it’s certainly better than have it polled every 15 minutes. Of course, a good web server will return an HTTP 304 ‘Not modified’ response if the file hasn’t changed, but still, if many of your readers use newsreader software, you might just make your bandwidth usage go that bit further.
As for newsclients which support this, I know that FeedDemon supports the TTL tag, though I’m not sure about others.