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

Browsers should cache editions for a shorter time period than Fastly

    XMLWordPrintable

    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

          No builds found.
          jsick Jonathan Sick created issue -
          jsick Jonathan Sick made changes -
          Field Original Value New Value
          Epic Link DM-5858 [ 23985 ]
          jsick Jonathan Sick made changes -
          Status To Do [ 10001 ] In Progress [ 3 ]
          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).
          jsick Jonathan Sick made changes -
          Story Points 1
          jsick Jonathan Sick made changes -
          Resolution Done [ 10000 ]
          Status In Progress [ 3 ] Done [ 10002 ]

            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:

                Jenkins

                No builds found.