为什么应该提高RSS刷新间隔

一些博客的 feed 不输出全文，哪怕可以用 css 来获取全文，也很麻烦。“没有全文的feed没有灵魂”失去了全文体验， rss 的意义就失去了一半。

博客只输出最近的十几篇文章，但我想看看更多早前的文章，又懒得主动打开网站去翻，我可能就没机会看到之前的博文。毕竟它不输出以前的文章，我哪怕知道这个博客以前的文章肯定不在 feed 里，但我连这些文章的标题都不知道，主动上博客 web 浏览的冲动也就少了几分。

且当博客网站突然间消失在互联网时(比如科学松鼠会关站、以及很多个人博客不打招呼删库跑路)，我并没有把它的全部文章保存到本地。虽然那些文章我不一定看，但是没有保存下来的话我会有种像丢了东西一样的“损失”感和淡淡的悲伤。（为这些站长 R.I.P 几秒😥）

如果你每5分钟刷新一次 feed ，对应站点的 feed 大小为 500KB。

5分钟一次刷新不极端，还挺普遍。很多人设置的刷新频率都是软件能提供多短，就设置多短，而telegram的rssbot更是只能5分钟刷新一次，还不能改🤒

那么一个月你将使用60min×24hour×30day÷5min×0.5MB=4.32GB的流量用于刷新该rss。你用流量不要紧，但如果博主使用了付费 cdn 来优化网站访问体验，那博主就需要为cdn支付流量费用。

以又拍云CDN的价格为例

So, 你频繁的rss更新并不会像频繁访问 web 那样给网站带来大量 pv (浏览量)，让博主在浏览后台时收获快乐。

