Increase cache TTL for assets

[strogonoff]

Since our frontend build now adds unique hashes to filenames, it is OK to let browsers cache most assets for a long time even if we iterate quickly and push out new website versions quite often.

We could make our website load faster this way.

Which assets this applies to

The following assets can be allowed to be cached (either by path prefix or file extension):

• File extensions — *.js, *.ttf, *.svg
• Paths (relative to glossarist.org site root) — /static/*, /templates/*

There is a high degree of certainty that any asset under those paths or with those file extensions will remain to be handled by website build process.

Unless I am mistaken, TTL seems to be None for those.

Where this does not apply

Below are examples of where we do not want to set TTL too long. These files do not have filename extensions and do not reside under global path prefixes mentioned above, so setting high TTL as described in previous section should not hurt these, but just for the record:

• index.html (obviously) and adjacent routeInfo.json files do not have hashes in their filenames.

• *.json files under /_in_app_help/ global path prefix do not have hashes in their filenames and might change. Those .json files are intended for consumption by desktop app’s built-in help as a kind of API, their TTL should be a couple of days at most perhaps?

• Documentation page illustrations. Those files (so far only .pngs) are currently copied adjacent to respective index.html files that reference them. Not expected to change, generally, but do not have hashes in filenames.

Reference

• https://web.dev/uses-long-cache-ttl/

• I would expect cache TTL to be controlled somewhere in CloudFront configuration