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.js if 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 like piwik.js?version=abcunique123 because 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 async loading 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.
thomaszbz
commented
7 years ago
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:
The idea is to cache the
piwik.jsfrom an external server/domain:piwik.jspiwik.jsif updated or not in cachepiwik_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:
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.