I did this as well to make http://developer.piwik.org faster:

    var _paq = _paq || [];
    _paq.push(["setCookieDomain", "*.piwik.org"]);
        _paq.push(["trackPageView"]);
    _paq.push(["enableLinkTracking"]);

    function track() {
        var u=(("https:" == document.location.protocol) ? "https" : "http") + "://demo.piwik.org/";
        _paq.push(["setTrackerUrl", u+"piwik.php"]);
        _paq.push(["setSiteId", "siteid"]);
        var d=document, g=d.createElement("script"), s=d.getElementsByTagName("script")[0]; g.type="text/javascript";
        g.defer=true; g.async=true; g.src=u+"piwik.js"; s.parentNode.insertBefore(g,s);
    }

    if (window.addEventListener) { window.addEventListener("load", track, false); }
    else if (window.attachEvent) { window.attachEvent("onload",track); }
    else {
        track();
    }

@tsteur you shouldn't need the IIFE inside of track. It's superfluous because the track function is already providing the lexical scope.

True, changed it. It was implemented a bit different first and then just copied into the track function :)

tentatively adding to 3.0.0 milestone - it would be a nice improvement to have 👍

there's now a slightly bigger chance of piwik not tracking it. But I think speed is more important than accuracy.

??
are you sure with this?
imho: Piwik is tracking software so it's main task is correct tracking.
Speed is optional (but of course highly desired)

@hpvd yes, I'm sure that my pages appearing to load as fast as they'd without piwik is more important to me than 100% accuracy. If you want 100% accuracy, you might end up with the opposite effect: you'd lose some users who're dissatisfied with your site's performance, and you'd have a perfect measurement of the ones with patience.

It's basically the web version of the observer effect.

@pekeler thanks for your answer.
Sure you can do it this way if the statistics you get from are good enough for your needs.
There are two problems when actively deciding nto to track a part of visitors and doing it not very carefully:

1. of course you do not know what these visitors did,
2. but even more worse you may not even know how many visitors, pageviews and actions you miss.
   => to put it bluntly: in consequence you have done statistics but they did not match reality.
   So they are not suitable to make serious (e.g.business) decisions for the future based on these numbers.

One can decide to do it this way, but it should not be standard solution in Piwik.

I guess the point is with correct server setup etc you can have your piwik.js served from the cache, track all users including at once that leave your page early and at the same time piwik.js will be reloaded automatically once the file was changed.

There are different caching strategies possible which can be all configured server side and depends on how the file/tracking code is included into the page.

For example if someone wants aggressive caching for best page load speed (which is critical for some websites / shops) they can do that and they maybe don't mind if it takes a while until a new version to piwik.js is rolled out to all users. Usually we don't have too many critical changes in piwik.js but happens. Someone else might setup the server with a little bit less aggressive caching and the file will be still updated/reloaded automatically once the file is changed. This will be still faster and work better than having another tiny file that loads correct version. That's what caching headers exist for :)

We recently documented this in our blog post:

• Performance optimizations you can apply today to load the Piwik JavaScript tracker faster

• Different ways of embedding the Piwik tracking code for faster website performance

And in the FAQ:

• How do I improve my website pages load time and speed and minimise Piwik JavaScript Tracker performance overhead?