#Caching image transformations from remote URLS

4 messages · Page 1 of 1 (latest)

blazing wasp
#

Hi there,

I'm a bit confused about the expected behaviour for building a site / generating images using an external API to build out a site.

I've tried using the images as is, tried Cloudinary.

https://dev-conorbiddle.pantheonsite.io/wp-content/uploads/2019/11/IMG_20191022_160910-1050x1400.jpg

https://seansmyth.ie/wp-content/uploads/2022/04/Gemma-Dunleavy-at-3Olympia-Theatre-on-1-04-22-by-Sean-Smyth-1-of-45-670x445.jpg

https://res.cloudinary.com/conorbiddle/images/w_1050,h_1400,c_scale/f_auto,q_auto/v1689363632/IMG_20191022_160910/IMG_20191022_160910.jpg?_i=AA

But every time I run the build, the images get rebuilt every single time. This results in large build times. 14 mins (for a 4 page site is a lot.)

I've asked in #general before and Astro is to respect the cache-headers but if you check those links, there does seem to be cache-headers in place (at least I think so!)

Is this expected? I thought Astro would be able to cache these generated images and keep them from build to build.

I've tried Netlify, DeployHQ and Buddy. Nothing seems to "cache" the build.

I'd appreciate your thoughts on this as I'm not sure how large sites do this? How would a large blog or something deal with this?

Thanks

honest shadowBOT
#

Hi @blazing wasp. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:

#

Astro does provide caching mechanisms to speed up the build process, especially for large websites. However, these mechanisms are primarily designed for content collections and not specifically for images.

Astro introduced Incremental Content Caching as an experimental feature in Astro 4.0 to reduce the amount of duplicate, unnecessary work done inside the astro build command. This feature hooks into the Content Collections API (https://docs.astro.build/en/guides/content-collections/), allowing Astro to track changes inside of a collection using an internal build manifest. Astro can then check the cache on each build and reuse unchanged content entries. This feature was first introduced in Astro 3.5 under the name “Content Collections Build Cache” and remains experimental in 4.0. You can enable it by adding experimental.contentCollectionCache: true to your Astro configuration.

For images, Astro provides an Image Services API to connect Astro with third-party image services like Cloudinary or Vercel. This API contains a collection of hooks that can control image handling inside of Astro. However, it doesn't seem to provide a built-in caching mechanism for images.

In one of the GitHub issues you mentioned, a user reported that original images were being stored in the cache folder after running astro build, which was slowing down the deployment process. However, a member clarified that Astro doesn't cache the original images, only the transformed versions, to avoid redoing the transforming step.

If you're experiencing long build times due to image transformations, you might want to consider optimizing your images before deploying them or using a third-party image service that provides on-the-fly image transformations.

#

Sources:

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: