As performance is now a priority, I’d like to suggest something that should be investigated
Piwik’s gif image is very small. However, no content (HTTP/1.1 204 No Content) is even smaller. Saves some 55 bytes on the server responds. Not having to serve and decode the image data will speed up outputTransparentGif in Tracker.php for high-traffic instances as well.
<noscript><img>-tracking as 204-ing an img is untested territory. It would at least require to set the height and width on the tracking img itself.
We would need to investigate if all browsers can handle that. Maybe some
older browsers might show an broken image symbol if such an header is
The noscript tracking method (<1% of users, right?) should still use the gif method to avoid this (as I said somewhat unclearly in the third paragraph in my initial comment).
@dareid thanks this makes me think more of this issue. Maybe it would not be a performance improvement so much as a fixing a bug on Chrome apps? Do you know how the problem with chrome apps can be reproduced?
(basically if it's a bug then we would schedule it higher priority)
Sure please see https://gist.github.com/dareid/eaf87732c5f79e0dfef1. If you download the files and load that into chrome as an unpacked extension you will see the error in the dev console.
piwik.js? We are not the only consumer of this API and some might actually do track via an image etc.
Maybe we can add a URL parameter like
no_response=1? This would also make it easier to keep the tests easy as it allows us to still test for the gif and it allows other people to use this as well. Eg I'd like to use it in Mobile App
You could probably see its a JS request without changing the code. There are likely to be some HTTP header information that could be used. POST vs GET. I thought the gif noscript tracking only requested one path instead of a path with query, for example. Could be some AJAXy header also, for example.
Headers could get lost in proxies etc. and JS can use both POST and GET.
The noscript image solution sends a URL like this
//piwik.php?idsite=1. Of course I could test whether only the idsite is set and then still return an image, a 204 header otherwise. This would break the API for many users though who might expect an image and we don't want to break anything. It would be also a bit confusing / not predictable etc whether they'd get an image or not. Also we might want to send more parameters using the noscript solution in the future.
We could maybe send a header to not return an image and if the header gets lost it doesn't matter so much as the worst thing that happens would be sending an image that is not used. But then it is a bit simpler to send a URL parameter for this and people could use it anywhere, even where it is not possible to set a header. Also while it doesn't matter for the browser whether we send back a 204 or an image it might matter somewhere else.
+1 for a new parameter, it's easy to understand & document
Created issues to use it in iOS & Android SDK as well. Documented it in Tracker API reference. Not sure if something is missing! Will close it for now.
New URL parameter in Tracking API is