2

我正在研究加快我们网站速度的解决方案。我让客户端首先 ajax 加载应用程序的预期下一页：

$.ajax({url: '/some/real/path', ...});

服务器对此做出响应并在标头中包含：

Cache-Control => 'max-age=20'

这将响应标记为可缓存。

然后，客户端应用程序等待查看其预测是否正确，并在发现正确后将浏览器转换到同一页面，但将一些信息作为# 片段添加到 URL 中，这些信息可供我们使用仅当用户实际执行了他们的操作时（即不可预测）：

location.href = '/some/real/path#additionalInfoInFragement';

当浏览器转换到页面时，片段中的附加信息会被该页面的 javascript 获取并在那里实现一些效果。

对于包括 Safari 在内的所有浏览器，对起始 ajax 请求的响应已正确插入浏览器缓存中。

然后，对于除 Safari 之外的所有浏览器，当我们将 location.href 转换到该页面时，浏览器会将该内容从缓存中拉出。这避免了服务器命中，是我们提速的基础。

Safari 虽然没有使用缓存来重新提供内容。它似乎被过渡的“#additionalInfoInFragment”部分绊倒了。它将片段包含在其用于检查现有缓存内容的缓存键的构造中。以下是我通过 sqlite 转储的 Safari 的 cache.db 文件中的条目：

* ajax request: INSERT INTO "cfurl_cache_response" VALUES(3260,0,-1982644086,0,'http://localhost:8080/TomcatScratchPad/EmptyPage','2012-05-14 07:01:10');

* location.href transition: INSERT INTO "cfurl_cache_response" VALUES(3276,0,-230554366,0,'http://localhost:8080/TomcatScratchPad/EmptyPage#wtf','2012-05-14 07:01:20');

同样值得注意的是 Chrome 的行为是正确的，尽管两者共享大量的 WebKit 代码。

我真的很感激社区的任何想法。谢谢！

4

1 回答 1

1

我只看到几个选项：

  1. 向 Apple 提交错误报告，不要担心。:-) 您的缓存内容仍然适用于其他浏览器。总体而言，Safari 的市场份额非常小，当然，如果您的网站针对的是（例如）iPad 或 iPhone 用户，这反而会改变您特定网站的统计数据的性质。:-) （您可能从您的日志中知道您的 Safari 用户有多大。）

    子类别：如果 Safari 是您的目标市场的重要组成部分并且这确实让您感到困扰，请查看它是否是它的任何开源部分中的错误，如果是，请提供补丁。

  2. 不要使用片段标识符来传递信息，而是使用其他东西（也许是 cookie）。

于 2012-05-14T13:37:33.927 回答