Firebug 为什么可以“接收”网络选项卡中的值为零？
我正在使用 Firebug 和 YSlow 对 LAN 上的服务器进行基准测试，有时我会在“接收”时得到“0 毫秒”。根据 Firebug (http://getfirebug.com/wiki/index.php/Net_Panel) 这应该表示通过网络读取数据所需的时间。
然而，我的结果似乎表明这种情况很快就会发生，但其他时候更可能出现几毫秒的结果：
有人知道为什么会发生这种情况吗？即使我清除缓存并使用 Ctrl+F5 重新加载整页，这种情况也经常发生。
I am using Firebug and YSlow to benchmark a server on my LAN and on occaision I get '0 ms' for 'receiving'. According to Firebug (http://getfirebug.com/wiki/index.php/Net_Panel) this is supposed to represent the time it takes to read the data over the network.
However my results seem to indicate this happens in no time at all, yet other times gives a more likely result of a few milliseconds:
Anyone have a clue why this might happen? It often happens even if I clear cache and do a full page reload with Ctrl+F5.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您可能会看到“BFCache”结果；这些通常具有非常短的“等待”时间（<20ms）和0“接收”时间，因为它们直接来自浏览器而不是来自新的网络请求。它们以浅灰色显示，如屏幕截图中的
spacer.gif条目。请参阅 Firebug 1.6：还跟踪 BFCache 读取以获得更详细的解释。您可以使用“网络”选项卡选项打开/关闭这些功能。 （为了清楚起见，我通常将它们关闭。）
更新：我使用您提到的相同设置（禁用浏览器缓存，不显示 BFCache 结果）进行了一些进一步的测试，并且我确实使用此页面看到了相同的结果举个例子。我还用 Google Chrome 网络面板检查了同样的情况，它也有类似的结果。看起来“0 接收时间”仅发生在可能适合单个网络数据包的最小响应大小（大约 1KB 以下）。我怀疑这是网络面板时序测量方式的边缘情况。该数据包同时表示数据传输的开始和结束，因此这可能就是它报告为 0 的原因。
You might be seeing the "BFCache" results; these typically have a very small "waiting" time (<20ms) and 0 "receiving" time because they are coming directly from the browser rather than from a new network request. These are shown in a lighter gray color, like the
spacer.gifentry in your screenshot.See Firebug 1.6: Tracking also BFCache reads for a more detailed explanation. You can turn these on/off with the Net tab options. (I usually keep them off for clarity.)
Updated: I did some further testing with the same settings you mentioned (browser cache disabled, not showing BFCache results) and I do see the same results using this page as an example. I also checked the same with Google Chrome Network panel and it has similar results. It looks like the "0 receive time" is happening only for the smallest response sizes (under about 1KB) which probably fit within a single network packet. I suspect this is an edge case in the way net panel timing is measured. That one packet signals both the start and end of the data transfer, so that may be why it's reported as a 0.