<p>With the correct cache busting, files can remain cached for as long as you like. Craft handles a lot of this for you.</p>
<p>I typically cache items for a year but do take caution to ensure every reference to assets within the site has a cache busting string on it. It's important to note that Cloudfront needs to be setup to use these query strings.</p>
<p>On the frontend, Craft appends an <code>mtime</code> attribute to the query string. If you ever replace an asset, the <code>mtime</code> is updated and subsequently a new cache is created.</p>
<p>Within the Craft CP, thumbnails of your remote images are generated rather than serving them from a CloudFront URL, generally there are no worries with caching here as Craft handles that.</p>
<p>Volumes with an expiry set will automatically load the <code>mtime</code> parameter when fetching the URL from Craft. Alternatively, you can implement your own cache busting with the <code>url()</code> function shown <a href="https://craftcms.com/docs/3.x/assets.html#example" rel="nofollow noreferrer">here</a>.</p>

CC BY-SA 4.0
2021-04-28T03:39:09.683Z
Thanks Matt. Do you have any links to or directions on the cache-busting? At the moment I have the S3 cache in Craft set to the default 3 hours.
Damien Buckley
CC BY-SA 4.0
2021-04-28T07:18:36.140Z
I've updated my answer to contain a link to setting up your own cache busting within Craft. However, given that you are already setting an expiry, the `mtime` attribute should be appended when you fetch the URL from Craft. You will likely need the Base URL and CloudFront distribution ID set to the corresponding values at CloudFront for that to work. I am unable to find any documentation to support that but [this answer](https://craftcms.stackexchange.com/a/1486/11869) seems to show the same thing.
Matt Banner
CC BY-SA 4.0
2021-04-29T01:51:05.143Z
Thanks again. So if the URL strings already have an mtime attribute (they do) I don't need to do anything?
Damien Buckley
CC BY-SA 4.0
2021-04-29T07:35:04.327Z
No problem, yes so long as CloudFront is setup to [cache query strings](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/QueryStringParameters.html). If you were to request `image.png?mtime=1`, CloudFront will cache that. If you then replace the asset within Craft, Craft will automatically adjust the value of `mtime`. No cache will exist at CloudFront for the new `mtime` so it will be re-fetched from the origin.
Matt Banner
CC BY-SA 4.0
2021-04-27T22:35:32.230Z
2021-06-08T07:35:37.123Z
2021-06-08T07:35:37.123Z
Matt Banner
<p>What does everyone consider a sensible cache duration to use when using Assets with S3/Cloudfront? Is 3 hours sensible or should it be longer?</p>
<p>Secondly, does this have any impact on the assets being displayed within Craft? Listing Asset directories takes a while due to my connection speed I'm sure but aren't these assets cached locally?</p>

<assets><s3>
Assets S3 Cache Duration and CP Thumbnails
# Assets S3 Cache Duration and CP Thumbnails

(Asked by: username_0 on 2021-03-31)

What does everyone consider a sensible cache duration to use when using Assets with S3/Cloudfront? Is 3 hours sensible or should it be longer?

Secondly, does this have any impact on the assets being displayed within Craft? Listing Asset directories takes a while due to my connection speed I'm sure but aren't these assets cached locally?

**Tags:** assets, s3

---

## 1 answers

### Answer by username_1 on 2021-04-27. Score: 1 | Accepted answer

With the correct cache busting, files can remain cached for as long as you like. Craft handles a lot of this for you.

I typically cache items for a year but do take caution to ensure every reference to assets within the site has a cache busting string on it. It's important to note that Cloudfront needs to be setup to use these query strings.

On the frontend, Craft appends an `mtime` attribute to the query string. If you ever replace an asset, the `mtime` is updated and subsequently a new cache is created.

Within the Craft CP, thumbnails of your remote images are generated rather than serving them from a CloudFront URL, generally there are no worries with caching here as Craft handles that.

Volumes with an expiry set will automatically load the `mtime` parameter when fetching the URL from Craft. Alternatively, you can implement your own cache busting with the `url()` function shown [here](https://craftcms.com/docs/3.x/assets.html#example).

> **Comments:**
> **username_0**: Thanks Matt. Do you have any links to or directions on the cache-busting? At the moment I have the S3 cache in Craft set to the default 3 hours.  
> **username_1**: I've updated my answer to contain a link to setting up your own cache busting within Craft. However, given that you are already setting an expiry, the `mtime` attribute should be appended when you fetch the URL from Craft. You will likely need the Base URL and CloudFront distribution ID set to the corresponding values at CloudFront for that to work. I am unable to find any documentation to support that but [this answer](https://craftcms.stackexchange.com/a/1486/11869) seems to show the same thing.  
> **username_0**: Thanks again. So if the URL strings already have an mtime attribute (they do) I don't need to do anything?  
> **username_1**: No problem, yes so long as CloudFront is setup to [cache query strings](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/QueryStringParameters.html). If you were to request `image.png?mtime=1`, CloudFront will cache that. If you then replace the asset within Craft, Craft will automatically adjust the value of `mtime`. No cache will exist at CloudFront for the new `mtime` so it will be re-fetched from the origin.  

---

