如何定义最佳 Cache-Control 策略

定义最佳 Cache-Control 策略



按照以上决策树为您的应用使用的特定资源或一组资源确定最佳缓存策略。在理想的情况下,您的目标应该是在客户端上缓存尽可能多的响应,缓存尽可能长的时间,并且为每个响应提供验证令牌,以实现高效的重新验证。

Cache-Control 指令和说明
max-age=86400 浏览器以及任何中间缓存均可将响应(如果是“public”响应)缓存长达 1 天(60 秒 x 60 分钟 x 24 小时)。
private, max-age=600 客户端的浏览器只能将响应缓存最长 10 分钟(60 秒 x 10 分钟)。
no-store 不允许缓存响应,每次请求都必须完整获取。

根据 HTTP Archive,在排名最高的 300,000 个网站(按照 Alexa 排名)中,所有下载响应中有半数可由浏览器缓存,这可以大量减少重复的网页浏览和访问。当然,这并不意味着您的特定应用有 50% 的资源可以缓存。一些网站的资源 90% 以上都可以缓存,而其他网站可能有许多私密或时效要求高的数据根本无法缓存。

废弃和更新缓存的响应


  • 在资源“过期”之前,将一直使用本地缓存的响应。
  • 您可以通过在网址中嵌入文件内容指纹,强制客户端更新到新版本的响应。
  • 为获得最佳性能,每个应用都需要定义自己的缓存层次结构。

浏览器发出的所有 HTTP 请求会首先路由到浏览器缓存,以确认是否缓存了可用于满足请求的有效响应。如果有匹配的响应,则从缓存中读取响应,这样就避免了网络延迟和传送产生的流量费用。

不过,如果您想更新或废弃缓存的响应,该怎么办?例如,假定您已告诉访问者将某个 CSS 样式表缓存长达 24 小时 (max-age=86400),但设计人员刚刚提交了一个您希望所有用户都能使用的更新。您该如何通知拥有现在“已过时”的 CSS 缓存副本的所有访问者更新其缓存?在不更改资源网址的情况下,您做不到。

浏览器缓存响应后,缓存的版本将一直使用到过期(由 max-age 或 expires 决定),或一直使用到由于某种其他原因从缓存中删除,例如用户清除了浏览器缓存。因此,构建网页时,不同的用户可能最终使用的是文件的不同版本;刚获取了资源的用户将使用新版本的响应,而缓存了早期(但仍有效)副本的用户将使用旧版本的响应。

所以,如何才能鱼和熊掌兼得:客户端缓存和快速更新?您可以在资源内容发生变化时更改它的网址,强制用户下载新响应。通常情况下,可以通过在文件名中嵌入文件的指纹或版本号来实现 - 例如 style.x234dff.css。

因为能够定义每个资源的缓存策略,所以您可以定义“缓存层次结构”,这样不但可以控制每个响应的缓存时间,还可以控制访问者看到新版本的速度。为了进行说明,我们一起分析一下上面的示例:

  • HTML 被标记为“no-cache”,这意味着浏览器在每次请求时都始终会重新验证文档,并在内容变化时获取最新版本。此外,在 HTML 标记内,您在 CSS 和 JavaScript 资产的网址中嵌入指纹:如果这些文件的内容发生变化,网页的 HTML 也会随之改变,并会下载 HTML 响应的新副本。
  • 允许浏览器和中间缓存(例如 CDN)缓存 CSS,并将 CSS 设置为 1 年后到期。请注意,您可以放心地使用 1 年的“远期过期”,因为您在文件名中嵌入了文件的指纹:CSS 更新时网址也会随之变化。
  • JavaScript 同样设置为 1 年后到期,但标记为 private,这或许是因为它包含的某些用户私人数据是 CDN 不应缓存的。
  • 图像缓存时不包含版本或唯一指纹,并设置为 1 天后到期。

您可以组合使用 ETag、Cache-Control 和唯一网址来实现一举多得:较长的过期时间、控制可以缓存响应的位置以及随需更新。

缓存检查清单



不存在什么最佳缓存策略。您需要根据通信模式、提供的数据类型以及应用特定的数据更新要求,为每个资源定义和配置合适的设置,以及整体的“缓存层次结构”。

在制定缓存策略时,您需要牢记下面这些技巧和方法:

  • 使用一致的网址:如果您在不同的网址上提供相同的内容,将会多次获取和存储这些内容。提示:请注意,网址区分大小写
  • 确保服务器提供验证令牌 (ETag):有了验证令牌,当服务器上的资源未发生变化时,就不需要传送相同的字节。
  • 确定中间缓存可以缓存哪些资源:对所有用户的响应完全相同的资源非常适合由 CDN 以及其他中间缓存进行缓存。
  • 为每个资源确定最佳缓存周期:不同的资源可能有不同的更新要求。为每个资源审核并确定合适的 max-age。
  • 确定最适合您的网站的缓存层次结构:您可以通过为 HTML 文档组合使用包含内容指纹的资源网址和短时间或 no-cache 周期,来控制客户端获取更新的速度。
  • 最大限度减少搅动:某些资源的更新比其他资源频繁。如果资源的特定部分(例如 JavaScript 函数或 CSS 样式集)会经常更新,可以考虑将其代码作为单独的文件提供。这样一来,每次获取更新时,其余内容(例如变化不是很频繁的内容库代码)可以从缓存获取,从而最大限度减少下载的内容大小。
时间: 2024-10-02 05:19:56

如何定义最佳 Cache-Control 策略的相关文章

etag cache control

https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching?hl=zh-cn 我们唯一要做的就是确保服务器提供必要的 ETag 令牌.检查您的服务器文档中有无必要的配置标志.有没有etag是服务器配置, 每个资源都可通过 Cache-Control HTTP 标头定义其缓存策略 Cache-Control 指令控制谁在什么条件下可以缓存响应以及可以缓存多

java cache过期策略两种实现,一个基于list轮询一个基于timer定时

最近项目要引入缓存机制,但是不想引入分布式的缓存框架,所以自己就写了一个轻量级的缓存实现,有两个版本,一个是通过timer实现其超时过期处理,另外一个是通过list轮询.       首先要了解下java1.6中的ConcurrentMap ,他是一个线程安全的Map实现,特别说明的是在没有特别需求的情况下可以用ConcurrentHashMap.我是想学习一下读写锁的应用,就自己实现了一个SimpleConcurrentHashMap. [java] view plain copy print

kafka数据接口定义最佳实践

1 上游业务系统向kakfa推送的数据全部应为 字符串类型,使用的时候 转换成需要的类型,保证数据可以类型转换2 为了便于后续 kafka数据校对,建议把推送数据来自的数据库主键id,也一起推送过来(一般数据推送流程:业务过程 --> 插入DB(返回主键id) --> 推送kafka) 3 所有金额涉及到到计算全部使用 decimal 类型,不要使用double 4 小数的位数需要明确好 原文地址:https://www.cnblogs.com/wooluwalker/p/12168066.h

前端学习笔记--HTTP缓存

原文地址:https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching?hl=zh-cn 缓存并重用之前获取的资源的能力是性能优化的一个关键方面. 每个浏览器都自带了 HTTP 缓存实现功能,只需要确保每个服务器响应都提供正确的 HTTP 标头指令,以指示浏览器何时可以缓存响应以及可以缓存多久. HTTP 与浏览器交互的请求头: 当服务器返回响应时,还会发

ASIHTTPRequest缓存策略download cache

本文为大家介绍了iOS开发ASIHTTPRequest使用download cache的内容,其中包括cache策略,存储策略,其他cache相关的特性,编写自己的cache等等内容. 从1.8版本开始,ASIDownloadCache和ASICacheDelegate的API改变了,你可能需要修改你的代码. 尤其是,cache策略的可用选项发生了改变,你现在可以对单一request使用结合的cache策略 ASIHTTPRequest可以自动缓存下载的数据,在很多情况下这很有用. 当你离线时,

缓存读写策略 - Cache Aside.md

场景描述 比如一条数据同时存在数据库.缓存,现在你要更新此数据,你会怎么更新? 先更新数据库?还是先更新缓存? 其实这两种方式都有问题. (1)先更新数据库,后更新缓存 这样会造成数据不一致. A 先把数据库更新为 123,由于网络问题,更新缓存的动作慢了. 这时,B 去更新数据库了,改为了 456,紧接着把缓存也更新为 456. 现在 A 更新缓存的请求到了,把缓存更新为了 123. 那么这时数据就不一致了,数据库里是最新的 456,而缓存是 123,是旧数据. 因为数据库更新.缓存更新这2个

提高 Web 站点性能的最佳实践

本文内容 提高 Web 站点性能的最佳实践 最大限度减少 HTTP 请求 使用内容分发网络(CDN) 添加 Expires 或 Cache – Control 头 Gzip 组件 CSS 放在页面顶部 JavaScript 放在页面底部 避免 CSS 表达式 使用外部 JavaScript 和 CSS 减少 DNS 查询 精简 JavaScript 和 CSS 避免重定向 删除重复的脚本 配置 ETags 使得 Ajax 可缓存 尽早强制地发送缓冲给客户端 用 GET 发送 Ajax 请求 延迟

Android的定位策略

原文作者:Google 原文地址:https://developer.android.com/guide/topics/location/strategies.html 原文版权:Creative Commons 2.5 Attribution License 译文作者:Jianan - [email protected] 版本信息:本文基于2016-06-17版本翻译 译文版权:CC BY-NC-ND 4.0,允许复制转载,但必须保留译文作者署名及译文链接,不得演绎和用于商业用途 前言 Not

Symfony2学习笔记之HTTP Cache

富web应用程序的本质意味着它们的动态.无论你的应用程序多么有效率,每个请求比起静态文件来说总会存在很多的耗费.对于大多数web程序来说,这没什么. Symfony2非常的轻快,无论你做些严重超载的请求,每个请求将会得到很快的回复,而不会对你的服务器造成压力.但是随着你站点的成长,负载将成为一个严重的问题.对每个请求处理应该只被正常执行一次.这就是缓存真正要达成的目标. 站在巨人肩膀上的缓存:提高一个应用程序执行效率的最有效方法是缓存一个页面的所有输出然后让后续的请求绕开整个应用程序.当然,这对