The Server Timing API allows you to pass request-specific timing data from your server to the browser via response headers

Potential uses

In IPFS context, it could be a way for HTTP Gateway to indicate how long it took to

• execute specific subtask of /api/v0/ call
• return valid data for /ipfs/* request, namely:
  • lookup data in local datastore (if present) or find it on the swarm
  • discover providers (could have separate metrics for dht, bitswap)
  • download data from providers etc

Improved debugging

As illustrated by @Gozala in ipfs/ipfs-webui#1534 (comment)
I think bifrost team and other gateway providers could leverage it for debugging gateway performance when processing a specific request.

Improved UX in browser context

User agents (eg. IPFS-aware web browser) could utilize hints passed in Server Timing headers to improve user experience by providing higher resolution feedback about the state of request.

Example

> GET /ipfs/QmFoo HTTP/1.1
> Host: ipfs.io


< HTTP/1.1 200 OK
< Server-Timing: miss, ds;dur=53, dht;dur=47.2, bitswap;dur=120
< Server-Timing: cache;dur=23.2

References

• https://web.dev/custom-metrics/#server-timing-api
• https://w3c.github.io/server-timing/