Closed Sebobo closed 4 years ago
I like it! beside some lint issues and naming discussion i thing this might be good to go once some documentation is adde @Sebobo ! Thanks for this!
Thx!
Yes this was just the first draft and I wanted the feedback whether the direction makes sense. I will change the naming.
I also want to add the actual application time incl. bootstrap and cache generation. Currently with a cold cache the request might take some seconds but the timings still show < 1s. This should be possible via $_SERVER['REQUEST_TIME_FLOAT']
.
Or do we have something in the Framework for that which I missed?
Also I thought about having a separate setting for enabling this header. Because I would like to always have this header but not necessarily the output in the html. What do you think?
There are several more possibilities in the specification: https://w3c.github.io/server-timing/#examples
withAddedHeader
to prevent overriding any existing one.They mention in the specification that those metrics could be used for tracking and monitoring purposes. So usually you don't want internal timing data visible to the user for security purposes. But lately I think about implementing server side tracking for the Matomo package. And there this information could be appended and worked with in the analysis.
@johannessteu ok I thinks everything regarding the specification is in there now. I added more configuration options and changed the naming.
I'll have a look into the ci issue and merge it afterwards :)
Did you have a change to check the CI issue?
Moved over to #93
This header will create additional output in the browser dev tools. Each timing will be added as entry in the timings tab and helps devs to understand which part of the app took how long.
Initially it will provide the duration of the request process, fusion rendering time and sql execution time.
But via the DebugService additional timings can be added by the dev.
Example: