使用XHR预缓存资源未按预期行为表现

Question

我只是想使用XHR预缓存一些资源，但缓存的行为并不如预期。

问题的范围如下：

• 我事先知道这些资源的URL（当然）。
• 我不知道它们的内容类型（CSS、图像和其他的混合）。
• 它们总是同源的。
• 我控制缓存标头。
• 它们可以永久缓存，我不在意。

我一直以为XHR会像其他资源一样使用浏览器缓存，但从未经过严格测试。这就是我正在做的事情：

• 使用XHR预先请求所有资源。
• 显式设置请求头Cache-Control: max-age=3600（Chrome由于某种原因设置了max-age=0）。

• 在服务器上设置以下响应标头：

  • Cache-control: public; max-age=3600
  • Date: now
  • Expires: now + 1 hour
  • [Content-Type, Content-Length]

这是我看到的情况：

• XHR始终获取资源（在服务器和开发工具中确认）。
• 在冷缓存中，后续请求（通过图像/CSS等元素）始终获取（即使XHR已经完成）。
• 但它们总是在缓存变热时使用缓存。

我以各种方式试探过它，但这种行为似乎从未改变。

- Joel Webber

---

“Subsequent requests (via image/css/etc elements) always fetch (even after the XHRs have completed) on a cold cache.” 这句话的意思是什么？你是在稍后动态创建 <script>/<img> 元素吗？ - Nelson Menezes

没错。这个想法是利用XHR请求来预热缓存，然后希望稍后动态创建的脚本/图片元素可以从预热缓存中获取。 - Joel Webber

Answer 1

经过长时间的挣扎和努力，我认为我已经证明了这种方法在所有浏览器上都行不通。以下是我迄今为止的经验：

• Firefox：使用起来非常方便。
• Chrome：很少起作用——就好像XHR使用不同的缓存而不是元素一样（尽管我非常确定这不是事实；我还没有时间深入研究Chrome代码，以弄清楚到底发生了什么。
• Safari：表现看似随机。有时从元素中检索出的资源请求会从缓存中检索，有时则不会。我确信有一种方法，但从外部看来，这似乎是疯狂的。

最终，我不得不转向使用略微更糟糕但可靠的方法，即创建一个隐藏的iframe，在其中注入脚本/图像元素，然后等待iframe窗口的onload事件。这个方法可以工作，但不能提供有关加载了哪些元素的精细反馈（从各个元素中获取可靠的onload事件比只等待整个帧“跨浏览器棘手”得多）。

我很想更精确地了解Chrome/Safari中发生了什么，但可悲的是没有时间进一步挖掘。

- Joel Webber