Just like：(这么多浏览量，开心开心😜；哇，这个来自火星的访客把我全部文章都看了，开心开心😝）。

况且，RSS 看文章，除非去评论留言，你不会再去访问博主的网站。

这就意味着博主的cdn账单可能就得为了你而每月增加几块钱的费用。 听上去不多对吧？

但博主本可以用这几块钱 CDN 费，用在 web 的访问上，给上千个访客更好的 web 体验。

费用是持续产生的，除非你不再订阅对应博客。

这样博主就在为你能仅仅早几十分钟收到最新文章而被动付费。

而对于独立播客 (podcast)，他们的情况还好，如果是订阅量上万的热门播客，他们的流量大，所以可以与 CDN 厂商谈拢到几分钱每GB的 CDN 流量价格。但广大中小型博主就没这么幸运了，博客流量总量不大，根本没资格与 CDN 厂商谈条件（这里赞扬一下又拍和七牛，免费的“联盟”计划对于博主们算是福利了）。

如果各位rss使用者大部分没有意识到这个问题，受伤的将会是你所喜欢的博客和播客本身。

当然，我知道很多博客使用免费的无限流量的 Cloudflare CDN，对于这类博客的 feed 确实可以想怎么更新就怎么更新。但是 cdn 有缓存啊，你作为用户，更新再频繁，cdn 不回源拉新版文件，你也没有办法不是。😂

RSS面向内容而不是面向即时

这有必要吗？博主每个月就产出那几篇文章，无论你是1秒刷新一次，还是一天刷新一次，你一个月其实就只能看到这些个博文。更不用说绝大多说rss爱好者的未读计数都上百上千了。

虽然博客是时间流式的web平台，但是它不是Twitter、微博这样的社会性社交网络，它不是朋友圈或QQ空间。 你用上了 rss ，但你的心没有完全静下来，还在被IM(即时通讯)和社交网络的即时理念所影响。我知道有人用rss来看Twitter，我知道有 PubSubHubbub 技术提高rss本身的即时性和通达性。 但是我想引用这篇文章的一段话：

“需要注意的是，所谓的「实时」只是相对的，通知的发送不可能快过 RSS 服务抓取到订阅源更新的时间，而我们已经知道后者往往存在不可避免的时间差。因此，实时推送功能的作用只是提醒我们不要错过关心的内容；要真正做到分钟级的先知先觉，当今媒体生态下恐怕还是直接瞄准社交网络更为靠谱。”

From 『2018 年主流 RSS 服务选哪家？Feedly、Inoreader 和 NewsBlur 全面横评』

by PlatyHsu 2018-05-04

写到这里我突发奇想。假如你每天会收到一定量的文章，那么延长刷新间隔时间后，平均每次刷新将为你带来更多文章，某种意义上你赚了。“好吧，我这是 短视损失厌恶 的反向举例😗”

现在还在写独立 Blog 和开 Podcast ，哪一个不是兴趣驱动并用爱发电？ So，为了更好的博客/博客以及整个rss生态环境的健康发展，在此倡议各位 rss 同好 ：

延长 rss 自动更新时间，最好1小时以上---推荐设为1.5小时。

仅对即时性要求较高的资讯源或论坛源适当缩短刷新间隔。

让更多的 rss 同好们一起提高刷新间隔

让 rss 软件开发者也知道此事。

本不应该出现这样的问题

http 缓存

互联网的老祖宗老早就想到了这个问题。 http 头有 etag、Last-Modified、Cache-Control 等参数来实现缓存。

比如Last-Modified，它会记录文件的最后修改时间。

当你第一次通过网络访问服务器上某个文件时，服务器会通过这个http头告诉客户端：“这个文件最后修改时间是 2021/03/20-17:55 ” ，

当你下次再访问这个文件时，你会告诉服务器："我之前收到的文件的最后修改时间是 2021/03/20-17:55 ，请问文件有改动吗？有改动就把新文件发给我！没有就吱我一声“

服务器收到后会比对修改时间是否一致，如果一致，就会告诉你：”没有改动 (304 Not-Modified)“，就不会给你再次发送相同的文件，整个过程也仅仅只消耗不到1kb。

而etag，它的作用的Last-Modified类似，不过它是基于文件内容生成的特征码，具体机制不细说了。Cache-Control也不细说了。

但是很多博客是基于PHP的动态博客（比如本站使用的Typecho）

*此处待完善

如果想拿到 Etag，就必须先拿到要输出的数据，所以 Etag 只能减少带宽的占用，并不能降低服务器的消耗。如果是静态页面，可以判断文件最近一次的修改时间（Last-Modified），获取文件上次修改时间的消耗比拿到整个数据的消耗要小的多。所以很多时候 Etag 都是配合这 Last-Modified 一起使用的。

其实 rss 标准在 xml 文件的开头有 lastBuildDate 和 pubDate 参数，atom 标准在开头有 updated 参数。但是...似乎订阅器们都没有仔细认真对待过这些参数。

这几个参数大家理解可能都会不太一样，所以是较少有仔细对待的。 @about_rss

按道理来说，订阅器应该一边下载一边解析。而不是把 feed 下载到本地后再解析。 这样只要订阅器解析到 lastBuildDate/update/pubDate 时间和上一次更新时相同，就终止下载。这样无论多大的源，在源本身没有更新的情况下，每次刷新都只会消耗仅仅几 kb 的流量。

但现在订阅器更多只把这些参数用到了减少数据库重复写入，提高数据库性能上去。而没有用到减少更新 feed 时的流量消耗上。

都是不管三七二十一，先把 feed 下到本地，再对下下来的 feed 文件进行解析处理。

*此处待完善

RSS软件们/开发者应该做点什么

当然，实现这样的优化确实相对比较难，毕竟这样需要把 feed 下载到内存中处理（毕竟需要边下载边解析），估计网上还找不到用于处理这样功能的库。

真诚希望各个rss软件开发者在这方面下下功夫。

实在不济，还有个最简单的方案，也是我想倡议的。 在您开发的 rss 软件中，在调整更新频率的页面那里设置一个对话框。只要用户一点击小于45～60分钟的刷新间隔的选项，就弹出对话框，这个对话框需要10秒钟才能点击”我已了解“。上面写有： “如非绝对必要，我们不推荐使用更高频率的刷新间隔，这可能会对你所订阅的网站造成不必要的流量开销和压力。“

*此处待完善

对于博主的建议

如果你的博客 cdn 流量在 feed 这方面消耗大，我个人建议先发一篇文章提醒订阅者降低刷新频率。 或通过技术手段，比如将 feed 单独托管在一个不用担心流量消耗的地方（比如github、gitee、coding、Cloudflare Workers等），然后将 feed 的 url 重定向过去。当然，在这个过程中再套一层免费的CDN也是可以的，比如用jsdeliver+github。✌ 如果你只是担心频繁的抓取对服务器造成压力，可以考虑给博客或只针对 feed 加上Redis之类的内存缓存。