1421576 - Add telemetry probes to track inspector relevant website metrics

Status: NEW

(DevTools :: Inspector, enhancement, P3)

Description

[Julian Descottes [:jdescottes]]

In addition to the time-based probes we added to the inspector (eg. toolbox reload), it would be nice to get an idea about the average complexity of the websites used with the inspector. 

We could gather information about:
- number of DOM nodes
- number of expanded nodes
- complexity of the tree
- number of frames
- number of stylesheets
- ...

This would help us design more accurate test pages for our performance benchmarks.

Comment 1

[Alexandre Poirot [:ochameau]]

Sounds like a great idea, especially if we already have the data.
If we don't, and we have to compute it, I would be concerned about the cost of computing it.

If we could record that from the actor and the content process, actors sounds like a good place to record such information.

Comment 2

[Patrick Brosset <:pbro>]

(In reply to Julian Descottes [:jdescottes][:julian] from comment #0)
> - number of DOM nodes
The Walker actor and the markup-view only ever know about the nodes that have been shown to the user in some way. So getting the total number of nodes will require some computation. But maybe logging the max number of nodes that have been displayed when a session ends is enough. Maybe we want to know how many nodes a person played with in the inspector, rather than the complexity of the page itself.
> - number of expanded nodes
> - complexity of the tree
We'll need to define what that means exactly.
> - number of frames
I think we have this without needing to compute anything in tabActor.windows
> - number of stylesheets
We have this data easily when the style editor is used.

Comment 3

[Julian Descottes [:jdescottes]]

I agree that we should keep the performance impact limited. I see 2 options:

1 - Allow additional computing

Let's take the number of nodes for instance. A call to rootNode.rawNode.querySelectorAll("*").length takes less than 2ms on a 20K nodes page on my machine (slightly more than 2ms on a Linux VM). That's not huge but I would like to avoid doing it on init()/destroy(). 

We could start our measures after a given timeout following the inspector initialization. This prevents slowing down init/destroy, but it also filters out some inspector usage (e.g. users jumping from page to page without really using the inspector). We could even check that the user interacted with the inspector before logging those metrics.

2 - Use existing data only

We could log to telemetry without having to worry about performance impact, but we are more limited in what we can do (cf Patrick's comment above).

I think I would prefer to go with option 1 for now, let me know if you have a strong opinion against it. It makes the data more filtered than the one we get for toolbox reload for instance, so might be harder to correlate.

Comment 4

[Alexandre Poirot [:ochameau]]

(In reply to Julian Descottes [:jdescottes][:julian] from comment #3)
> I think I would prefer to go with option 1 for now, let me know if you have
> a strong opinion against it. It makes the data more filtered than the one we
> get for toolbox reload for instance, so might be harder to correlate.

Sounds fine if we only compute this while telemetry is enabled
  (Services.prefs.getBoolPref("toolkit.telemetry.enabled"))
and may be we should decide upfront that we do this only for one release and get rid of that on the next merge?

Comment 5

[Julian Descottes [:jdescottes]]

While browsing https://vaadin.com/elements/vaadin-button/html-examples/button-basic-demos, switching between nodes in the inspector was pretty slow. Everytime we change the selected element, the ruleview is rebuilt and can be quite slow. (https://perfht.ml/2DimDIu)

The stylesheets on this website define a lot of variables, and the ruleview is pretty big. It would be interesting to measure how many CSS rules per element are displayed in the inspector.