Page timings in low-code platform (single-page application)

[Jeroen]

Hi,

I’m trying to get helpful performance metrics (page timings) insights of my Mendix application. Mendix is a low-code platform compiling to a single-page application meaning I only have 1 URL. Now, I would like to achieve 2 things:

1. Send every page to Piwik Pro
2. Use the page timings to measure DOM loading / time to interact for each page

So far I have not been able to achieve the first step with the documentation for auto SPA or even manual SPA How can I track a single-page application (manual method)? | Piwik PRO help center. Is there someone who has any experience in this field?

Thanks in advance.
Jeroen

[kuba]

Our solution for automatic SPA tracking uses browser’s history API. If you have consent manager implemented, make sure that you have proper consent for tracking - it won’t work without that.

[Jeroen]

Hi Kuba,

Thanks for your reply. I have SPA tracking enabled using a:

• Custom variable (document title)
• History change trigger (SPA)
• Virtual page view with the trigger enabled

I’m getting page views in but no specific document titles. I’m currently trying out different configurations in the virtual page view setup using {{ Page URL }} and {{ History Fragment }}. I haven’t found the correct setup yet. Any suggestions?

[kuba]

Do you have this setting enabled?

Sometimes the document.title is a bit delayed, so we have to wait for the variable to be set.

[Jeroen]

Yes we have this enbaled. Any other idea?

[kuba]

Is document.title set to the previous URL or doesn’t work at all? How did you implement routing in your SPA app? How is the variable for page title defined?

[Jeroen]

It’s hard to tell if Mendix sets the document.title correctly inside the history object of the browser (see screenshot).

Where is Piwik expecting some value inside the history object? Can I use the state.path as a trigger?

[kuba]

Is the document.title set to some older value (previous page view) or not set at all? I guess there are no problems with the URL since it’s something available directly through History API.

[Jeroen]

When I switch pages, thedocument.title is changed.

[kuba]

Thanks for that. I just realized that I missed the most important part from the first post. Since your app is served under one URL, our SPA solution and history change triggers wont work. Do you think that it’s possible to update the app so that the URLs are updated in line with the state.path?

[Jeroen]

Sadly that’s not possible out of the box. Is there any other way to trigger a page change automatically with Piwik? Note that our main goals is to get insights in end user performance (DOM loading and time to interact)

[kuba]

To have a full control, the best option is to publish datalayer event every time the page url changes. This datalayer event would contain the current url and page title as variables.

Example structure:

<script>
  window.dataLayer = window.dataLayer || [];
  window.dataLayer.push({
    'event': 'pageview',
    'page_title': 'yourtitle',
    'page_url': 'https://domain.com',
  });
</script>

The only issue with this solution is fact that those events have to be published by the frontend app.

Regarding page timings, we did recently some research on that and it turns out that measuring performance of SPA is a totally different topic than the standard full page reloads. Comment from our dev team:

There is no automatic way to gather that (page performance metrics) like in the traditional page load scenario. SPA can handle virtual page loads in many different ways and it’s defined by developer in JS, so all we can do is provide developer with a way to time any arbitrary process he wants to monitor and add it in statistics. This would require good documentation to explain how to use such a tool and rework in the analytics reports for page performance (to add arbitrary loading metrics in addition to the standard ones we use already).

I’ll fill a feature request to bump the priority of this task.

[Jeroen]

Hi kuba and dev team,

Thanks for the time you spent on this topic. I agree with the dev team that it becomes very hard to determine the actual page loading / time to interact with a page when applications start using different ways to load pages and data. That having said, I’ll implement some custom JS when an action is triggered and try to capture when the actual page is loaded.