Caching files

The Rivet CDN uses a technique called caching for all files that it serves to users. Caching reduces the time required to load a website by saving the files locally on the user's machine. This is done via the Cache-Control header and is handled automatically; no additional setup is required by you, the developer.

Caching occurs on servers close to the user as well as on the user's own machine (handled by the browser).

For example, given a file at /my-script.js, when the user first requests this file it will downloaded and cached according to the Cache-Control header. For all subsequent requests, the file will be read from the users machine and not fetched from the server. For all subsequent requests from other users who have not downloaded the file before, it will be read from the cache saved on an edge node (a server close to the user).

Cache issues

Because the files are saved on edge nodes and the users machine, caching becomes an issue when you want to update the contents of a particular file. Because it is cached, the new file is never fetched from the CDN and thus it is not updated for the user until the cache expires. The reason this happens is because caching is based on the path of the file being downloaded, and includes the query string (e.g. ?foo=bar).

Query string solution

To mitigate this problem, you can use the query string of any particular file to signify a change to the files contents. In our above example, you can modify the path to be fetched to /my-script.js?version=1234.

<script src='/my-script.js?version=1234'></script>

Because the original request was cached with the path /my-script.js, the user's browser will attempt to fetch the file from our CDN instead of reading from disk.

Webpack solution

User's of webpack can utilize the [contenthash] feature during building. This automatically adds a hash to files being built and updates the links to them in your source code. Read more about it here.