[DX][D9] Telemetry: gather Server Timing performance metrics

[klonos]

This is part of the #285 meta.

Description of the need

Respective d.org issue: https://www.drupal.org/project/drupal/issues/3104566

Providing server timing would help developers estimate site performance.
The corresponding W3C specification is currently in "Working Draft" status and its already supported by Google Chrome and Firefox.

https://www.w3.org/TR/server-timing/

This specification enables a server to communicate performance metrics about the request-response cycle to the user agent. It also standardizes a JavaScript interface to enable applications to collect, process, and act on these metrics to optimize application delivery.

Symfony adopted it in symfony/symfony#27985

Proposed solution

Add Server-Timing header with relevant timing information.

[philsward]

Curious, would this be collected to show to the site admin for their benefit, or collected to get a better idea of metrics to see how well BD is running on various platforms

I can see where it might be beneficial but also useless due to the sheer number of variables that play into performance metrics. (Hardware used, OS used, DB used, actual configuration of all of the above, etc.). The reported software might all be latest and greatest, but that will still impact performance if the server hardware isn't fast. Mechanical drives on RAID5 vs RAID10 NVME drives for example.

So, one idea is to collect the info and then aggregate the data to show a site admin: Your site ranks [here] in performance when compared to other backdrop sites. It might show someone that their hosting isn't all that great in comparison. Some (affiliate?) links could be displayed to better hosting platforms if they are below a certain threshold.

As a side thought, if it were me, I would move this data (performance) into the "b.org dashboard" idea I've thrown out in other issues so all site info is viewable from one central place and b.org can monetize larger firms that need to keep up on this info. A hobbiests blogger paying out of pocket for hosting probably won't care as much about this info.

Point is, if we're going to benchmark performance, let's make sure we have a usable reason to collect and display it. Otherwise we end up with data that won't have much context. I'm all for the request, I just want to make sure the time spent to implement this request goes to good use.

[quicksketch]

I don't see how this something that we could report back to BackdropCMS.org through Telemetry and perhaps we should remove it from the meta issue at #5231.

From the looks of the specification, this is a per-request header, so the amount of time that will be returned will change for every possible request. Doing things like loading the /admin/modules page or saving a node will likely take a lot more time than returning a cached page.

I think this issue is still a good idea to pursue, we would essentially be taking the page timer and SQL query timers from Devel module and returning them as headers instead. It might also be reasonable to just implement this in Devel only, since it's already collecting a lot of useful information that could be exposed in different ways.

[ghost]

I vote for removing from telemetry and moving to Devel instead.