我试图理解为什么我的应用程序记录的总获取请求时间与Chrome开发工具“网络>计时”选项卡中显示的时间不同。
考虑这个例子，它记录了获取开始时间和获取响应时间之间的差异：
const startTime = new Date();
fetch('https://somedomain.com/api/route')
.then(res => {
const completeTime = new Date().getTime();
console.log(completeTime - startTime)
})字符串
现在，当我查看Chrome的“网络”选项卡时，点击列表中的请求，然后点击“计时”选项卡-我会看到请求的不同阶段的细分，底部列出了总时间。这个时间总是小于上面示例中记录的时间。通常情况下，差异是1- 10毫秒，但我观察到的差异高达几百毫秒。
是什么因素影响了这种差异？
1条答案
按热度按时间nafvub8i1#
尝试通过JS监控获取请求几乎是毫无意义的。我将解释为什么：
首先，你是Chrome之上的几层。你浪费时间示例化一个新的日期对象，检索它的时间戳，生成一个获取请求，这是JS插入到事件循环中的一个承诺，以及由于JS JIT编译过程而产生的更多开销。这可以解释几个额外的毫秒（我猜不到100）。
second，promise被插入到事件循环队列中，只有在服务器响应期间运行的队列结束后才会被处理。这意味着即使在收到HTTP响应后，当前队列可能需要一段时间才能完成（例如，如果您正在进行一些数学计算）。这可能会导致几十毫秒的额外时间（我猜有几百个）。
第三个也是最重要的是Chrome的每个域的最大并行连接数，默认为6。这意味着如果你的页面正在发送超过6个HTTP请求，其中一些请求只有在它们之前的那些请求完成后才会被触发。我做了一个测试，我试图获取9个不同的东西，第一个请求的额外毫秒数是~ 200毫秒，但第7 - 9个请求的额外毫秒数是惊人的~ 1500毫秒！
我希望我没有错过任何其他可能影响JS在这件事上的不准确性。干杯！