可以看到,大部分浏览器的缓存比例是在68%和84%之间.移动平台的数据差别还是挺大的,我们想可能都是比较低端的移动设备().除此以外数据跟桌面端还是比较相似的.

下面这个图分别是移动端和手机端空缓存用户所占的比例:

平均来看,有的用户是空缓存的,这个也很符合Yahoo团队在2007年做的研究.

更进一步:

到这里,文章还没有完结.在Facebook,我们迭代速度非常快,每天几乎都会发布两个版本.这个驱动我们去思考,多长时间的缓存设置适合我们呢?我们将if-modified-since这个文件头返回的时间减去当前时间来寻找答案.

所以我们根据上面的方法,我们统计了从第一次正常请求到发生304请求的时间(这说明了用户从没有缓存到有缓存经历了多长时间),下面是数据生成的图标:

横轴是以小时为单位的时间值,垂直竖线P50和P75表示在某一时间内缓存请求所占的比例,例如P50告诉我们在47小时的时候有50%的请求是有缓存的,同样,p75意味着75%的请求将是有缓存的.

移动端的测试数据告诉我们大概在12小时的时候有50%的请求是有缓存的.

实际应用:

总体来看我们的统计跟2007年是比较相似的,如果我们firefox浏览器(32和更高版本)不计入统计的话:这次有缓存的比例最高点是,高于2007年的80%.

另一方面,缓存的存在时间并不是太长.基于我们的研究,虽然在一个新版本发布的47小时之后有42%的请求将会带有缓存,但是这个缓存资源在电脑上存在时间也大概是这个时间.这个新的发现,对其他网站很有参考意义.

为什么缓存存在的时间不是太长?其实非常容易理解,从互联网的发展来说,网站的体积从2007到现在发生了不小的变化.拿2007年年来说,那时候我们家里的网速大概是,Yahoo的首页有.现在我的手机都有了8G下行,Yahoo首页已经变到768KB.现在市面上网页的平均大小已经超过1MB了,这将给我们的浏览器的良好运作带来很大的压力(译者注:因为需要缓存的资源太多,超过浏览器设置的默认资源缓存大小会自动删掉早期的一些缓存文件,例如ie默认的是50MB,而chrome的是320MB).

因此合理利用浏览器缓存比8年之前更加有意义.

最佳实践告诉我们:尽量用外链样式表和JS、让headers设置Cache-Control and ETag,并尽可能的压缩我们的数据、用不同的网址管理缓存、分割需要频繁更新的资源.这些优化方法不仅适用于像facebook这样规模的项目,其他网站也可以应用它们.虽然我们的更新频率会对缓存的优化带来负面的影响,但是这个不是本次文章所研究的重点.事实上,我们已经开始运用这次的研究成果来让所有访问facebook的用户收益.