I've recently seen a couple of Piwik installations that were not configured well in terms of caching static resources and Piwik ended up being much slower therefore. Like 400ms spent server side to load the initial page but then 2 or 3 more seconds just to load the resources even on repeat visit. So far it's basically been up to the user to configure a server correctly for static caching and there are projects like https://github.com/perusio/piwik-nginx that do this already I think (haven't actually checked whether caching is enabled there).

See for example

It would be nice to find a couple of ways to make this easier for users and I would differentiate three things here:

• Our minified / merged JS and CSS resources like Proxy.getJs and Proxy.getCss that have a cache buster parameter ?cb=34242432434 . This cache buster changes whenever something in Piwik changes so we can cache these resources pretty much for a long time. These files are actually served with Piwik via PHP and maybe we could remove the must-revalidate and send a max-age here so it doesn't even go to the sever again to avoid the 304. In the 304 we detect whether content changed this is slow. Optimizing this should already help a lot as they are quite big files and fetching them is slow.
• Static resources like *.js, *.css, *.html that have a cache buster parameter ?cb=34242432434 as well but they are not served via PHP. This cache buster changes whenever something in Piwik changes so we can cache these resources pretty much for a long time.
• Other static resources like images, fonts, ... with no cache buster. They have no cache buster parameter and can be maybe cached for a shorter time, etags can be used if server supports it, must-revalidate can be used etc.

One step would be to collect these kinda information, to write about it in the FAQ and to create smaller issues for individual tasks. Maybe we could later even have a system check that kind of checks whether resources are served from cache (we could maybe detect it eg via performance API and/or via service workers).

For installations that use HTTPS we could possibly add service workers see eg https://developers.google.com/web/fundamentals/getting-started/your-first-progressive-web-app/step-04?hl=en and https://jakearchibald.com/2014/offline-cookbook/ and cache the resources client side this way (eg if the server doesn't send proper cache headers or always). This would be independent of the server and make it easier to use and install Piwik. Because of the cache buster we should be able to correctly validate and invalidate all kind of resources. In development mode we could either disable the service workers or developers simply disable caching in development tools while developing. Also it doesn't work with self signed certificates, at least in chrome. It shouldn't be too much work to create the workers. In a more extended version we could detect whether a user is on a slow network or in power saving mode and in such a case serve more resources from service workers.

Any other thoughts?