前段时间，我问怎么做Incremental updates using browser cache。
在这里，我给出问题的简短摘要-有关更多背景信息，尤其是我要执行此操作的原因，请引用旧问题。
我希望您查看并改善我的解决方案构想(只是一个构想，所以请不要将我发送给code review:D)。
问题
客户端(单页应用程序)从服务器获取相当大的列表。
这可以正常工作，并且实际上将服务器资源保存为
其中一些列表是特定于用户的，其他列表是一组用户所共有的，其他列表是全局的。
所有这些列表可能随时更改，我们永远不希望提供过时的数据(此处的
Cache-Control和Expires HTTP header 没有直接使用)。我们正在使用
304 NOT MODIFIED，这在没有任何变化的情况下会有所帮助。当任何变化时，变化通常很小，但是HTTP根本不支持这种情况，因此我们必须发送包括未更改部分在内的整个列表。
我们可以改为发送增量，但是没有明显的方法可以使浏览器有效地对其进行缓存(到目前为止，用
localStorage或类似方式进行缓存并不如我在链接的问题中所解释的那样好)。我们列表的重要属性是每个项目都有唯一的
id和最后修改的timestamp。timestamp允许我们通过查找最近更改的项目来轻松计算增量。id允许我们简单地通过替换相应项来应用增量(列表在内部是Map<Id, Item>)。这不适用于删除，但是现在让我们忽略它们。
这个主意
我建议使用大小不同的多个列表(任何数量的列表都可以使用)，并且较大的列表可以长时间存储。
假设一天是合适的时间单位，我们使用以下三个列表:
WEEK这是包含所有项目的基本列表，这些项目在当前一周的任意时间存在。 DAY包含本周已更改的所有项目(今天除外)的列表，因为它们在当天的任意时间存在。今天更改的项目可能包括也可能不包括。
CURRENT包含所有今天已更改且当前存在的项目的列表。 客户端将获得所有三个列表。它以
WEEK开头，应用DAY(即，插入新项目并替换旧项目)，最后应用CURRENT。一个例子
假设列表中有1000个项目，每天有10个项目在变化。
WEEK列表包含所有1000个项目，但是可以缓存到一周结束。未指定其确切内容，并且不同的客户端可能具有不同的版本(只要上述项目符号中的条件成立)。
这允许服务器将数据缓存整个一周，但也可以将其删除，因为服务当前状态也可以。
DAY列表最多包含70个项目，并且可以缓存到一天结束。CURRENT列表最多包含10个项目，并且只能进行缓存，直到发生任何更改为止。沟通交流
客户应该对所用的时间范围一无所知，但是它需要知道要查询的列表数。 “经典”请求，例如
GET /api/order/123 // get the whole list with up to date content
将被三个请求所取代，例如
GET /api/0,order/123 // get the WEEK list
GET /api/1,order/123 // get the DAY list
GET /api/2,order/123 // get the CURRENT list
问题
通常，更改确实如描述的那样，但是有时所有项目都会一次更改。
发生这种情况时，所有三个列表都包含所有项目，这意味着我们必须提供三倍于此的数据。
幸运的是，此类事件非常少见(例如，当我们添加属性时)，但是我希望看到一种允许我们避免此类突发事件的方法？
您是否对此想法还有其他疑问？
除了将项目标记为已删除并将物理删除推迟到缓存过期(即在我的示例中直到一周结束)之前，是否有其他删除的解决方案。
有什么改善吗？
最佳答案
是的，我对此有很大的疑问。这是一个很大的 list ，这意味着客户端需要做很多工作才能减少所需的资源。这对性能有很大影响。
因此，您应该使用较长的缓存时间和cache-busting urls。
那是解决问题的最坏方法。检索的大部分成本是等待时间。如果您以304答复，那么您已经承担了大部分费用-当您处理少量数据时，这一点尤其明显。 HTTP/2有所帮助(与1.0和1.1相比)，但并没有消除成本。
我还要质疑您最初提出的许多假设。