Default Cache-Control max-age=60 ?

[bestickley]

I just learned Next.js deafult Cache-Control for optimized images is 60 seconds (see docs)! Why would this be the default??? Why not cache for a year (or at least a longer time period than month)? Does anyone have good use case for why this should be 60 seconds? I think we should recommend in docs to increase this to larger number. Would save a lot of compute/cost since increasing cache TTL significantly decreases trips to origin from CloudFront.

[coltenkrauter]

So... I was sure that this must have been a code example, not a reflection on the actual behavior... But, then I found this code, which really looks like a default value of 60 seconds for image caching.

This seems related,

Static images are immutable. They receive a unique hash at build time. So if you change the image's content, the hash also changes, and a new request is made. So there is no point in low cache values.

Dynamic images, however, are not immutable, since they are nondeterministic (you can't be sure of their content). minimumCacheTTL is used to configure such dynamic images, not static.

I also found this which quotes old documentation,

If no max-age value is provided in a Cache-Control header returned by the image URL/path, a default max-age of 60 seconds is set. In turn, source images will be retrieved again and optimized on incoming requests if more than 60 seconds have passed since the last optimization of that image (in the same Edge Network node).

More conversations related to this here...

---

I want to clarify one point here (perhaps for future readers, this may provide helpful context).

I checked the headers on my Next.js prod build for a request for an optimized image, and it had this

cache-control: public, max-age=60, must-revalidate

Thanks to the etag, the browser will check with the server every 60 seconds to see if the image has changed. If it hasn’t, the server responds with 304 Not Modified, and the browser continues using the cached image without re-downloading it... forever.

This means unnecessary validation requests may happen every 60+ seconds, but actual re-downloads should be rare (only when the image changes.

All that said, I still think that 60 seconds is unnecessarily short for these freshness checks.

[bestickley]

Thanks for your research into this, @coltenkrauter. I didn't know about ETag. Still doesn't make a ton of sense for a project where you're optimizing images that won't change. You should be able to edit the Cache-Control header in middleware, but you actually cannot because _next/image requests are actually skipped in middleware. Fix was just merged into canary of 15.

[coltenkrauter]

Ah yes, I certainly think that something like this should be configurable. Especially with a default like that.

I'm glad that they are making the necessary changes.