可观测行之系统如何识别网站有多少文件命中了缓存?
为了告慰良心,web developer 搞了可视化、组件化、工程化、微前端、低代码。
网站平均加载时间依然客死在 2s 内。
文章首发于掘金,属于小众的技术文,讲的是如何判断网站使用的文件是缓存,有关使用的本地存储数据(ls、ss 等)不在讨论范围。说清楚范围后,说一下分类,这里的文件缓存有两类,第一类是:
disk cache
memory cache
这里的缓存,也就是网络所示中,标明缓存的部分:
上图中,红框内就是缓存的文件。如果服务器发版了,但是客户端依旧使用了缓存的文件,就可能会出现功能不一致、报错等情况。当然使用缓存文件,能够极大的提高网站的性能,至于定量分析,也不在本文章的技术讨论范畴。
在进入主题前,需要需要补充两方面的内容:
Performance.getEntries()
performanceObserver 因为根据上面两方面的内容上面两方面的内容我们能够看到,我们是能够获取到文件的对象的。下面是获取对象的方法代码示例:
下面的类型很多这里,我们只看跟文件有关的,其中包含可能的有:来看一下这个对象都有哪些内容:
link
script
css
img
other
这部分只是掘金展示的内容,我们详细来看一下, 这里我们先看 link 这种类型,以此来了解这个对象都包含哪些内容,
将详细的 json 贴入,能看到:
mdn 在 performanceObserver 的例子中,给出的有关如何判断 304 的代码
上面代码即下图。
同时,mdn 给出了 api 的兼容性。
看到上图,基本可以放心大胆的使用了。理想很丰满,然而现实却是骨感的。因为上图掘金中,明明使用缓存的文件,我们发现 responseStatus 有哪些:
200
204
0 即便明确有 304 的,我们也看不到。所以如何来判断 304?代码如下:
所以,聪明的你,应该能够根据上面的代码推测出来,如果是磁盘或者文件缓存,entry.transferSize 应该是多少呢?
有关命中缓存的好处,就不在本文赘述。下图是本地测试中有关静态文件的 response status 的分布。
版权声明: 本文为 InfoQ 作者【Yestodorrow】的原创文章。
原文链接:【http://xie.infoq.cn/article/0f7f77fbb1eb5bd62fd342446】。文章转载请联系作者。
评论