[Bug] `setLinkTrackingTimer` does not influence delay if sendBeacon is used

[LeoniePhiline]

What happened?

Matomo caused our Interaction Next Paint (INP) timing statistic to be longer than the 200ms deemed acceptable by Google, which resulted in downranking in Google search.

Trying to counter #21297, we set setLinkTrackingTimer to 0. It is described as:

When a user clicks to download a file, or clicks on an outbound link, Matomo records it. In order to do so, it adds a small delay before the user is redirected to the requested file or link. The default value is 500ms, but you can set it to a shorter length of time. It should be noted, however, that doing so results in the risk that this period of time is not long enough for the data to be recorded in Matomo.

Source: https://developer.matomo.org/guides/tracking-javascript-guide#changing-the-pause-timer

However, the delay when the browser’s “send beacon” is used is hard coded to 100ms and not lowered by setting the link tracking timer.

What should happen?

The 100ms hard coded delay should be reduced to the value of configTrackerPause, if the latter is set shorter. I.e. use delay for legacy tracking requests and Math.min(delay, 100) when using send beacon.

Alternatively, the 100ms delay should be removed entirely, since “send beacon” exists precisely for reliably sending beacons at unload, without requiring any artificial delay.

How can this be reproduced?

1. Configure:

window._paq.push(['setLinkTrackingTimer', 0]);
window._paq.push(['enableLinkTracking']);

2. Find that the 100ms delay still applies. This means that the configuration is not effective. This is the bug.

3. Optionally inspect the JS source code and find that the delay argument to the send request and send batch request functions is not used when use of send beacon is enabled.

Matomo version

5.1.2

PHP version

8.3

Server operating system

Debian 12

What browsers are you seeing the problem on?

Firefox, Chrome, Safari, Microsoft Edge

Computer operating system

All

Relevant log output

No response

Validations

• [X] Read our Contributing Guidelines.
• [X] Follow our Security Policy.
• [X] Check that there isn't already an issue that reports the same bug to avoid creating duplicates.
• [X] The provided steps to reproduce is a minimal reproducible of the Bug.

[LeoniePhiline]

I have been playing with Chrome's dev tools script content override feature to mimic a patched matomo.js.

Changing the existing minified cv(100), which corresponds to the unminified setExpireDateTime(100), to cv(0), then sending the beacon is not entirely reliable.

With cv(0), sometimes profiles only show the page load, but not the beacon being sent:

However, setting cv(10) (= setExpireDateTime(10)) was enough to make sure the beacon is sent reliably:

Thus, while some delay seems required for a reliable beacon, 100ms might be more than Matomo users are willing to pay for it.

Therefore, I believe that applying Math.min(configTrackerPause, 100) to setExpireDateTime (minified: cv(Math.min(bW,100))) in the context of sendBeacon-enabled browsers is the right way to go, as it allows users to configure for shorter than 100ms delays.