当Steve Souder在2007年出版《高性能web站点》这本书的时候,第一次向大家解释了什么是浏览器缓存,以及如何使用浏览器缓存来提高你站点的性能。令人难以置信的是,其实在那之前,浏览器缓存对于很多web开发者来说是很神秘的东西。有些人甚至都不知道为什么请求的图片、css、js文件会存放在他们硬盘上。 在那本书里面有提到,我们可以在每次请求资源的时候,给资源打上一个过期时间头,这样在这个过期时间头内,用户在请求统一资源的时候,是不需要在重新在网上拉去回来的。人们使用web应用和我们开发web应用的方式其实都已经发生了很多变化。然而,有三个非常具体的变化,也是这三个变化需要我们再重新的思考一下浏览器缓存这个东西。

1.选项卡式浏览

追溯到2007,IE几乎占领了整个浏览器市场。在2006年末发布了IE7,并且在那时候,没有浏览器会自动更新。值得庆幸的是,firefox出现了,并开始分割IE浏览器的市场份额,这就意味着Steve在写那本书的时候,大部分用户用的还都是不支持多tab得IE浏览器。 在现在,多tab浏览器已经非常常见了,但是在IE6统治的时代,用户大多是在任务栏中会打开若干个浏览器窗口。并且在一个非开发人员的桌面上你很难看到多个浏览器同时存在的时候。好多人当时的做法是,访问一个站点,然后点击收藏,把这个站点收藏之后再去点击下一个站点。有时候用户还有可能点击返回操作,去看上一个或者之前访问过的站点。在现在看这么做是非常可笑的。 在那个年代,浏览器缓存的价值体现在,如果你早上看过了一个站点,当你晚上再去访问这个站点的时候,这个站点载入的速度会明显快很多。如果你每天都去访问同一个站点,浏览器缓存的加速作用会更加明显。其实你可以计算一下你经常访问的站点,数量也许并不多。 当多tab这种模式被引入之后,很多用户产生了一种新的浏览习惯,他会打开多个tab一整天。如果你不关闭这个站点,这时候浏览器缓存所扮演的角色就比较尴尬了,可能就没什么收益了。

2.Ajax 和 单页面应用

一旦真的说用户打开多个tab一整天都没关闭站点,这个时候,站点的自动更新就变得额外的重要了。并且站点的自动更新比你主动去点击刷新按钮的体验更好,Ajax这个技术允许开发人员在不刷新整个站点的情况下获取新的数据,因此单页面应用应运而生。(SPA) 事实上第一个影响面最大的单页面应用应该是Gmail,在使用Gmail的时候,你可以在不刷新页面的情况下,产看新邮件、回复或者新建邮件。因此你可以打开gmail然后仍在那不去管它,然后他会自己在“后台处理一些逻辑”。 随着单页面应用的兴起,这也变相的让浏览器缓存的作用相对的降低了一些。如果我一直这样使用的话,打开页面页面自己去做更新的逻辑,那么缓存其实对我又有什么作用呢。

3.持续化部署

最后一个比较大的变化,并且真正意义上改变浏览器缓存作用的就是持续化部署。就我自己身的开发经验来看,在大多数情况下几乎所有的静态文件最多不会超过两周就会发生修改,这也就意味着浏览器的缓存两周就需要被更新一次,也就是说其实这些文件在某一阶段仅仅是在某一阶段才具有真正的业务意义。 目前持续化部署也是随处可见了。好多公司可能每天都会做更新上线,甚至还可能一天更新上线好多次。如果你发布的东西或者说需要上线的东西包括js、css、图片这些文件的时候,你反而会觉得缓存文件反而成为了你上线的阻碍。因为你想让你上线的东西立马出现在更新在用户眼前。在单页面应用中除此之外你能还会面一个异步问题,你如何保证用户已经全部更新到最新版本,你必须要刷新整个页面才能解决这个问题。通常有一个约定俗称的规律是:很多工程师压根不关心浏览器的缓存,因为他们都会去设置一个很长的过期时间戳,但没人关心缓存的命中率。

今天的浏览器缓存

如果有人问我浏览器缓存目前所扮演的角色,其实我真的不知道该怎么回答。每天有难以计算的文件发生着变化,每天有无数的单页面应用在被使用,但是我可以很明确的告诉对方浏览器缓存目前所扮演的角色和2007年是有很大不同的。 并且随着新技术的发展比如service worker,浏览器缓存所扮演的角色又将会发生很大的变化。 正是伴随着这些变化点,我们其实应该去思考一下,新的缓存策略,我觉得这是个很有意义的话题。