Of course after replacing it with a maintained minifier we need to test if all features still work and that the minifier doesn't use any features that are missing in ancient browsers,

This might be bit hard?

Just to understand: Is the benefit that it will result in a slightly smaller minified JS basically?

Since this is basically no breaking change for users, I would prefer to move this into the priority backlog or 4.1 or 4.2 for now to keep 4.0 as small as possible (otherwise takes much longer to work on 4.0).

Maybe a quick test be to use some modern minifier, then use the minifier we use, and see how much different the resulting JS file size is to evaluate if it's worth doing or not.

I looked into it again and tested UglifyJS3 (https://github.com/mishoo/UglifyJS2) which is the most popular minifier (used by over 4 Million github repos) for ECMAScript 5. (It doesn't support newer JS features, but it will take ages until we can support them in the tracking code anyway, so this should not matter)

uglifyjs  piwik.js -c -m eval --comments -o piwik.ugl.js

Things I noticed:

• file size is very similar (52k instead of 58k and 17k instead of 19k gzipped), which is to be expected as there isn't much more to optimize without removing things.
• it is probably easier to write a tiny .js file to call instead of using the cli as then one can specify a regex to keep important comments like pluginTrackerHook
• it supports sourceMaps, so one could debug tracking in production as the browser developer tools can reverse the minification with it
• the current minifier removes the "use strict" line, which might have had weird concequences.
• I did not have time yet to test the output, but it should work fine.

fyi @rr-it Opened a PR and an issue in #20964 to suggest a new compiler 🙌