You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, all files served from https://interactive-examples.mdn.mozilla.net have a max age of 900 seconds (15 minutes). This includes both the embedded samples HTML and the static assets shared among samples.
Users will re-request any file after 15 minutes. If the file hasn't changed, CloudFront should send a 304 Not Modified, which is smaller and faster than sending the whole file. This also means it will take as much at 15 minutes for users to see changes to samples, asset, etc.
This is probably OK. However, tools like https://www.webpagetest.org will advise us that some assets, such as codemirror.js, should have longer cache times. 1 week is usually the recommended minimum, but web page test will accept down to 1 hour.
We can use very long cache times for files that never change. If the file does change, we can change the name, so that it is a different file. Some asset pipelines allow you to embed a hash of the file in the name to get this effect, and others embed a version in the asset name.
Different cache times for different assets will complicate publishing to S3 (we can't just use aws s3 sync), so I'd like to make sure we know what cache times we want for each asset before making the change.
Here's my proposal:
/pages - 1 minute (optimize for time to see new version)
/live-examples - 1 minute (optimize for time to see new version)
/media - 1 week (developer will need to change name to get new version). Includes:
media/clippy.svg
media/dino.svg
media/example.svg
media/firefox.png
media/fonts/FiraSans-Bold.woff2
media/fonts/FiraSans-ExtraBold.woff2
media/fonts/FiraSans-Italic.woff2
media/fonts/FiraSans-Light.woff2
media/fonts/FiraSans-Regular.woff2
media/fonts/FiraSans-SemiBold.woff2
media/fonts/FiraSans-SemiBoldItalic.woff2
media/warning.svg
/css/codemirror-5-31-0.css - 1 week
/css/css-examples-libs-1-8-4.css - 1 week
/css/editor-css.css - 1 minute
/css/editor-js.css - 1 minute
/js/codemirror-5-31-0.js - 1 week
/js/css-examples-libs-1-8-4.js - 1 week
/js/editor-css.js - 1 minute
/js/editor-js.js - 1 minute
With this proposal:
/pages, /live-examples, and /media will be synced
/css and /js will be transferred file-by-file, and the sync script will need to be updated when files are added or removed.
If you anticipate often adding or removing assets in /css and /js, then you'll need to split them into /css and /js (1-minute cache) and /css-lib and /js-lib (1-week cache). Different folders will allow us to use sync to upload them.
The text was updated successfully, but these errors were encountered:
This continues the work started in #311
Currently, all files served from https://interactive-examples.mdn.mozilla.net have a max age of 900 seconds (15 minutes). This includes both the embedded samples HTML and the static assets shared among samples.
Users will re-request any file after 15 minutes. If the file hasn't changed, CloudFront should send a
304 Not Modified
, which is smaller and faster than sending the whole file. This also means it will take as much at 15 minutes for users to see changes to samples, asset, etc.This is probably OK. However, tools like https://www.webpagetest.org will advise us that some assets, such as codemirror.js, should have longer cache times. 1 week is usually the recommended minimum, but web page test will accept down to 1 hour.
We can use very long cache times for files that never change. If the file does change, we can change the name, so that it is a different file. Some asset pipelines allow you to embed a hash of the file in the name to get this effect, and others embed a version in the asset name.
Different cache times for different assets will complicate publishing to S3 (we can't just use
aws s3 sync
), so I'd like to make sure we know what cache times we want for each asset before making the change.Here's my proposal:
With this proposal:
If you anticipate often adding or removing assets in /css and /js, then you'll need to split them into /css and /js (1-minute cache) and /css-lib and /js-lib (1-week cache). Different folders will allow us to use sync to upload them.
The text was updated successfully, but these errors were encountered: