Skip to content
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

feat(netlify): Implement caching for static assets #97

Merged
merged 1 commit into from
Dec 24, 2024

Conversation

peerless-hero
Copy link
Contributor

Description

This pull request configures long-term caching for assets in the /assets/ directory.

It adds a [[headers]] section to the netlify.toml file to set the Cache-Control header with a max-age of one year for all files under /assets/. This will improve website performance by leveraging browser and CDN caching.

Linked Issues

Additional context

Doc:
https://docs.netlify.com/routing/headers/
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control

@peerless-hero peerless-hero force-pushed the perf/enable-asset-caching branch from a5f1643 to 8186b5c Compare December 23, 2024 14:51
@antfu
Copy link
Owner

antfu commented Dec 24, 2024

Hmm, I am not so confident about that. The asset folder also contains JS bundles; even if it has a hash in the filename, I am still worried that a strong cache will cause some outdated JS to be executed that results in the site breaking.

@peerless-hero
Copy link
Contributor Author

Hmm, I am not so confident about that. The asset folder also contains JS bundles; even if it has a hash in the filename, I am still worried that a strong cache will cause some outdated JS to be executed that results in the site breaking.

Thank you for your reply! I think we all share the same consensus that for any files packaged under the same project, as long as they carry the same hash value, the content must be identical. This is one of the main reasons we use content hashing.

For example, with a JavaScript file, let's say we have a file named app.abcdef123.js that previously had a bug. If we fix this bug and repackage it, the new file name will change to app.ghijkl456.js, which means the browser will request the new file instead of using the cached old version.

If the strong cache is set for too long, users might continue to use the old app.abcdef123.js file for a while, leading to them encountering the bug during use. However, due to the change in the hash value, users will automatically receive the updated version when accessing new content.

I’m curious if you have encountered similar situations or if you have any other potential scenarios in mind where things might go wrong.

@antfu
Copy link
Owner

antfu commented Dec 24, 2024

Alright, I guess it would be fine. Thanks

@antfu antfu merged commit 4e1e8b0 into antfu:main Dec 24, 2024
@peerless-hero peerless-hero deleted the perf/enable-asset-caching branch December 24, 2024 07:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants