After updating piwik to version 3.0 i have observed that my site sometimes loads much slower and today i discovered why.
It seems that piwik takes up to 1.5-1.7 seconds to finish uploading its bytes of info on pages with ecommerce products.
That is, on most pages of my site piwik.php is done in 3-400 ms.. Kinda much, but that`s the way it goes. But on pages with products (woocommerce) it takes anywhere from 1.3 - 2 seconds!!! I worked so hard to optimize the site to make it load very fast, 2 seconds latency due to piwik is huge.
Checked this today tens of times to be sure, piwik.php is definitely 3-4 times slower on those product pages, and there must be a reason. Also, this is surely something new, related to latest version.
If it matters, subsequent uploads to piwik due to pings are 200-300 ms, regardless of page.
See attached images with 2 example, normal page vs product page and the difference in time.
While it shouldn't be that slow, the request also shouldn't slow down your site as it is loaded asynchron.
It is slower, i know the difference between asynchronous and synchronous and i have many years of experience as sites owner.. in my oppinion loading process is slower i believe due to "ttfb" (most of piwik.php time is in ttfb) and not talking only about the "still loading" icon while u can see the site or most of it, thanks to asynchronous loading.. althought, many clients are waiting for the site to be completely loaded before clickcing or scrolling, is psychological i guess...so,on most pages site is all done in 2.4-2.5 seconds.. while in pages with product 4-4.5 seconds
@Glisse1 can you click on the resource and show exactly where the time was spent? It should show time for ttfb, waiting time etc.
We will for sure need to profile orders as it should never take 1.5 seconds. Ecommerce tracking requests are not much different to regular tracking requests so in theory they should take about the same time. Is this a cart update or a tracking order?
I quickly profiled ecommerce orders and cart updates and performance seems to be fine. It may be related to the amount of data but it shouldn't be too big of a problem there. What are you tracking on product pages? Are you using any other plugins?
Are the scheduled tasks sometimes triggered while tracking? Might that be a cause why a (single) request could take a bit longer?
could be an issue indeed
Hello, thx for comming back on this!
As i said above, on pages with products piwik.php is in the waiting for first byte state for 1 point w/e seconds. This happens even on subsequent reload, tho sometimes it is faster. Something like out of 10 reloads, 8 are with 1.5 sec TTBF while 2 are faster, or w/e. Thing is, nothing is updated or triggered, no cart update, no order, just plain loading or reloading. On pages with no product piwik.php is always all done in 2-300 ms, never more. About triggered scheduled task that @sgiehl suggested, i dont think this is the case because this is not happening sometimes. Is always, is recurrent, scheduled tasks should maybe kick in just sometimes? But I am no programmer man, dont know :D
Added screenshot as requested with details.
If u want to sometime look on site live u can do it here. In menu bar product pages are under "PRODUSE" label, everything else are non-product pages..
I had a quick look and also noticed a 2second request on the home page:
I clicked through several pages and then noticed later there are often slower requests on product pages and faster tracking requests on other pages. It always tracks the same information so for Piwik those requests should always take about the same amount of time.
I then noticed on product pages it does a WooCommerce "get_refreshed_fragments" just before the tracking requests. The more they are executed in parallel, the slower the Piwik request is. I presume you have Piwik and WooCommerce running on the same server? It looks like WooCommerce is in this case slowing it down.
When there is no such requests Piwik tracks fast. I would recommend to maybe put Piwik on a different server or to check if you can optimize WooCommerce performance. I will close this issue but feel free to reopen if this is not the case
ok, i will not opened again, but also wont open more tickets with bug reports if " _I presume you have Piwik and WooCommerce running on the same server__".. what would u expect ppl to do, put every service providers on different servers, or what? one server for facebook link page, one server for piwik, one server for google s remarketings, one server for chat provider,, etc? be serious :)
woocommerce is working fine and had always been in the past 3 years, piwik was working fine in past years but not anymore.. u can of course close any tickets and deny this, ur choice of future product development.
PS: my hompage is not in ttfb for 2 seconds as u state. NEVER. Or maybe in just some strange accidents. Also, piwik.php is done in 154 ms on home page as opposed to 1.5 seconds in product pages.. Not sure why would u make that statement that in my homepage is in TTFB for 2 seconds, as this is not true. I know my site.
In my case it was 2s for sure. Also please be aware that I spent half an hour for free in my free time to investigate your issue. Piwik by itself runs fast but when running multiple services on same server or when having lots of traffic you simply need a good server that can handle this traffic. If you want performance, and not have several servers, maybe consider getting a faster server. In most cases Piwik tracking requests take 100-200ms, with QueuedTracking maybe 5ms. So the server seems to be simply a bit overloaded. Maybe also when there are several users on your homepage.
and i am telling u that this is something new.. i am using both piwik and woocommerce for at least 3 years...did not update woocommerce in more than 8 months preciselly to avoid breaking anything..
I am sorry for ur spare time, i really am because i know it can be frustrating to chase wild horses, but u are just starting with wrong premises:
1) i am having and paying for more than enough server resources, able to handle more than 20 times my average traffic (according to my ISP who said i am a gold customer, paying much and using very little resources) which is somewhere around 150 visitors.. PER DAY man, 150 visitors per day... i never have more than 2-3-4 concurrent users on site. No way this is an issue. Also, how come a server can be blazing fast 120 ms on most pages and 15 time slower on another type of pages. This just does not make sense is the same server with same resources?
so no, the 4 gb ram and quad-core cpu at my disposal is NEVER used more than 5 % in my host`s CP resources monitor where i can see the averages... i can give u CP screenshots with resources usage that NEVER exceed 5 % but wouldnt matter i guess.
Regardless, thx for looking on this, sadly wont be fixed. At least not until more will notice and maybe report in future, i wont do it again.
If you read my comment you can see that I said we could reopen the issue if this is the case.
I will close this issue but feel free to reopen if this is not the case
However, I can also tell that there is for Piwik no difference in those tracking requests eg home page vs a product page so it should take both the same time. I also noticed that when these 2 requests are not executed at the same time, Piwik finishes the tracking request even on product pages in under 500ms. So I recommend to have a look at all possible stats on your server. CPU is not the only bottleneck.
update woocommerce in more than 8 months preciselly to avoid breaking anything..
After posting this here I would recommend to update your woocommerce immediately for security reasons. Especially after posting the URL here.
However, I can also tell that there is for Piwik no difference in those tracking requests eg home page vs a product page so it should take both the same time
OK, u are telling me that there shouldnt be a difference, i tell (and u have seen yourself from what i understan) that there is almost a 10 times factor between the two, which is kinda a big difference, 150 ms vs 1.5 seconds.... well then just wait for more feedback and see if others are reporting this.. tho, there are online shops with 10-12 secs loading times and even more if they have tons of css and js and uncompressed jpgs, , they would not even notice a "small" 1.5 secs lag due to piwik, being that unprofessional :)
Thx and take care.
Wow, quite the discussion here some years ago. I have only been using matomo in production since this year, 2021. For context, my site is running on Wordpress, with Woocommerce. I use the plugin WP-Piwik to integrate with my matomo server (on a different host elsewhere), and the paid plugin "Woocommerce Matomo Analytics".
Tested on a clean wordpress host, and the WP-Piwik integration has no problems. BUT, when using the paid plugin, Woo+matomo, adding to cart was noticeably slower, by 1s, and checkout slower by a whopping 2.5s (I did dozens of trials for these findings). So you could argue that it is the paid plugin, but it is made by Innocraft, the makers of Matomo (I am speaking with them on this). The WP-Piwik plugin only connects Wordpress and regular interactions. Woocommerce Matomo Analytics hooks into the eCommerce functionality on a deeper level.
@Glisse1, not sure if you're still hanging around, but I absolutely agree that 150ms vs 1.5seconds is like years in Internet speed. In ecommerce, 1s lost can be thousands in the long run. I know cause I'm experiencing this very thing right now! 😅
To the maintainers, although this may be a 3 year old thread, and I have updated matomo to the latest, I can clearly see that there is an issue here. Troubleshooting this wasn't easy, as the waterfall only showed "add to cart" ajax, but simply isolating the plugins on the backend show something is going on there.
For the record, I'm not a developer, just someone moderately tech savvy. So I do not claim to have full visibility on the issue. I have experts set things up for me but they do tell me that ultimately, it's down to the software.
I also did not want to create a new thread as it always end in, "please refer to #xxxx". There's something to be optimised here. Would definitely be constructive if someone in the know could open up an issue for the masses to contribute.