我尝试在 Chrome 70 中对此进行了一些调查。这是一个摘要。
我正在跟踪对https://cdnjs.cloudflare.com/ajax/libs/require.js/2.3.5/require.min.js URL 的所有请求,这是我网站的关键脚本。
TL;DR
正如 Kayce 建议的那样,在 Chrome HAR 文件中,没有明确的方法可以确定条目是否由服务人员处理(据我所知)。我也无法找到现有 HAR 条目字段的组合,这些字段可以肯定地将条目标识为由服务人员处理(但也许存在这样的组合)。
在任何情况下,浏览器记录 HAR 条目之间的任何显式关系都会很有用,这样 HAR Viewer 之类的工具就可以识别出两个条目是针对同一个逻辑请求的,因此不会在瀑布流中显示两个请求。
设置
使用清除缓存扩展清除缓存、cookie 等。
在 HAR 中找到的第一个和第二个条目
第一个条目(如下)看起来像是由页面发出并由服务工作者拦截/处理的请求。没有serverIPAddress 和connection,所以我们可以假设这不是一个“真正的”网络请求。
第二个条目也是初始页面加载的结果 - 没有其他刷新/重新加载 - 在初始页面加载时,您在 HAR 中获得 2 个相同 URL 的条目(如果它通过服务工作者并到达网络)。
第二个条目(如下)看起来像是服务工作者向网络发出的请求。我们看到填充了 serverIPAddress 和 response.connection 字段。
这里有一个有趣的观察结果,条目#2 的 startedDateTime 和 time 位于“父”请求/条目的 startedDateTime 和 time 内。
我的意思是条目#2 的开始和结束时间完全在条目#1 的开始和结束时间之内。这是有道理的,因为 entry#2 是 entry#1 的一种“子请求”。
如果 HAR 规范能够明确记录这种关系,那就太好了。 IE。来自页面的 request-A 导致 service worker 发送 request-B。然后像 HAR Viewer 这样的工具不会显示两个条目,这实际上是一个请求(这是否涵盖了页面进行的单个提取导致多个 service worker 提取的情况?)。
另一个观察结果是条目#1 将request.httpVersion 和response.httpVersion 记录为http/1.1,而“真实”请求使用http/2.0。
第三个条目(初始页面加载后在地址栏中按回车键)
在地址栏中按回车后,此条目会出现在 HAR 中。 _fromCache 字段正如预期的那样是 memory,因为在这种情况下,资源应该从常规浏览器缓存中提供(资源使用 cache-control=public, max-age=30672000)。
问题:
- 此条目是否由服务工作人员的 fetch 事件“处理”?
- 也许当资源在内存缓存中时,Service Worker
fetch 事件不会被触发?
- 或者说 Service Worker 在这里有效地“透明”了?
没有预期的serverIPAddress 或connection 字段,因为没有“真正的”网络请求。
存在pageref 字段,与条目#2 不同(条目#2 是服务工作者发起的网络请求)。
第四条
此条目的准备工作是:
此条目将fromCache 设置为disk。我认为这是因为 service-worker-cache 能够满足请求。
没有设置serverIPAddress 或connection 字段,但设置了pageref。
第五条
此条目的准备工作是:
此条目与条目#4基本相同。