Details
-
Type:
Story
-
Status: Done
-
Resolution: Done
-
Fix Version/s: None
-
Component/s: Stack Documentation and UX
-
Labels:
-
Story Points:1
-
Epic Link:
-
Team:SQuaRE
Description
Currently we set Cache-Control: max-age=31536000 so that Fastly caches uploads from LTD Mason for a year on its POPs. This has the side-effect of also having browsers potentially cache documentation on the client for up to a year. In practice, browsers churn through their cache space more quickly, but I've noticed that Safari has no cap on its cache space, and therefore can hold onto pages for a long time.
The solution is to set a Surrogate-Control max age to 1 year, and have Cache-Control: max-age=0, private, must-revalidate. This will be done on LTD Keeper during the copy phase of a build into an edition (since it is reasonable for a client to cache a build forever), but then give us the flexibility to update an edition instantly.
In the future we may want a more nuanced solution where CSS and JavaScript, for example, are cached longer on the browser.
Attachments
Activity
Also discovered an issue with adapting S3 surrogate-key metadata to a proper header for Fastly.
Applied https://docs.fastly.com/guides/purging/setting-surrogate-key-headers-for-amazon-s3-origins for x-amz-surrogate-key (Fastly version #18).
This Fastly doc page gives an example of Cache-Control: no-cache, no-store, must-revalidate to force a browser not to cache content.
This Google doc page explains Cache-Control very well: https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching
Based on the Google doc, I think for editions Cache-Control: no-cache is appropriate. This allows browsers to have a cache the actual content, but then ask the Fastly if the content has changed via the ETag. While this triggers HTTP requests, it at least conserves bandwidth.