Uploaded image for project: 'Data Management'
  1. Data Management
  2. DM-6111

Browsers should cache editions for a shorter time period than Fastly

    Details

      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

          Hide
          jsick Jonathan Sick added a comment -

          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.

          Show
          jsick Jonathan Sick added a comment - 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.
          Hide
          jsick Jonathan Sick added a comment - - edited

          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).

          Show
          jsick Jonathan Sick added a comment - - edited 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).

            People

            • Assignee:
              jsick Jonathan Sick
              Reporter:
              jsick Jonathan Sick
              Watchers:
              Jonathan Sick
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Summary Panel