You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
One recurrent thing that people have mentioned in 1:1 conversations is performance metrics. Something that tells them if they are doing ok or not. We already have the performance budget hint but we could expose more information.
This is what I'm currently thinking:
The tracing information depends on the connector used. Chrome will use the Tracing domain from the debugging protocol, Edge the Windows Performance Toolkit, jsdom I'm unsure (metrics from request + some tracing from node?`), etc.
Because of the above, we can't just send the trace from each connector to a general trace parser.
With that in mind we have a few options:
Each connector "normalizes" the trace and emits something that is understandable by any related hints
We have several parsers (one per type of trace). Each connector emits specific events (e.g.: trace::cdp::end), and then the parser transforms it into something understandable by any hint. This is more or less the previous one but using parsers and with the possibility of reusing it for other connectors (especially CDP if we end up doing Check targets before passing them to the engine #35 and Fix linting issues and update some of the rules #36), but we could always put it inside the common utils of cdp or have another package and not have the overhead of sending events that probably will just slowdown taking into account the size of the traces.
My preferred option for now is 1 and if we need then extract to a different package.
@webhintio/core thoughts about this?
The text was updated successfully, but these errors were encountered:
One recurrent thing that people have mentioned in 1:1 conversations is performance metrics. Something that tells them if they are doing ok or not. We already have the performance budget hint but we could expose more information.
This is what I'm currently thinking:
Tracing
domain from the debugging protocol, Edge the Windows Performance Toolkit, jsdom I'm unsure (metrics fromrequest
+ some tracing from node?`), etc.trace parser
.With that in mind we have a few options:
trace::cdp::end
), and then the parser transforms it into something understandable by any hint. This is more or less the previous one but usingparser
s and with the possibility of reusing it for other connectors (especially CDP if we end up doing Check targets before passing them to the engine #35 and Fix linting issues and update some of the rules #36), but we could always put it inside the common utils of cdp or have another package and not have the overhead of sending events that probably will just slowdown taking into account the size of the traces.My preferred option for now is 1 and if we need then extract to a different package.
@webhintio/core thoughts about this?
The text was updated successfully, but these errors were encountered: