Cache piwik.js server-side #260
Description
We are serving piwik.js from the source given by configuration (e.g. other domain or subdomain). Serving is done asynchronically for piwik.js so that it should already be served non-blocking.
That's working and fine so far, but still leaves potential for further improvements:
- Changes in piwik.js do not make it to the user instantly as there is no reason for browsers and proxies to fetch an updated version (caching (hopefully) enabled but URL cannot change). The use of ETag, however handles this eventually.
- Maybe save requests by merging with TYPO3-site javascript. Plus, improving compression.
- Connecting to another domain requires a new tcp connection and (if used) another SSL/TLS handshake.
The idea is to cache the piwik.js from an external server/domain:
- Check for updated version of
piwik.js - cache the new
piwik.jsif updated or not in cache - serve piwik.js with a distinct name for a distinct version (e.g.
piwik_abcunique123.js). Hereby not using URL parameters likepiwik.js?version=abcunique123because this is sometimes interpreted as dynamic content which itself could avoid browser caching.
Enabling/Disabling this strategy should be made configurable, while we should default to the existing strategy which is quite failsafe at least.
Intended result:
- Have a working chaching strategy which still offers instant updates for new versions.
- Speed up page loading (user will not benefit a lot here, as we use
asyncloading already).
TYPO3's infrastructure already allows to integrate external javascript files (via typoscript) and have them cached via TYPO3's caching framework. TYPO3's compressor can do the merging and serves the compressed version with a unique file name. Maybe we can reuse this. For that case we still have to test if TYPO3 somehow pulls updated versions.
Needs to be tested if it really improves something.
This could be done for google analytics in a similar manner.