Similar to how we used to have setGenerationTimeMs.

We then need to document this in https://developer.matomo.org/guides/spa-tracking similar to how the other method used to be documented. Also of course need to document the JS Tracker reference etc.

We'll also need to adjust in JS tracker the logged console message in the setGenerationTimeMs method and mention to use this new method instead or maybe we can even somehow map setGenerationTimeMs to the new method but likely this wouldn't make any sense. Same in developer changelog need to adjust the text where we mention the setGenerationTimeMs removal.

@sgiehl feel free to close if we already have an issue for it. Couldn't find it.

It's to be seen how this makes sense because some performance metrics might not really make sense in SPA etc. Eg whether we have only one method and by default all metrics will be reset except the ones specified or whether we have individual metrics (but then the problem be that other performance values aren't reset and reports would become wrong).

We need a new JS tracker API method to set these Performance Tracking HTTP API parameters. A name could be for example setPagePerformanceTiming(networkTimeInMs, serverTimeInMs, ...) and then the related tracking API parameters should be appended in the next tracking request. Basically users should be able to call eg _paq.push(['setPagePerformanceTiming', 35, 103, ...]). As far as I know all the parameters should be optional and if no value is set, then we won't send the related tracking parameter.

When someone sets the custom page performing timings, then we don't detect the timing ourselves.

The new method needs to be documented in https://developer.matomo.org/api-reference/tracking-javascript

Any set value will be sent along the next tracking request and then the configured values are reset so that the same values aren't sent in any following tracking request after that.