[Support Guide] Making the most of Netlify's CDN cache

Last reviewed by Netlify Support - August, 2023

Our CDN derives much of its efficiency from files whose checksums don’t change between deploys.

For instance, in a blog, you usually write or update one article in one file, while the rest of the content remains unchanged. In this typical use case, we don’t need to re-upload and re-process these files, since our CDN already has them stored - no checksums have changed except the one file. This also means that your visitors’ browsers don’t need to re-download any files, since they already have a cached copy of the latest version (see this article for more details about how our CDN handles browser caching for more details).

If you see perpetual deploy summaries with many files uploaded, like this:

…then you are probably not leveraging our CDN well AND your site probably takes far longer to deploy than it ought to.

So let me guess - you’re seeing that kind of pattern in your deploys, right?

  • If it was intentional, could you tell us what change you are expecting with such broad effects? We may have some advice to refactor a little bit and speed up deploys and browsing a lot :slight_smile:

  • If it wasn’t intentional, you’d benefit from some changes to your build process. This can happen for a few unexpected reasons:

  1. Perhaps your build process changes some filename which is included in each file? If so, don’t do that and your site will deploy much faster since we don’t need to re-upload the files - EXCEPT that single changed javascript file - which our caching mechanisms that are documented here will appropriately force browsers to re-download since it changed - but without re-downloading all of your unchanged content as well!
  2. Perhaps your build framework is trying to be helpful. Gatsby for instance uses asset fingerprinted filenames intentionally, which breaks Netlify’s usual caching. Here’s one way you can control that behavior in Gatsby.

A trick I use to “see what changed” is to download a copy of the deploy from its successful logs page. The icon pictured below will let you download a copy of that specific deploy.

Do this twice for two deploys that should be largely identical (e.g. 2 sequential commits to a branch), and then use a “diff” utility to see what changed. I bet it is a very small number of lines per file - and I further bet that you can change your build script to not create different filenames and avoid the re-uploads and speed your site up for return visitors at the same time! :slight_smile:

Note that some larger deploys may not be downloadable and you’ll see an error; in that case, our staff can try to find a file that shouldn’t change (you’ll specify what that should be - e.g. “only index.html should have changed in this build, so find any other html file”) and we can grab you a copy from each deploy to point out what changed.


Thanks for the explanation, @fool. By the way, I don’t set any additional hook, environment, prerendering, asset optimization, etc, on Netlify setting. Is that process above run automatically or I have to add more tweak?

@BayuAngora, the changes fool is talking about above are not automatic. This post is recommending that you do builds in a certain way, but it doesn’t go into detail about how to do this.

If every file is being changed with every build, we recommend modifying the build so that it no longer does this. However, what to change is not “one size fits all”. Different sites and static site generators (SSGs) will require different solutions.

This post is suggesting that, for example, the site build does not add a build hash to files or filenames. Netlify automatically hashes files and will automatically invalidate the cache of any files which change.

For sites deployed with Netlify, the hash of the page is tracked as using an etag header and, if there are any changes to any deployed file - Netlify invalidates any cache version files automatically - even versions in the local browser cache for people visiting the site.

Some build tools and SSGs add a unique hash to each page with the build id - even if the page would otherwise contain no changes. This is great if you want to force cache invalidation - but that is the point - with Netlify you don’t want to force cache invalidation.

If the files didn’t change, using the cached version will be the best user experience and give the best site performance. This is why we created this topic - to make sure sites are using our CDN/ADN caching in the best way possible.

If there are other questions about this, please let us know.

1 Like

Great detail explanation, @luke. It gave me more insight about Netlify build processing. Thanks.

1 Like