The reports for page performance are almost ready, but there are some more adjustments needed for the tracking.

Currently all the timing data would be sent with the pageview, but that doesn't actually work, as some of the performance timings might not yet be available when the pageview is tracked. Wondering how to solve that best. As sending the page view event after the onload event was finished won't be a usable solution, I currently see two possibilities with sending the timing data later:

• try to update the (last) page view tracked with those performance timings
  That would mean we need a new mechanism to not only update a visits, but also an action. Not sure if that is currently possible at all. Maybe we would need to send some kind of identifier with the pageview so we can identify the action again when sending the timing data, not sure if simply updating the last pageview of that visit would be accurate enough
• move everything into a new log table and track the timing data together with the visitor id, page url (and maybe the page title)
  That would mean the timing data isn't directly related to a specific action anymore. The currently generated reports would still be possible, but it would for example not be possible to show the timing data in the visitor log or profile for a specific action.

@tsteur What would you prefer? Or do you maybe have a different idea? Also maybe you or @mattab have some comments or additional suggestions on the already implemented stuff (see PR description)

@sgiehl which metrics might not be available?

I actually haven't tested that through yet. But to have all metrics available in the timings api we would need to listen to the window.load event and add the tracking with a timeout of 0, so it's done when onload is finished. So depending on how the matomo tracker is included, I would say at least the onload metric won't be available and maybe also DOM Interactive to Complete, as Matomo might be executed within this process.

I would say at least the onload metric won't be available and maybe also DOM Interactive to Complete, as Matomo might be executed within this process.

We could send them with ping events, or other tracking requests if needed. Could even temporarily store data and track it on the next page view for the previous one should they visit another page but that gets too complicated. I would say we would simply document that in some cases the value wouldn't be recorded if the onload event happened yet and if they don't use the ping event or have other tracking requests. We certainly do not want to cause any extra tracking request just for that information.

Something to think about: Would we need to do anything for single page applications that track multiple page views within one page? I suppose only the first page would then get the metrics which be fine for now. Be good to not make this feature too complicated.

As for the update: I suppose either a log table or log_link_visit_action would be possible and technically allow the same features if it has an idVisit in there etc. Be great to reuse log_link_visit_action though I would say maybe (for simplicity). I suppose the update be like update log_link_visit_action left join log_action set metric = xyz where idvisit = ? and idpageview = ? and log_action.type = pageview (1 or ...)?

That might be ok as long as we only execute this query should it not be recorded yet. Meaning the tracker would need to make sure to send the metric only once and the server would only issue this query once and only if the action type is not a page view. When the metric is set in the request, and action type is a page view, then it can be recorded as part of the index.

We'll need to see what impact this update has on disk I/O later once in production. We may want a feature later to disable recording metrics after the page view was tracked to avoid this update statement and instead if user wants to have these metrics, force them to listen to the onload event for the track page view.

@tsteur ok. changed the tracking accordingly. If the metrics are already available when the pageview is tracked it will be sent with the pageview, otherwise they will be sent with the next tracking request.

should be ready for a first review. Some tests of the submodules are still failing, but the expected system files will only need an update later...

@sgiehl in

wonder if we would want an "All tables column visualisation" and then show all page specific performance metrics?
Many people will never find this though. On the other side we maybe don't want to show all of them all the time so at least they would be able to get it, should they want to.

In this screen should we explain that some metrics might not be always tracked? and link to an FAQ or so?

Ideally we would remove the new performance menu item under Behaviour and instead show below screen as part of Visitors -> Overview (below the visits overview, not as part of the visits overview sparklines)

Haven't looked at code yet otherwise or tested too much but looking good! The row evolution screen is quite cool!

@tsteur

• added a new table visualization to show the supported page reports with page performance metrics only:
  

• moved the page performance reports below the visits overview

• improved the overlay so it shows the metrics descriptions and a link to the online guide (that has still to be written, shall we create a separate issue here or in jira maybe?)
  

@tsteur I've updated the PR and all related PRs so it's no longer possible to set the page generation time. Guess this and all related PRs should be ready for a final review...

Cheers team! It's a very good geek improvement but, isn't it a bit tricky report for a target of non-techy editors? Most of all they don’t have any clue about DOM ... 🤔

fyi @sgiehl there are some conflicts, otherwise looks good

@tassoman thanks for the comment. There are inline helps that explain those metrics for those who don't understand them directly. Also the default reports will only show the page load time, which should be clear to everyone

Hi and thanks for the new feature.

I've searched for "equivalent", "corresponds", "identical" in this issue, looking for what would correspond to the old "avg generation time", no luck.

Is there any ? A client would like to be able to compare old 3.0 matomo statistics with newer 4.0 one.

Hi @AnnoyingTechnology that's unfortunately not quite possible unless you maybe built a custom plugin because the previous generation time is basically a combination of several metrics within the page performance. Sorry about that. If needed, instead of a custom plugin you could also connect to our API https://developer.matomo.org/api-reference/reporting-api and fetch the reports and aggregate this number in a script if needed. Fully aware though this might not be an option in this case. @sgiehl do you remember which performance metrics are basically equal to the previous generation time?

Assuming that most people only tracked the time the server needs to generate the page there is no value it could be directly mapped to.
The value that matches most is Latency. But that one also includes the time it took the request to reach the server.

Thanks to both of you for the clarification.
I wouldn't want to criticize a great tool that I benefit from for free. But this kinda look like an oversight.

In the case of my client, we migrated his applications to new servers, and upgraded the Matomo instance at the same time. Which prevents us from comparing the before/after performance easily.

Anyways, the new performance reports are so much better, he can deal with that !