我试图理解为什么我的应用程序记录的总获取请求时间与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在这件事上的不准确性。干杯!