[Question] related to: Making the most of Netlify’s CDN cache – how to mark as «has not changed»

[jones]

Hi there
I just read this post:

[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 …

And I wanted to add a question there, but the post was already closed. I wondered if there is anything I could improve in the following setup regarding using netlify’s cache, or if that is already handled.

We have a headless WordPress installation, that is used with vue.js and nuxt.js.
We built a custom fetcher that, on each build, first fetches the data from the WP REST API, saves it into .json files and then generates all the static html files for each post/page.

In the post above it is mentioned that for files that are not reuploaded the cache would be used.
But in our case those files are created during the build.

Is there a way to mark to netlify which of these files have been unchanged?
Normally maybe just a handful of posts have a content that has changed and hundreds of other posts are exactly the same and will result in the same generated .html files.

I know that this setup is a bit different from what is described in the post, but I face the issue that the post processing is taking quite some time (although I almost shut it off completely) and I assume it is because netlify is scanning all the new files, although they are probably exactly the same as the 10 deploys before…

Thanks in advance on any inputs.
Completely different approaches to this problem are of course as well appreciated.

Cheers

[fool]

No way to mark them explicitly, @jones - what our system thinks is changed is just “files that don’t have new checksums from any previously deployed files”. So make sure your files don’t end up with datestamps or other changes. You can see what’s changed by doing 2 builds in a row locally in different directories and then using a tool like diff -r to show the differences.

So - if we are scanning the files again - the checksums have changed.