“永远”和“永不”是唯一有用的缓存持续时间吗？

在由史蒂夫Souders的（at around 14:30）演示"Cache is King"，它暗示有在实践中，只有你应该为你的资源使用两个缓存持续时间：“永远”和“从不”（我自己的术语）。“永远”和“永不”是唯一有用的缓存持续时间吗？

“永远”意味着您通过设置非常高的最大年龄（例如一年）有效地使资源永久不变。如果您想在某些时候修改资源，演示文稿建议您只需在另一个URL上发布修改后的资源。（建议在此重命名是必要的，部分或全部，因为大量在互联网上错误配置的代理。）
“从不”意味着你有效地禁止一切形式的缓存，并且需要浏览器下载资源每次请求。

一方面，Google首席绩效工程师给出的任何绩效建议都会自行承担责任。另一方面，由于某种原因（不仅仅是“永远”和“从不”）将HTTP缓存设计为可变缓存持续时间，并且仅仅因为资源已被修改而将URL更改为资源似乎违背了HTTP。

有“永远”和“never”中的唯一高速缓存持续时间，你应该在实践中运用？这是否与网络上的其他最佳做法相冲突？

除了典型的“带浏览器的用户”用例外，我还想知道这些原则是如何应用于REST /超媒体API的。

2014-10-16 Jakob

我最喜欢的缓存标头是'Cache-Control：private，max-age = 0'，它可以选择性地与'ETag'组合成等于资源哈希或资源版本。它在使用Ajax或RESTful API的情况下获得最佳结果。例如，请参阅[答案]（http://stackoverflow.com/a/9269567/315935）。 – Oleg 2014-10-18 21:21:01

许多人不同意将自己限制为“永远”或“永远”不如你描述的那样。

首先，它忽略了允许缓存始终重新验证的选项。在这种情况下，如果客户端（或代理）缓存了资源，它将发送一个有条件的HTTP请求。如果客户端/代理缓存了最新版本的资源，则服务器发送一个短的304响应而不是整个资源。如果客户端（代理）副本已过期，则服务器将发送整个资源。

有了这个计划，客户总是会得到资源的了最新版本，如果资源没有改变多少带宽将被保存。

为了节省更多的带宽，客户端可以被指示重新验证，只有当资源超过一定的时间段之前。

而且如果坏代理是一个问题，服务器可以指定只有客户端而不是代理可以缓存资源。

我发现this document非常简洁地描述了您的缓存选项。 This page更长，但也提供了一些优秀的信息。

来源

2014-10-18 07:59:53

如果因为等待时间而被修改为坏。 – 2014-10-24 00:10:04

在避免延迟和提供陈旧数据的浏览器缓存之间进行权衡。如果内容很少发生变化，或者提供的陈旧数据没有问题，那么每月只能重新验证一次或更长时间。 – 2014-10-24 00:17:39

“这取决于”真的，在你的用例，你试图达到的目标以及你的品牌建议。

如果您只想实现一些带宽节省，则可以进行总成本细分。服务成本可能不会太高。例如，浏览器在优化图像点击率方面非常聪明，因此了解您的HTTP协议。永远，结合版本化的资源url和url重写规则可能是一个很好的选择，就像你的Google工程师建议的那样。

资源的波动性是另一回事。例如，如果您仅提供每日股票图表，它可以安全地缓存一段时间，但不是永远。

您的计算成本很高吗？您的用户是否对时间敏感？数据是否存在或修复？例如，您可能正在为航空公司航线，飓风路径，选择希腊航线或向首席运营官报告商务智能报告。您可能希望将其缓存，但TTL可能因用户类而异，一直到永远。永远不能为实时数据工作，但永远也不会是错误的答案。

服务器和客户端之间的合作程度可能是另一个因素。例如，在一个业务操作环境中，可以分发程序并预期遵循程序，再次查看TTL可能是值得的。

HTH。我怀疑是否有一个神奇的答案。

来源

2014-10-23 23:54:29 Dinesh

Idealy，你会缓存内容直到内容发生变化，如果因任何原因无法在内容更改时清除/刷新缓存，则需要一个持续时间。但的确，如果可以的话，永远缓存或不缓存。如果您已经不知道任何变化，则无需刷新。

来源

2014-10-24 11:41:58 KyleK

如果您知道底层数据在任何时间长度内都是静态的，缓存是有意义的。我们有一个Web服务，用于从外部源夜间ETL作业填充的数据库中公开数据。我们的RESTful Web服务只在数据库发生更改时才会发送到数据库。在我们的例子中，我们确切知道数据何时发生变化，并在ETL过程完成后立即使缓存失效。

来源

2014-10-24 20:41:02

“永远”和“永不”是唯一有用的缓存持续时间吗？

回答

相关问题