Web 技术研究所

我一直坚信着,Web 将会成为未来应用程序的主流

合并请求的缓存问题

  之前的文章中已经提及了「合并请求」的许多坑,现在又遇到了一个新的坑。普通的 HTTP 请求是可以使用 HTTP 缓存的。请求有可能被响应 304 或直接 from cache 不发起请求。然而当我们把请求合并成一个之后,HTTP 缓存就无法对合并后的子请求单独做缓存了。
  其实这个问题是可以通过暴力的手段解决的,前端程序直接基于 localStorage 实现一套 Cache-ControlLast-ModifiedETag 即可。这些东西并不复杂,100 行代码内肯定可以搞定。可要是这么实现的话 localStorage 里就会出现一坨奇怪的东西,这样真的好么?或者把这些缓存打包起来放到一个 JSON 中,只在 localStorage 留一个键?可是这样的话我又担心会有性能问题。反正我目前是没有其他解决方案了,姑且先这么用吧。
  纠结完这个问题后突然让我想到了以前提出的另一个问题「合并缩略图」。当时纠结的是程序无法控制 HTTP 缓存,所以合并缩略图无法实现。但现在如果我们自己实现了一套 HTTP 缓存,这个问题就迎刃而解了。如果服务器提供一套输出 BASE64 图片的 API,通过合并请求的方式就完全可以把缩略图合并的问题也一起解决了。不过 BASE64 + GZIP 和二进制流的传输成本比较我目前还没做过测试,也许真可以用也说不定呢!
网名:
3.84.186.*
电子邮箱:
仅用于接收通知
提交 悄悄的告诉你,Ctrl+Enter 可以提交哦
神奇海螺
[查看全部主题]
各类Web技术问题讨论区
发起新主题
本模块采用即时聊天邮件通知的模式
让钛合金F5成为历史吧!
次碳酸钴的技术博客,文章原创,转载请保留原文链接 ^_^