问HAR file -访问Chrome Dev Tools Network选项卡中的"Size“列条目？

EN

看起来像是content对象定义了请求的大小：http://www.softwareishard.com/blog/har-12-spec/#content

但我在来自airhorner.com的示例HAR文件中没有看到任何可以帮助您确定请求是否来自服务工作者的内容。这似乎是HAR规范中的一个缺点。

看起来Puppeteer提供了这个信息。参见response.fromServiceWorker()。

我试着在Chrome70中对此进行了一些研究。这是一个总结。

我正在跟踪所有对https://cdnjs.cloudflare.com/ajax/libs/require.js/2.3.5/require.min.js网址的请求，这是我的网站的关键脚本。

TL;DR

正如Kayce建议的那样，在Chrome HAR文件中，没有明确的方法来确定条目是否由服务工作者处理(据我所知)。我也找不到现有HAR条目字段的组合，可以肯定地将条目标识为由服务工作者处理(但可能存在这样的组合)。

在任何情况下，对于浏览器来说，记录HAR条目之间的任何显式关系都是有用的，这样像HAR Viewer这样的工具就可以识别出两个条目对应于相同的逻辑请求，因此不会在瀑布中显示两个请求。

设置

使用Clear cache扩展清除缓存、cookies等。

​

​

在HAR中找到第一个和第二个条目

第一个条目(如下所示)看起来像是由页面发出并由服务工作者截获/处理的请求。没有serverIPAddress和connection，所以我们可以假设这不是一个“真正的”网络请求。

​

​

第二个条目也是初始页面加载的结果-没有其他刷新/重新加载-在初始页面加载时，对于相同的URL (如果它通过服务工作程序并到达网络)，您将在HAR中获得2个条目。

第二个条目(如下所示)看起来像是服务工作者向网络发出的请求。我们看到填充了serverIPAddress和response.connection字段。

这里有一个有趣的观察，条目#2的startedDateTime和time“落在”“父”请求/条目的startedDateTime和time中。

我的意思是，条目#2的开始和结束时间完全落在条目#1的开始和结束时间内。这是有意义的，因为entry#2是entry#1的一种“子请求”。

如果HAR规范能够明确记录这种关系，那就太好了。即，来自页面的请求-A导致服务工作者发送请求-B。那么，像HAR Viewer这样的工具将不会为有效的单个请求显示两个条目(这是否涵盖页面进行的单个获取导致多个服务工作者获取的情况？)。

另一个观察结果是，entry#1将request.httpVersion和response.httpVersion记录为http/1.1，而“真正的”请求使用http/2.0。

​

​

第三个条目(在初始页面加载后在地址栏中按enter )

按下地址栏中的enter后，此条目将出现在HAR中。正如预期的那样，_fromCache字段为memory，因为在这种情况下，资源应该从常规浏览器缓存中提供(资源使用cache-control=public, max-age=30672000)。

问题：

• 此条目是否由服务工作者的fetch事件“处理”？
• 可能当资源在内存缓存中时，服务工作者fetch事件未被激发？
• 或服务工作者在这里是否有效地“透明”？

没有预期的serverIPAddress或connection字段，因为没有“真实”的网络请求。

与entry#2不同，存在pageref字段(entry#2是服务工作者发起的网络请求)。

​

​

第四个条目

这篇文章的准备工作是：

将资源添加到service-worker-cache (https://developer.mozilla.org/en-US/docs/Web/API/Cache).

• Use清除缓存扩展中，以清除所有缓存( service-worker-cache).

• Reload页除外。

此条目的fromCache设置为disk。我认为这是因为service-worker-cache能够满足请求。

没有设置serverIPAddress或connection字段，但设置了pageref。

​

​

第五个条目

这篇文章的准备工作是：

• 使用devtools进入'Offline‘模式。

此条目与entry#4基本相同。

​

​