Add ServerTiming Headers

[barryvdh]

See https://ma.ttias.be/server-timings-chrome-devtools/

Would it make sense to make an interface to add headers, if other collectors would want to do that?

[james-johnston-thumbtack]

Would it make sense to make an interface to add headers, if other collectors would want to do that?

I think this seems like it would be the right/generic way to do it, although admittedly I cannot think of any other use cases at this moment - but we still have lots of collectors we'd like to write, so I can't say it would never come up...

See https://ma.ttias.be/server-timings-chrome-devtools/

An interesting first attempt at server timing protocol.... but limiting (as you already noted on Twitter). :( The inability to specify a start time means that we can't send back a rich timeline like how the debug bar itself renders this collector. And you're subject to the limiting HTTP header size limits, so if you're collecting more than a few items or items with long descriptions you could be in trouble: e.g. large numbers of database calls collected with PDO collector. (Not to mention the end-result on DevTools would be an unintelligible mess, since there's no start time / duration.)

I think with some UI improvements, the time collector front-end widget in our debug bar could be more useful for sorting through large numbers of measurements. (e.g. filtering by application-specific measurement type, showing only long-duration measurements, things like that). Having it send back these HTTP headers that are limited in size/usefulness would be even more of a constraint, because they just couldn't handle the amount of data.

To conclude, I think we'd be better to accumulate / aggregate timing information separately for the ServerTiming headers, if we really want to do that. So e.g. the time collector widget can show detailed timeline for database calls, but we only send a sum/total of database call time for ServerTiming header - leading to an end result that is similar to the screenshots. (Although I don't think I would use this feature much, when I have full power of the debug bar as an alternative!)

[barryvdh]

An alternative could be to only send it back when the debugbar is not injected. For example, when I create APIs with a JS front-end + PHP back-end, I can't see the debugbar, but I can see the network requests there. I agree that usually, the headers would be less informational then the actual debugbar.

[james-johnston-thumbtack]

For example, when I create APIs with a JS front-end + PHP back-end

This is not a scenario you can use the AJAX debug bar feature for? We've been successfully using it on some of our single-page application pages...

[barryvdh]

I do use that when calling Ajax from our php app, but not when it's a standalone js app

[james-johnston-thumbtack]

I do use that when calling Ajax from our php app, but not when it's a standalone js app

Ah, that makes sense. Sounds like we need some way of embedding the debug bar in that scenario for the purpose of listening to AJAX calls... it would be initially empty...