Last reviewed by Netlify Support in May 2024
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
-
If it wasn’t intentional, you’d benefit from some changes to your build process. This can happen for a few unexpected reasons:
- 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!
- 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!
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.