-
Notifications
You must be signed in to change notification settings - Fork 26.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
next/image Cache-Control header does not match origin server #23562
Comments
Will hold on opening a PR until I've fleshed this out more, here is my WIP potential fix canary...aguilarm:image-maxage |
One big issue that |
Are there any updates on this issue? It makes no sense that NextJS forces browsers to revalidate immutable images over and over again. It really hurts visual performance of the app. Upstream origin cache-control header:
NextJS image cache-control header:
Here is the code sandbox demonstrating this issue - https://e6s3y.sse.codesandbox.io/ If you refresh the page multiple times, you can see that the top image (served from the upstream) is displayed instantaneously, while the bottom one (served via next/image) blinks before rendering. |
Duplicate of #19914 I'm combining all these issues as they're practically the same report |
These issues are not exactly the same... #19914 is requesting NextJS to respect custom |
This issue has been automatically locked due to no recent activity. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you. |
What version of Next.js are you using?
10.1.0
What version of Node.js are you using?
14
What browser are you using?
Chrome
What operating system are you using?
macOS
How are you deploying your application?
next start
Describe the Bug
The Cache-Control header for images generated by the next/image component are set to
public, max-age=0, must-revalidate
and do not match the origin server as described in documentation.Expected Behavior
Cache Control max-age should match the origin server.
To Reproduce
Use the Image component to generate a derivative image from a server that has a max-age value set.
The Cache-Control header for images generated by the next/image component are set to
public, max-age=0, must-revalidate
and do not match the origin server as described in documentation.I traced this behavior from this issue about custom headers to this issue concerning etags and finally this PR where Etags were added.
The Etag PR is really close but has opted to ditch forwarding the Cache-Control max-age value, and set it to 0 + must-revalidate. In small deployments, this isn't a big deal because with Etag working the server is not transferring the whole file repeatedly unless the file actually changes.
However, this means clients both rely on the next image server to be up to display images and ping it excessively. Ideally, both Etag and a high max-age let clients cache images as long as is reasonable and do not receive a new version of the file.
I have a PR incoming that saves the original maxAge value and forwards it out to clients. I need to add testing and would like a general gut-check. It seems like there is some potential to overhaul the image optimizer a little more to mitigate things like #23436 or the issue with custom headers from config being superseded.
The text was updated successfully, but these errors were encountered: