要求浏览器尽可能积极地缓存答案

【问题标题】：Asking browsers to cache as aggressively as possible要求浏览器尽可能积极地缓存
【发布时间】：2011-01-26 10:25:33
【问题描述】：

这是关于提供图像的网络应用程序。由于相同的请求将始终返回相同的图像，我希望访问浏览器尽可能积极地缓存图像。我很想告诉浏览器

这是您的图片。继续并保留它；在接下来的几天里，它真的不会改变。没必要回来。真的。我保证。

到目前为止，我确实设置了

缓存控制：公共，最大年龄=86400
最后修改：（前一段时间）
过期：（从现在起两天后）

当然，如果请求具有适当的 If-Modified-Since 标头，则返回 304 not modified。

我还能做些什么（或者我应该做些什么不同的事情）来将我的消息传递给浏览器？

应用托管在 Google App Engine 上，以防万一。

【问题讨论】：

如果不改的话，1天的过期时间（max-age）也不算多。
@Gumbo：是的；正如我在 Sripathi Krishnan 的回答中指出的那样，这肯定会增加。我仍然想知道为什么 Gravatar 将其设置为仅 5 分钟。
你可以改变你的头像，所以很有意义。

标签： http browser caching http-headers

【解决方案1】：

您可能有兴趣查看以下 Google 代码文章：

Optimize caching: Leverage browser caching

简而言之，所有现代浏览器都应该能够按照说明使用这些 HTTP 标头适当地缓存您的图像。

【讨论】：

【解决方案2】：

你可以做得更好。 304 仍然是 HTTP 请求/响应。虽然图像没有再次下载，但延迟可能会被杀死。

如果您可以在映像名称中包含版本标识符，则可以将 max-age 设置为 2 年。这样，您可以防止 304。如果图像发生更改，您将更新版本标识符，从而更改文件名。这可确保浏览器发出新的请求。

它需要对您的项目结构进行一些更改。版本标识符可以是上次更新映像时的 SVN 修订号，并且可以在构建时自动生成。您还需要更新 html，因此如果您在图像名称和图像路径之间有逻辑映射，您的工作会更容易。

图像很少更新，因此如果您无法自动执行我上面描述的操作，您也可以采用手动方法。诀窍是只添加新图像，从不修改它们。

【讨论】：

这些都是好主意。长 max-age 是我肯定会做的事情。虽然我认为我读到一年是根据 RFC 允许的最大值。版本标识符是我考虑过的，但不幸的是它不是一个选项。该应用程序仅提供要包含在其他网页中的图像（像 Gravatar 一样）。
@Sripathi Krishnan：但杀戮延迟似乎无法避免！每当您关闭浏览器并在同一页面上再次打开它时，即使使用mod_expires，浏览器也会再次对图像发出 HTTP 请求。在服务器响应后它不会下载图像，但它仍然会查询服务器，从而增加延迟。看到我的问题也许你有一个想法：stackoverflow.com/questions/10048740/…
根据 rfc2616 的第 14.21 节，“HTTP/1.1 服务器不应发送超过一年的过期日期。”；一年是你的最大值。

【解决方案3】：

我不知道它是否会比其他人提供的解决方案有所帮助，但您可以使用HTML5 offline web apps 工具更明确地要求浏览器存储本地副本。

【讨论】：

这是个好主意。在我的情况下它没有帮助（因为我只提供图像，我不控制包含这些图像的页面的 HTML）。但很高兴知道一般情况。 +1

【解决方案4】：

缓存头有一个非常重要的值，你在这里没有提到：

“后检查=900，前检查=3600”

阅读有关此主题的文章（并搜索更多内容）：

http://www.rdlt.com/cache-control-post-check-pre-check.html

【讨论】：

这很有趣，谢谢。有几点值得一提：这只是 IE，你链接到的帖子本身链接到一篇相当老的文章，我没有发现任何提到你的“你的客户浏览器总是问......”的说法；恰恰相反，在评论线程中有许多迹象表明 IE 实际上确实尊重标准标题。
也许只适用于ie，我不知道。我所知道的是，我在 google chrome 和 mozilla firefox 上的开发人员工具上看到，从我设置此值的那一刻起，就一直停止获取图像。事实是我的工作速度很快，在我看到效果更好之后，并没有检查太深。如果使用或不使用此值，也许在 chrome 的源代码中会有一个真正的答案。
我删除了“没有该标题，即使您设置了您提到的标题，您的客户浏览器也会始终询问您的页面和图像。”因为我没有检查它是否酸。我还发现这篇文章是相对的。 google.co.uk/support/forum/p/Chrome/…

【解决方案5】：

试试 .htaccess 之类的

<ifmodule mod_gzip.c>
  mod_gzip_on Yes
  mod_gzip_dechunk Yes
  mod_gzip_item_include file \.(html?|txt|css|js|php|pl)$
  mod_gzip_item_include handler ^cgi-script$
  mod_gzip_item_include mime ^text/.*
  mod_gzip_item_include mime ^application/x-javascript.*
  mod_gzip_item_exclude mime ^image/.*
  mod_gzip_item_exclude rspheader ^Content-Encoding:.*gzip.*
</ifmodule>

<ifmodule mod_deflate.c>
AddType application/x-compress .Z
AddType application/x-gzip .gz .tgz
AddType application/x-httpd-php .php
AddType application/x-httpd-php .php3
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/xml
AddOutputFilterByType DEFLATE application/x-httpd-php
AddOutputFilterByType DEFLATE application/x-javascript
</ifmodule>

<ifmodule mod_expires.c>
  ExpiresActive On
  ExpiresDefault "access plus 1 seconds" 
  ExpiresByType text/html "access plus 1 seconds" 
  ExpiresByType image/gif "access plus 2592000 seconds" 
  ExpiresByType image/jpeg "access plus 2592000 seconds" 
  ExpiresByType image/png "access plus 2592000 seconds" 
  ExpiresByType text/css "access plus 604800 seconds" 
  ExpiresByType text/javascript "access plus 216000 seconds" 
  ExpiresByType application/x-javascript "access plus 216000 seconds" 
</ifmodule>

<ifmodule mod_headers.c>
  <filesMatch "\\.(ico|pdf|flv|jpg|jpeg|png|gif|swf)$">
    Header set Cache-Control "max-age=2592000, public" 
  </filesmatch>
  <filesMatch "\\.(css)$">
    Header set Cache-Control "max-age=604800, public" 
  </filesmatch>
  <filesMatch "\\.(js)$">
    Header set Cache-Control "max-age=216000, private" 
  </filesmatch>
  <filesMatch "\\.(xml|txt)$">
    Header set Cache-Control "max-age=216000, public, must-revalidate" 
  </filesmatch>
  <filesMatch "\\.(html|htm|php)$">
    Header set Cache-Control "max-age=1, private, must-revalidate" 
  </filesmatch>
</ifmodule>

【讨论】：

应用程序在 Google App Engine 上；没有.htaccess（或者 Apache，就此而言）
糟糕，我忽略了这一点。无论如何，我一直在保持它，以便它可以帮助那些使用 Apache 的人。

【解决方案6】：

您可以为每个图像添加一个ETag 表示，然后将其与入站请求的If-None-Match 标头进行比较（请参阅“Why isn’t my custom delivered image caching in the browser?”）。当使用首选的Last-Modified 标头时，这是多余的，无论如何这只是另一种说法 304。（我认为 GAE 会自动为静态文件执行此操作，但不确定。）

Gravatar 设置了很旧的Last-Modified 日期——默认值似乎是“Wed, 11 Jan 1984 08:00:00 GMT”。 5 分钟到期会导致浏览器频繁检查更新的图像。换句话说，我认为他们是在邀请 304，而不是试图说服浏览器只使用本地缓存。它们的标题如下所示：

Date: Sat, 20 Mar 2010 07:52:43 GMT
Last-Modified: Wed, 11 Jan 1984 08:00:00 GMT
Expires: Sat, 20 Mar 2010 07:57:43 GMT
Cache-Control: max-age=300

最大的区别是到期时间——你需要两天，他们需要五分钟。所以如果你想让浏览器只使用缓存的图片 48 小时，做你正在做的，只设置Cache-Control: max-age=172800（86400 是 24 小时）。

【讨论】：

【解决方案7】：

几天的缓存年龄非常低。您应该将其设置为一年或更长时间。当然，当图像实际更改时，这可能会引发问题，但您可以通过向图像添加版本号并更改引用图像的页面以包含新图像的路径来解决这个问题。

我在这里写了更多关于 Web 应用程序缓存的内容： http://patchlog.com/web/7-methods-to-cache-web-applications/

【讨论】：

你在开玩笑吗？我完全赞成怀疑，我总是感谢人们在回答中给我的任何提示或帮助。但是，与一周前 Sripathi Krishnan 所做的几乎相同的东西（只是更详细）只是为了链接到您失去相关性的博客文章——我称之为垃圾邮件。
这可能很难相信，但在我发帖之前我没有看到他的回答。而且我的帖子还有更多关于缓存的想法，但当然更简单的是忽略某些内容并投反对票而不是阅读相当长的帖子。
信不信由你，反对票不是我的。不过，您的博文（我觉得它一点也不长；在接受的答案中链接的文字要长得多）与我的问题无关。
如果我链接到与问题相关的帖子的事实不是您的问题，那是什么？我的答案是重复的事实？我发现很难仅仅因为它是重复的而考虑垃圾邮件。我没有给出这个答案，因为我想链接到我的帖子。我给了它，因为我认为它可能会有所帮助。我链接到该帖子只是因为我不想写我已经在其他地方写过的东西。