可观测系统如何识别网站有多少文件命中了缓存?

为了告慰良心，web developer搞了可视化、组件化、工程化、微前端、低代码。

网站平均加载时间依然客死在2s内。

文章首发于掘金，属于小众的技术文，讲的是如何判断网站使用的文件是缓存，有关使用的本地存储数据（ls、ss等）不在讨论范围。 说清楚范围后，说一下分类，这里的文件缓存有两类，第一类是：

• disk cache
• memory cache

这里的缓存，也就是网络所示中，标明缓存的部分：

上图中，红框内就是缓存的文件。 如果服务器发版了，但是客户端依旧使用了缓存的文件，就可能会出现功能不一致、报错等情况。当然使用缓存文件，能够极大的提高网站的性能，至于定量分析，也不在本文章的技术讨论范畴。

在进入主题前，需要需要补充两方面的内容：

• Performance.getEntries()
• performanceObserver 因为根据上面两方面的内容上面两方面的内容我们能够看到，我们是能够获取到文件的对象的。下面是获取对象的方法代码示例：

const observer = new PerformanceObserver((list) => {
  list.getEntries().forEach((entry) => {
    
      console.log(entry);

  });
});

observer.observe({ type: "resource", buffered: true });

下面的类型很多这里，我们只看跟文件有关的，其中包含可能的有： 来看一下这个对象都有哪些内容：

• link
• script
• css
• img
• other

这部分只是掘金展示的内容，我们详细来看一下, 这里我们先看link这种类型，以此来了解这个对象都包含哪些内容，

将详细的json贴入，能看到：

{
    "name": "https://lf3-cdn-tos.bytescm.com/obj/static/xitu_juejin_web_editor/css/app.926bb8b0.css",
    "entryType": "resource",
    "startTime": 224,
    "duration": 70.5,
    "initiatorType": "link",
    "nextHopProtocol": "h2",
    "renderBlockingStatus": "non-blocking",
    "workerStart": 0,
    "redirectStart": 0,
    "redirectEnd": 0,
    "fetchStart": 224,
    "domainLookupStart": 224,
    "domainLookupEnd": 224,
    "connectStart": 224,
    "secureConnectionStart": 224,
    "connectEnd": 224,
    "requestStart": 234.5,
    "responseStart": 291.40000000596046,
    "responseEnd": 294.5,
    "transferSize": 52326,
    "encodedBodySize": 52026,
    "decodedBodySize": 309469,
    "responseStatus": 0,
    "serverTiming": [
        {
            "name": "cdn-cache",
            "duration": 0,
            "description": "HIT"
        },
        {
            "name": "edge",
            "duration": 5,
            "description": ""
        }
    ]
}

mdn在performanceObserver的例子中，给出的有关如何判断304的代码

const observer = new PerformanceObserver((list) => {
  list.getEntries().forEach((entry) => {
    if (entry.responseStatus === 304) {
      console.log(`${entry.name} was loaded from cache`);
    }
  });
});

observer.observe({ type: "resource", buffered: true });

上面代码即下图。

同时，mdn给出了api的兼容性。

看到上图，基本可以放心大胆的使用了。理想很丰满，然而现实却是骨感的。 因为上图掘金中，明明使用缓存的文件，我们发现responseStatus有哪些：

• 200
• 204
• 0 即便明确有304的，我们也看不到。所以如何来判断304？代码如下：

entry.encodedBodySize > 0 && entry.transferSize > 0 && entry.transferSize < entry.encodedBodySize

所以，聪明的你，应该能够根据上面的代码推测出来，如果是磁盘或者文件缓存，entry.transferSize 应该是多少呢？

有关命中缓存的好处，就不在本文赘述。下图是本地测试中有关静态文件的response status的分布。