Change Details

Especially the `isCompliant` check I'd prefer to have in the backend so that there is less burden on the client (for an unlikely scenario), and also so that our raw throughput is not affected by it. This also allows us to improve and change the compliancy check without having to roll it out for everyone at once (similar to how we are doing with the navtiming2 experiment right now).

Especially the `isCompliant` check I'd prefer to have in the backend so that there is less burden on the client (for an unlikely scenario), and also so that our raw throughput is not affected by it. This also allows us to improve and change the compliancy check without having to roll it out for everyone at once (similar to how we are doing with the navtiming2 experiment right now). ------- From T190977: When we move the `isCompliant()` filter to the server, let's also improve its instrumentation to be more details. E.g. In addition to incrementing the `nonCompliant` counter, we could also log to navtiming's stderr an log message more details about the issue (eg. browser, version, property).

Especially the `isCompliant` check I'd prefer to have in the backend so that there is less burden on the client (for an unlikely scenario), and also so that our raw throughput is not affected by it. This also allows us to improve and change the compliancy check without having to roll it out for everyone at once (similar to how we are doing with the navtiming2 experiment right now). ------- From T190977: When we move the `isCompliant()` filter to the server, let's also improve its instrumentation to be more details. E.g. In addition to incrementing the `nonCompliant` counter, we could also log to navtiming's stderr an log message more details about the issue (eg. browser, version, property).