Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Hint] Performance metrics #1634

Open
molant opened this issue Sep 7, 2018 · 0 comments
Open

[Hint] Performance metrics #1634

molant opened this issue Sep 7, 2018 · 0 comments

Comments

@molant
Copy link
Member

molant commented Sep 7, 2018

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:

  1. Each connector "normalizes" the trace and emits something that is understandable by any related hints
  2. 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?

@molant molant self-assigned this Sep 7, 2018
@molant molant transferred this issue from webhintio/rfcs Jan 8, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant