Restructure metrics

[MattDodsonEnglish]

Possible improvements:

• Add component to single source metrics tables
• Include conceptual guidelines on important metrics, perhaps paraphrasing: https://k6.io/blog/ways-to-visualize-k6-results/#guidelines-to-visualize-performance-test-results
• Move tags docs to metrics collection?

[github-actions]

There's a version of the docs published here:

https://mdr-ci.staging.k6.io/docs/refs/pull/1151/merge

It will be deleted automatically in 30 days.

[ppcano]

@MattDodsonEnglish Something to consider as part of these changes:

• On the Metrics reference page, include metrics from experimental modules such as new websockets, redis, browser... This will give more visibility to these modules.

• Add a section on HTTP API, WS API, gRPC API ... that list the collected metrics for that module or link to its section on the Metrics reference page.

[MattDodsonEnglish]

@ppcano Perhaps those can happen in a separate PR? I'd like to merge this, then iterate on top. As it stands, I think even merging today is an improvement, so I'd rather do it incrementally.

Also, some comments

• On the Metrics reference page, include metrics from experimental modules such as new websockets, redis, browser... This will give more visibility to these modules.

It looks like the docs for redis and maybe browser don't have metrics yet. Need to investigate what they are.

• Add a section on HTTP API, WS API, gRPC API ... that list the collected metrics for that module or link to its section on the Metrics reference page.

I agree, I'm not sure what strategy is better:

• Duplicate the metrics. If so, it probably would be better to make a shared component to ensure that both versions stay accurate.
• Just link to the metrics. A little less convenient, perhaps, but simpler to write and less text to read.

[codebien]

Why are we adding examples for each type in this page? Isn't it better to have them in the dedicated doc for each type?

[MattDodsonEnglish]

We do also have examples in the metrics reference docs. It is indeed redundant, but I'm trying to think of how someone who's looking to make a custom metric may arrive in one of two places (here or the reference).

It's also at the end, so the most important information is at the top.

Not sure though, maybe it'd be better to just delete and remove the duplication... 🤔

[codebien]

Maybe one could be a link to the other?

[MattDodsonEnglish]

I think it's better, more efficient.

Here's a nice red diff: 7de40f7