我想为一些 Amazon S3 文件设置浏览器缓存。我打算使用这个元数据:
Cache-Control: max-age=86400, must-revalidate
这相当于一天。
我看到的许多示例如下所示:
Cache-Control: max-age=3600
为什么只有 3600,为什么不使用 must-revalidate?
对于我很少更改的文件,应该缓存多长时间?
如果我更新文件并需要立即看到该更新,但它的缓存不会再过期 5 天,会发生什么情况?
我想为一些 Amazon S3 文件设置浏览器缓存。我打算使用这个元数据:
Cache-Control: max-age=86400, must-revalidate
这相当于一天。
我看到的许多示例如下所示:
Cache-Control: max-age=3600
为什么只有 3600,为什么不使用 must-revalidate?
对于我很少更改的文件,应该缓存多长时间?
如果我更新文件并需要立即看到该更新,但它的缓存不会再过期 5 天,会发生什么情况?
为什么只有3600?
假设是因为该特定示例的作者认为一小时是该页面的适当缓存超时。
为什么不使用 must-revalidate ?
如果响应不包含严格遵守您设置的缓存规则所需的信息,则省略 must-revalidate 理论上可以确保通过缓存传递更多请求。有关详细信息,请参阅此答案,最相关的部分来自 HTTP 规范:
当缓存有一个陈旧的条目要用作对客户端请求的响应时,它首先必须与源服务器(或可能带有新响应的中间缓存)检查以查看其缓存条目是否仍然可用.
对于我很少更改的文件,应该缓存多长时间?
许多网络性能建议说要设置一个很远的未来缓存过期时间,比如几年。这样,客户端浏览器只会下载一次数据,后续访问将从缓存中获取。这适用于“真正的静态”文件,例如 Javascript 或 CSS。
另一方面,如果数据是动态的,但不会经常变化,您应该根据您的具体场景设置一个合理的过期时间。您是否需要在最新版本可用时立即将其提供给客户,还是可以提供过时的版本?你知道数据什么时候改变吗?等等。一小时或一天通常是服务器负载、客户端性能和数据新鲜度之间的适当权衡,但这取决于您的要求。
如果我更新文件并需要立即看到该更新,但它的缓存不会再过期 5 天,会发生什么情况?
为文件指定一个新名称,或在查询字符串中附加一个值。您当然需要更新所有链接。这是静态资源需要更改时的一般方法。
此外,这里是对您可用的缓存控制属性的一个很好的概述。