Seems like a minor payload to be delivered. I guess it makes a difference in the performance/UX of the reader itself.
I've started working on my own "power user" RSS reader that lets you weight the keywords you're interested in (so an article that hits important keywords but is older could be displayed above an article that's newer) but it's still closer to a proof-of-concept than a complete app.
with arms wide open
under the RSS feed
welcome to this place
i'll show you XMLOriginally that would have been mutt, later my own client, and later still I switched to gsuite.
I did add support for excluding entries/posts based on title, body, regular expression, and similar, but at the end of the day I just fetch all feed entries and save them as emails. The later processing can be done by any client and that's pretty flexible. There's very little custom processing required in the RSS-processing itself.
At the time of writing this, the HN rss feed is 12kb. That'd mean you'd need 10Mbps upload to handle 100s of requests to the rss feed per second.
(Again, not saying you shouldn't optimize this, just questioning how big a problem it is).
One podcaster halved its bandwidth bill overnight getting just one of these fixed, see "A saving bandwidth special!":
RSS/podcast feed polling is a load for which Apple/Amazon/Spotify/Podbean are currently wasting 99%+ of the network and CPU bandwidth for, and thus money and carbon emissions. Many of the creators have limited budgets, and reaching Net Zero is not going to happen by ignoring really easy cases such as this, albeit small in the overall scheme of things.
I have a home-brew solution for pulling feeds and will be cross reference with your info. One small impact!