Web 技术研究所

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

前端入口文件缓存的一些想法

  对于前后端分离的站点,目前的架构一般是对入口文件不设置缓存或设置一个较短的缓存,让它能够在下一个版本迭代时及时更新上。然后把其他所有的资源加上版本号丢到 CDN 上。这样程序不但可以及时更新,而且对源服务器的压力也会降得非常低。
  虽然这个做法已经广被使用,但我还是觉得它不够好。因为入口文件无法设置永久缓存所以客户端还是会发起请求。虽然可以使用 ETag 之类的方式来让它 304,但这只能避免内容传输的耗时。从 DNS 解析到请求完成,即使是 304 也需要几百毫秒的时间。如果项目使用的是 https,那这个就需要更久。虽然只是几百毫秒,但从用户大角度看来,这就是一闪而过的白屏。或者如果网络比较渣的话可能就会陷入无止境的白屏。
  如果入口文件可以缓存,并且在新数据加载前先把旧数据展示给用户,这就能解决这个问题。可是入口文件要是缓存了,谁来引导版本更新呢?
  这是个很简单的问题,既然入口文件无法引导版本更新,那么我们只要在程序中处理版本更新就行。比如一个程序以 index.html 为入口,为了避免用户打开时出现一闪而过的白屏,我们把它缓存了。这个文件只干两件事,一件是把上一次成功渲染的页面立即展示出来给用户,另一件是主动请求更新。这样用户不仅可以瞬间打开页面,还可以在页面被浏览之后看到更新的数据。
  这个过程虽然并不复杂,但其中可能还涉及一些交互设计。如果我们只是做了这么一套处理,当数据更新时用户可能就会发现页面莫名其妙地变化了。如果再刚进入页面并渲染上一个版本时给用户一些提示,比如显示一个「更新中」之类的东西。用户就可以知道当前数据可能不是最新的,会等待新数据到来后再操作,而且也不妨碍用户浏览当前显示的数据。
  其实这个设计在很多 App 中早就有了,但 Web 上却很少看到实现。不过确实仔细想想还是有不少坑的,但这依然是个可行的做法。
网名:
3.80.32.*
电子邮箱:
仅用于接收通知
提交 悄悄的告诉你,Ctrl+Enter 可以提交哦
神奇海螺
[查看全部主题]
各类Web技术问题讨论区
发起新主题
本模块采用即时聊天邮件通知的模式
让钛合金F5成为历史吧!
次碳酸钴的技术博客,文章原创,转载请保留原文链接 ^_^