2 ms·

>> the bandwidth is dominated by the RSS feed > Exceptionally low cost per hit, as opposed to overall bandwidth. I don't understand. I'm telling you that my

>> the bandwidth is dominated by the RSS feed > Exceptionally low cost per hit, as opposed to overall bandwidth. I don't understand. I'm telling you that my RSS file literally dominates my bandwidth usage in GB. > I think in general RSS readers could do a better job of fetching heads and checking whether or not there is a change worth fetching, that would save a tonne of bandwidth. Yah! Agreed. > It should just be a short `<description>` and a link to the main article (which would still allow you to potentially monetize your content or gauge interest more accurately). No, I want people to be able to read it offline. I'm not trying to monetize anything. > Also, bandwidth is just one resource - potentially each call to a page is a database read I have a simple website. The bandwidth is the dominant cost.

bArray 8y ago
>> I think in general RSS readers could do a better job of fetching heads and checking whether or not there is a change worth fetching, that would save a tonne of bandwidth. > Yah! Agreed. You could also reduce the number of `<item>`s you keep in rotation to a more manageable number. >> It should just be a short `<description>` and a link to the main article (which would still allow you to potentially monetize your content or gauge interest more accurately). > No, I want people to be able to read it offline. I'm not trying to monetize anything. It should still be much more lightweight than it's HTML counterpart. Should be almost nothing to it, next to no markup, no styling, no scripts and a highly compressible piece of data. I don't understand how you're racking up massive bandwidth. Can you put some numbers to it: * Bandwidth usage for RSS * Bandwidth usage for webpage * Hits to RSS * Hits to webpage * Links for both