991870 - Network performance view

Status: NEW

(DevTools :: Netmonitor, enhancement)

Description

[Mihai Sucan [:msucan]]

I've been discussing with Rob about adding a view or a new tool that is performance-oriented for network requests.

Currently the timeline view does a poor job at answering questions web devs have when they want to optimize the loading of their apps - take the example of cnet.com frontpage, gmail.com or some other complex/big app.

I wrote my thoughts and ideas here:

https://etherpad.mozilla.org/network-performance-view

Axel, Rob, Darrin: please take a look, and submit any comments/questions you have. We should also probably schedule a meeting when Rob returns from his vacation.

Thanks!

Comment 1

[Axel Kratel]

We really need websocket support, that should be pretty high on the list.

Comment 2

[Mihai Sucan [:msucan]]

(In reply to Axel Kratel from comment #1)
> We really need websocket support, that should be pretty high on the list.

True, however that's a separate effort - we need platform support and we've been pinging people.

This is about a performance-oriented view of the existing data.

Comment 3

[Rob Campbell [:rc] (:robcee)]

(In reply to Mihai Sucan [:msucan] from comment #2)
> (In reply to Axel Kratel from comment #1)
> > We really need websocket support, that should be pretty high on the list.
> 
> True, however that's a separate effort - we need platform support and we've
> been pinging people.
> 
> This is about a performance-oriented view of the existing data.

yes, separate thing. We should have some user stories for that.

Comment 4

[Kyle Simpson]

This may sorta be implied by the linked write-up, but I'd vote specifically for a variation on the loaded-resources list which specifically shows, for any given resource request, the preceding resource request (if any) that blocked it.

For example, if there's a <link rel=stylesheet> that appears after a <script src>, the stylesheet resource is intentionally blocked (IIRC) until it completes (or maybe it's the other way around?). It would nice to see a view like:

  blah.js
   |
   ----- blah.css

Where the nesting isn't about "sub requests" but about "who blocked me".

Again, I know you can kinda glean (partially) this info from a waterfall, but it's indirect and implicit. It'd be nice for an explicit view, where I can see "oh wow, that one script file is blocking four other requests, I should re-order my markup", etc.

Comment 5

[Kyle Simpson]

And btw, I argued for this same sort of data in the WebPerf WG a long while back for the resource timing spec, because they were intentionally filtering out duplicate requests. I argued that we needed a list of those resources that included dupes, so you could see for instance that your CMS loading jquery.js 4 times does only result in one network load, but the subsequent 3 <script> tags strewn throughout the markup are still creating "blocking" behavior for other resources.

AFAICT, the WG acknowledged this use-case but declined to support it in Resource Timing, and IIRC they said this was more the job of a dev-tool. :)

Comment 6

[Karl Dubost💡 :karlcow]

# browsing session

There should be a way to view an accumulated view of a browsing session. Basically some Web development choices in terms of caching (http, manifest, data storage) will make sense not only when loading one page, but once a user went through a couple of interactions including browsing, posting, etc. 

* Seeing the number of times one resource is being used.
* Identifying resources which are exactly the same (payload duplicates) but have different URIs so they are not cached properly.
* beacons overly aggressive being downloaded all the times (with the impact it creates if on a 3G or wifi)

Comment 7

[Karl Dubost💡 :karlcow]

# simulated network capabilities

Giving the possibility in the view to show differences in between what are the results for the current type of connection vs a simulated 3G network. Nothing replaces a real traffic sample, but creating simulations can be interesting for discovering some painful points.

Comment 8

[Karl Dubost💡 :karlcow]

# distribution vs timeline

It would be good to be able to create distribution graphs for latency tied to a list of which resources/domains are in the bad part of the latency graph. In that way you might be able to analyze if there are specific domains or resources creating an issue for the rest of the resources.

Comment 9

[Karl Dubost💡 :karlcow]

# Apache benchmark like

Simulating an organic traffic from the browser itself and collecting/compiling the information for the user and its impact on the resources. Additional features would be to throw some proxies into the mix for simulating traffic from different countries. The command line ab is not enough in this case, because there are plenty of interactions for resources which are triggered by the browser itself.

Comment 10

[Eric Lawrence (@ericlaw)]

(In reply to Kyle Simpson from comment #4)
> For example, if there's a <link rel=stylesheet> that appears after a <script
> src>, the stylesheet resource is intentionally blocked (IIRC) until it
> completes (or maybe it's the other way around?). It would nice to see a view

I'd assume that Firefox matches IE and Chrome by offering a lookahead pre-parser which scans for and speculatively downloads resources despite a "blocking" script.

Comment 11

[Kyle Simpson]

(In reply to Eric from comment #10)
> I'd assume that Firefox matches IE and Chrome by offering a lookahead
> pre-parser which scans for and speculatively downloads resources despite a
> "blocking" script.

I'm not necessarily talking about blocking of *loading*, but blocking of processing. That's why I said that this is distinct from the waterfall diagram, because it's not just about when something starts loading, but when something in sequence can be processed (which CAN be affected by loading but is not necessarily so -- that's why my request makes sense in THIS tool, since it *could* be about the network/cache loading).

For example, AFAICT, the request (from cache) of a duplicate <script src=jquery.js> element in the page is obviously not a network fetch activity itself, but the "request"'s presence in the sequence of all loading and processing of resources can definitely have an affect on others.

Comment 12

[Anselm Hannemann]

A filter by type and a search functionality would be great. Also a clickable link on the file paths.