Uploaded image for project: 'Moodle'
  1. Moodle
  2. MDL-57789

Use Cache-Control: immutable

    XMLWordPrintable

Details

    • MOODLE_32_STABLE
    • MOODLE_33_STABLE
    • m33_MDL-57789_Add_Cache_Control_Immutable_Support
    • Hide

      (difficulty: easy, requires teacher access to a course of two Moodle properly configured instances, one being fully HTTPS)

      1. When browsing the instance both as guest and as teacher each Moodle page should be correctly styled and no image should be missing
      2. Components serving files like SCORM or a File System repository should be attended and navigated up to their contents w/o any issue (regressions)
      3. When using the Moodle instance under HTTPS with Firefox, latest update (49+), if you open the Developer Tools (F12) and look at the network tab while htting F5 (Refresh) you should find no HTTP 304 hits to any of the theme related files (CSS, JS, GIF/PNG/SVG) i.e. only HTTP 200 w/ a clear indication about the content being cached. HTTP 304s could appear when browsing some components like a SCORM activity when attended it the n-th time (where n > 1) or some other blocks.
      4. More on regressions: repeat the test in MDL-39832, if you want to be sure that partial content serving is still working
      Show
      (difficulty: easy, requires teacher access to a course of two Moodle properly configured instances, one being fully HTTPS) When browsing the instance both as guest and as teacher each Moodle page should be correctly styled and no image should be missing Components serving files like SCORM or a File System repository should be attended and navigated up to their contents w/o any issue (regressions) When using the Moodle instance under HTTPS with Firefox, latest update (49+), if you open the Developer Tools (F12) and look at the network tab while htting F5 (Refresh) you should find no HTTP 304 hits to any of the theme related files (CSS, JS, GIF/PNG/SVG) i.e. only HTTP 200 w/ a clear indication about the content being cached . HTTP 304s could appear when browsing some components like a SCORM activity when attended it the n-th time (where n > 1) or some other blocks. More on regressions: repeat the test in MDL-39832 , if you want to be sure that partial content serving is still working

    Description

      Facebook suggested a new cache control header because they use a very similar system to Moodle for serving long lived css/images/css but were still finding 20% of their requests were a result of browser refreshes that returned 304 not modified. By adding this header, the browser will never check the same resource twice. This is appropriate for many parts of Moodle as a new unique url will be generated whenever the cache is purged.

      https://hacks.mozilla.org/2017/01/using-immutable-caching-to-speed-up-the-web/

      https://bitsup.blogspot.co.uk/2016/05/cache-control-immutable.html

      Chrome appear to have effectively decided to opt all resources into this, which should have a similar impact for the urls we'd want to add the header to, but may cause some other corner cases to not refresh.

      https://blog.chromium.org/2017/01/reload-reloaded-faster-and-leaner-page_26.html

      This may also help with situations I've seen where Moodle server problems can cause an avalanche of reloads as users all try to get it to work by repeatedly refreshing the page, and make the problem worse in a vicious cycle.

      IETF draft document: https://tools.ietf.org/html/draft-mcmanus-immutable-00.

      Attachments

        Issue Links

          Activity

            People

              matteo Matteo Scaramuccia
              bawjaws David Scotson
              David Mudrák (@mudrd8mz) David Mudrák (@mudrd8mz)
              Andrew Lyons Andrew Lyons
              Jun Pataleta Jun Pataleta
              Votes:
              6 Vote for this issue
              Watchers:
              13 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:
                15/May/17