Server-Timing is too limited in scope, rename to Server-Metrics

[plutora-steve-g]

Server-Timing is a one-trick pony. It would be nice if was a header that could express any server metric rather than just times, which are interesting, but only part of the story if you're trying to analyse what's going on in server-land. To that end I propose renaming SERVER-TIMING to SERVER-METRICS so it's future proof.

As an example, I've been trying to use Server-Timing to express other internal server metrics apart from just times:

db;dur=100;avg=10;stddev=5.3;count=10;sp=3;ef=7;deadlockRetries=1
cache;hit=10;miss=2;duration=100;avg=10;stddev=4.5

To me Server-Timing is client-focused, not server-focused. It's been driven from the client POV not the server POV -- duration is just one of many metrics that are useful in troubleshooting and development of a server. Exposing arbitrary metrics makes it possible to answer the question, "Why Is It Slow", which is far more useful than the statement, "It Is Slow".

[noamr]

I'm not sure there's enough steam behind renaming server timing at this point. Feel free to gather more support.

[josephwynn-sc]

I'm not necessarily voting for a rename, but just wanted to raise my hand and say that at SpeedCurve we're supporting customers sending all sorts of data through the server-timing header. It's misuse/abuse of the spec, but essentially we're allowing arbitrary numeric or string values in the desc field. It would be nice if the spec and API had first-class support for data types other than timing durations.