When GLAMkit sites use S3 to store and serve image assets, these images should be set to be cacheable downstream by setting the appropriate Cache-Control headers. This is especially the case for thumbnail images.
At the simplest level we could possibly adapt the image/thumbnail storage S3 backend to set Cache-Control header values to at least permit in-browser caching of these objects.
A more robust but complicated solution might be to use CloudFront in front of assets like this, to benefit from a more distributed CDN-ish approach. This could also help if image assets like thumbnails are not set for public-read in S3, and therefore require ever-changing signed URLs to access them.
Overall we also need to be careful about permitting image assets to be cached for too long based on only their URL path, which could potentially remain the same despite changes in the underlying image, such as if an ICEkit image file is updated in-place, but the human name remains the same and therefore the derived thumbnail image path does not change. Fixing this properly would likely involve using, or including, in the thumbnail path a hash value based on the data content of the image file.
When GLAMkit sites use S3 to store and serve image assets, these images should be set to be cacheable downstream by setting the appropriate
Cache-Control
headers. This is especially the case for thumbnail images.At the simplest level we could possibly adapt the image/thumbnail storage S3 backend to set
Cache-Control
header values to at least permit in-browser caching of these objects.A more robust but complicated solution might be to use CloudFront in front of assets like this, to benefit from a more distributed CDN-ish approach. This could also help if image assets like thumbnails are not set for public-read in S3, and therefore require ever-changing signed URLs to access them.
Overall we also need to be careful about permitting image assets to be cached for too long based on only their URL path, which could potentially remain the same despite changes in the underlying image, such as if an ICEkit image file is updated in-place, but the human name remains the same and therefore the derived thumbnail image path does not change. Fixing this properly would likely involve using, or including, in the thumbnail path a hash value based on the data content of the image file.