Performance with Matomo for wordpress: how to speed up

Hi @doolyo

The solution would be indeed to use Matomo On-Premise. The same speed in the plugin is not reachable because we always have to bootstrap the entire WordPress and for example depending on amount of plugins this can take a bit of time.

Regarding the request, we’re using sendBeacon by default whenever possible and we don’t require an answer back when it’s supported by the browser (which most browsers do).

Regards

Mat

Thank you for that in-depth explanation, I better understand now why it is slower.
This is very sad but good to know.
I hope that you would be able to come up with an optimized solution for wordpress.

Why not trying to just put the browsing data in a new caching database table that records only the page from which it was called, with everything else you need inside?
And then, using a hourly cron on wordpress, update all tables as they must, through this caching table.

This way, the call of the sendBeacon would be almost immediate, and all the timing would be handled at another time, with bootsrtap beind already made and hence reducing even the CPU load as the bootstrap is done only once per hour rather than at each request.
You could also simply divide the number of cache entries by 1 hour to get the sleep time between two requests, so that it would lower the CPU load over time.

Hi @doolyo ,

thanks for the tips for performance improvements. It works that way since Matomo for WordPress is mostly intended for small websites with less traffic and performance is usually not super critical. Since there is an alternative with Matomo On-Premise already there we don’t go through the effort to also optimise Matomo for WordPress for ultimate performance. This of course can change in the future. Generally, by not optimising it helps us having it work on all WordPress installations out of the box without any issues. As you know WordPress powers most website and runs on millions of differently configured servers and installations and by bootstrapping WordPress every time we can ensure that things work without issues.

If you already have a running WordPress, Matomo On-Premise should be fairly easy to install and is quick to maintain (update). If you want even faster performance for On-Premise, there is our Queued Tracking feature which effectively does what you are after to make things blazing fast (4-5ms for us per request). This however wouldn’t be as effective in Matomo for WordPress since we’d still bootstrap WordPress every time which is the slow part.

Hope this helps @doolyo

Thank you very much for your explanations, I understand the reasons, compatibility is really important I agree.

So I installed Matomo On-Premise, and yes, it is much much faster. I get usual times of 70ms rather than about 400ms. Also the maximum I saw with Matomo On-Premise is about 300ms instead of 2500ms with Matomo for WordPress. This is a very big improvement, and is enough for me.
It is really fast and I must say that I really like it. It makes the usage of Matomo almost transparent, which is really nice. Also the “WP-Matomo Integration plugin” makes it easy to interact with Matomo On-Premise from WordPress, it is really well made and very useful, so we almost have the feeling that we use Matomo directly from WordPress.

Thank you for the proposal of Queued Tracking feature. I tried it already under WordPress but it was not working.
It seems quite complicated to setup:
– It seems Redis is needed, I don’t know what that is
– Also I do not have cron jobs available on my hosting plan, so I think I cannot use it.

By the way, I have created an Apache RewriteRule which allows hiding the real Matomo On-Premise real directory, and provides a “fake” address so that the Matomo directory is free from hackers: they won’t even be able to find out what directory to hack (put a complicated one).
This is the line to put in the .htaccess file:
# Hide real directory of Matomo On-Premise
RewriteRule ^matomo123/matomo\.([a-z]+)$ /real_matomo_dir_51823/matomo.$1 [L]

Then, just edit the javascript code on WordPress “WP-Matomo Integration” and modify the matomo directory on the “var u=” line to be “matomo123”.
It should make the On-Premise version even more secure.

I appreciate your satisfying suggestions you provided on that topic, thank you!

Hi @doolyo

just FYI the Queued Tracking plugin also has an option to use the existing MySQL database instead of redis and there is an option to not needing a cronjob. The option is called “Process during tracking request”.

And FYI to hide the Matomo URL we also have a dedicated feature that can be used see https://github.com/matomo-org/tracker-proxy . As you already have a workaround for it this might not be needed. But wanted to mention it anyway in case it’s useful ??

Have a great day @doolyo

Ok I didn’t know that Redis was a database I though we had to install this in any case for this plugin, this is good to know. Also it is very good to know that there is an option that allows it to work without cronjob.
Hence I could be trying it in this case even with my very little hosting plan.

Very good to know about the other hiding method and plugin to secure the matomo directory. Note that mine is just one line of code and works really well ??

Thank you. Keep up the good job!