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 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 the a “diff” utility the two 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!