It’s already great that the developers dropped the flash charts and replaced them with a javascript alternative, whiwch have a significally improvement of the loading speed of piwik. but I think piwik can do a lot better when it compressed it’s pages with gzip. It costs some server processing time, but the pages take less time to load. And while your compressing stuff, why not also compress piwik.js?
As well.
One more Vote: Yes for compress!
piwik.js compression is available through the proxy (i.e., replace “piwik.js” with “js/” in your tracking tag).
The reason we don’t compress output elsewhere is because the output isn’t static. Smarty templates are compiled and cached in tmp/templates_c, but we’re already taking a performance hit executing the compiled templates to generate the output. The second reason is because it’s tricky to do this within the app when there are so many other methods people have come up with that we have to try to detect and then disable compression in the app.
[quote=vipsoft]
piwik.js compression is available through the proxy (i.e., replace “piwik.js” with “js/” in your tracking tag).
The reason we don’t compress output elsewhere is because the output isn’t static. [/quote]
Understood and no problem that dynamic content may not be compressible or cacheable in practical terms.
BUT the static piwik.js could very usefully be performance optimized, e.g. :
a) support for local or CDN caching with “expires” (one year) and “etag” headers
b) file compression support with “piwik.js.gz” output + “Vary: Accept-Encoding” headers.
Not complicated, but surely a material performance boost?
Steve