I just rebuilt my personal photography website with Astro. It has around 500 unique photos in JPG format. I generate AVIF and WebP in multiple sizes for responsive image sizing. The build generates close to 10,000 image variants in total, which is a lot, but not unreasonable for the amount of images I have. I've already cut down the number of variants I generate in the srcset, reducing the number of variants further is not viable.
The problem is that the build takes a long time. The site is fully static is hosted on Cloudflare Pages. The build on Pages timed out after around 35 minutes (there's a soft cap of 20 minutes, so that's to be expected). Now I build and deploy the site through GitHub actions. The build takes a bit over one hour, 99 % of that are the image variants being generated. While this works, I'd like to optimize the build time.
I've already implemented caching in the GH Action via the actions/cache action. This caches and restores the .astro folder (see the GitHub Action below). However, that doesn't really move the needle – it's still generating all the images in every build. I don't think the generated image variants are cached in the .astro folder at all, because the cache size indicated by the action is tiny, just a couple of kilobytes. Can someone confirm if that is expected?
The main problem is that every build regenerates all variants every time, even though 99 % of them are identical between builds. But I haven't really found a solution for that.
I know I could deploy the site on workers instead and have the images generate on request. But the site is completely static and often doesn't change for months on end. Running workers and dynamically generating everything is completely unnecessary and a waste of energy. Same with outsourcing the image hosting to an external service like S3 or whatever.
Is there any way to implement incremental builds and reuse image variants between builds? Or a different approach altogether?