我正在研究一个解决方案来加快我们网站的速度。我让客户端首先使用 ajax 加载应用程序预期的下一页:
$.ajax({url: '/some/real/path', ...});
服务器对此做出响应并在 header 中包含:
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 代码。
我非常感谢社区的任何想法。谢谢!
最佳答案
我只看到几个选项:
向 Apple 提交错误报告,不要担心。 :-) 您的缓存内容仍然适用于其他浏览器。总的来说,Safari 有一个 very small market share ,当然,如果您的网站是针对(比如说)iPad 或 iPhone 用户的,那么这会改变您特定网站的统计信息的性质。 :-)(您可能从日志中知道您的 Safari 用户有多大。)
子类别:如果 Safari 是您目标市场的重要组成部分并且这确实让您感到困扰,请查看它是否是它的任何开源部分中的错误,如果是,请提供补丁。
不要使用片段标识符来传递信息,而是使用其他东西(也许是 cookie)。
关于javascript - Safari 将 URL # 片段合并到其浏览器缓存中,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/10584331/