@indeyets opened this Issue on February 13th 2019

Matomo tracker-code itself is loaded asynchronously, but the problem is, that sometimes JS is loaded fast and is executed before document is ready. JS calls piwik.php to be loaded as a GIF file which, somehow, blocks execution of other JS on the page.

I saw this in high-load scenario when database was overloaded and answered really slow:

  1. page loads
  2. matomo is loaded asynchronously
  3. banners-code is loaded asynchronously
  4. matomo starts loading piwik.php as a GIF
  5. (~20 seconds paus)
  6. banners are rendered

I was able to mitigate this by delating matomo initialisation till page's onLoad event.

It would be much better if matomo delayed image-call until onLoad instead. this way matomo code would be up and running earlier, gathering info, but it still wouldn't lock execution of other js-code.

I did my tests in Google Chrome 72

@tsteur commented on February 13th 2019 Member
@tsteur commented on February 13th 2019 Member

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).

@indeyets commented on February 13th 2019

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

@tsteur commented on February 13th 2019 Member

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 ...

@indeyets commented on February 13th 2019

@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

@tsteur commented on February 13th 2019 Member

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.

@indeyets commented on February 14th 2019

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

@tsteur commented on February 14th 2019 Member

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.

@tsteur commented on February 24th 2019 Member

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

Powered by GitHub Issue Mirror