See https://matomo.org/blog/2017/04/different-ways-embedding-piwik-tracking-code-faster-website-performance/ that maybe helps? Let me know if anything needs to be done.

If you use the content tracking feature, you can also just load the tracker regularly (to track as many pageviews as possible), and onload for example call the tracker method trackAllContentImpressions again (so far we only execute it onReady).

Thanks @tsteur. I did something like this already. But this is suboptimal. Matomo could act better in this regard by queueing requests until DOM is ready.

This issue was not a question or request for help. I believe code should be fixed to handle these situation better

Not sure exactly what you mean? From your message I assume you are using content tracking? So we could check for new content impressions onLoad ...

@tsteur first blocking request is a tracking pixel. Pageview I believe. Content tracking happens later on

Anyway, what I mean is: default configuration of matomo should not block normal page loading process. No matter if matomo server is under load or slow for another reason. UX should not be harmed.

One way to achieve this is to delay any network requests from piwik.js until page's DOM is in "ready" state

Anyway, what I mean is: default configuration of matomo should not block normal page loading process. No matter if matomo server is under load or slow for another reason. UX should not be harmed.

Some would for sure argue differently but for sure UX is key :)

One way to achieve this is to delay any network requests from piwik.js until page's DOM is in "ready" state

So far it's sending it right away. You could influence it though basically by just putting the JS code at the end of the DOM </body>? When loaded async and deferred the Matomo footprint should be tiny.

You could influence it though basically by just putting the JS code at the end of the DOM

sure, I could. but that's a workaround that should be done by me again. I advocate for robust behaviour on matomo side so that users are not forced to think about it.

Compare this with google-analytics which works just fine in similar scenarios.

@tsteur I really believe this is a bug in matomo

I'll reopen it for now. UX definitely is more important than anything else these days. At the same time delaying the tracking request to onReady is not going to do too much. Because when you load the piwik.js everything will be already parsed and loaded etc. and all you save is a wee tiny request.

BTW: When the script is loaded defered as suggested in our default code, it should maybe also execute only after the page is parsed?

Compare this with google-analytics which works just fine in similar scenarios.

It would be interesting to know what logic GA uses to not experience this issue?

GA uses service workers and postpones everything after load afaik

Source: https://developers.google.com/web/showcase/2016/service-worker-perf