Recently I was debugging some network calls, latency, etc. I found that Firefox misses an essential measurement of the network request (atleast not shown) - that of the start time / timestamp of the network request. Sometimes it is useful to see when the request started (ie. 1.7s into the page hit/refresh, and then at what time it successfully got delivered, ie. 2.3s). This is very helpful when measuring timelines of the page or timed events.

Chrome currently does have the timestamp displayed, it shows the total elapsed time for the request as well. It shows the data at 2 levels

• The hover card when the mouse is moved over the network timing graph
• The Timing tab on clicking the request (as in the 1st attachment)

We too should have something similar

• On the hover state, show in the tooltip (that should suffice)
• On the clicked state, we already have the Timings tab.

I tried searching in BMO, however couldn't find the bug, so filing it here. I've already checked the developer edition there is no such enhancement in it.

I'm willing to work on this one :)

Thanks for the report!

Yes, agree this looks like useful info to display to the user.

@Harald, any comments for this?

Honza

Absolutely, that there is no way to find out right now makes dependency analysis a lot harder.

We should also file a bug for the hover card if we don't have one yet.

Bug for the Hover card : bug 1580493

Honza

Thanks, Honza!
Let me start digging into this.

• Rutu

Honza,

I have few questions,

• the Started at ie 1.7s, it should calculated relative to which event? The timings.RESPONSE_COMPLETE.last of the very first request OR the dom.ready event ?
• How to keep tab of the first request
  • Using a closure of NetworkObserver fn, which could ensure a static like member. The above event will trigger it to be true, and that member's response_complete.last or dom.ready would be considered epoch.
  • Or is there any other place for me too look ?

Rutu

Added queued at time in TimingsPanel

This is a WIP queued at UI

@Ruturaj: there is a dup report of this feature where I was posting detailed instructions how to fix it.

Please look at the following comments:

• https://bugzilla.mozilla.org/show_bug.cgi?id=1471249#c4
• https://bugzilla.mozilla.org/show_bug.cgi?id=1471249#c8

Honza

Just adding Honza's comments from bug#1471249

Thanks for the report!

Some instructions for anyone interested in fixing this bug:

The Timings panel is represented by TimingsPanel component and is rendered here
https://searchfox.org/mozilla-central/rev/97976753a21c1731e18177de9e5ce78ea3b3da2d/devtools/client/netmonitor/src/components/TimingsPanel.js#96

All timings data are accessible form props using this.props.request.eventTimings
https://searchfox.org/mozilla-central/rev/97976753a21c1731e18177de9e5ce78ea3b3da2d/devtools/client/netmonitor/src/components/TimingsPanel.js#103

There is also RequestListColumnTime component (used for Timings columns: Start Time, End Time, etc.) showing how to calculate relative times (relative to the first top level document request)
https://searchfox.org/mozilla-central/rev/97976753a21c1731e18177de9e5ce78ea3b3da2d/devtools/client/netmonitor/src/components/RequestListColumnTime.js#54

I believe that queued time corresponds to Blocked time start and Started to Blocked time end.

Honza

We need to calculate two values:

Started - time relative to the first request start time (so, the first request has start time 0)
Queued - time spent in the internal browser queue (the number of concurrent connection is limited so, in case of many requests done by the page some need to wait)

Here is a place showing how we can get the start time of the first request firstRequestStartedMs
https://searchfox.org/mozilla-central/rev/3300072e993ae05d50d5c63d815260367eaf9179/devtools/client/netmonitor/src/components/RequestListContent.js#422

We need to implement the same connect method in the TimingsPanel to get the same property
https://searchfox.org/mozilla-central/rev/3300072e993ae05d50d5c63d815260367eaf9179/devtools/client/netmonitor/src/components/TimingsPanel.js#167

Don't forget to also update the list of props just like the RequestListContent does
https://searchfox.org/mozilla-central/rev/3300072e993ae05d50d5c63d815260367eaf9179/devtools/client/netmonitor/src/components/RequestListContent.js#78

Here is the place in TimingsPanel where we are reading props
https://searchfox.org/mozilla-central/rev/3300072e993ae05d50d5c63d815260367eaf9179/devtools/client/netmonitor/src/components/TimingsPanel.js#97

And here is the calculation:

const { eventTimings, totalTime, startedMs } = this.props.request;
const relativeStartedMs = startedMs - this.props.firstRequestStartedMs;
const queuedMs = eventTimings.timings.blocked;

Honza

https://hg.mozilla.org/mozilla-central/rev/afe9af7c0dd5

Would it require update to docs? https://developer.mozilla.org/en-US/docs/Tools/Network_Monitor/request_details

Yes, Karen can help with that.

Doc changes are being tracked in https://github.com/mdn/sprints/issues/2469

Thanks, do let me know how could I be of your help.

I've documented this feature; see https://github.com/mdn/sprints/issues/2469#issuecomment-570169504 for the full details.

Thanks Chris!