Deployment no longer adding CDN to image src path

Previously when doing manual deployments (Early Dec 2024) the src path in the html code for image files would automatically have the CDN url injected “…” and the images added to the CDN. Deploys since the beginning of January now no longer have the CDN url added so the files are being served directly each time leading to 7x bandwidth usage.



src=“” (fake example)

I know that asset optimizations were discontinued in October but I didn’t see anything in the announcement that said no longer would the images be added to the CDN and no longer would the src paths to the CDN be updated in the code during deployment.

Is there an issue on my end? Or has that process been discontinued? I’m confused on how the asset optimizations were discontinued in October 2024 yet my site continued to inject the CDN url into the image src patch until at least early December 2024.

I thought Netlify handled the image caching on their CDN as part of the service. If so, do I need to add a build step to inject the CDN url into the src path for the images in the html code during deployment? I’ve searched all over and I’m not sure what I’m missing here.

In early December Netlify deploys were adding images to the CDN and injecting the url into the image src path in the html code. Now the CDN url is not injected and all images are served directly leading to high bandwidth usage. Without the CDN urls being injected into the images src path the site uses about 45 GB data per day and when it was working the site used 7 GB per day.

Any advice is greatly appreciated. I’ve got to be missing something here.

Image processing was a part of post-processing, so that’s disabled as well. Simply changing the URLs to Cloudfront did not mean we cached them separarely. We still cache them the same way regardless of the URL.

You can switch to Netlify Image CDN: Netlify Image CDN | Netlify Docs.

How are other users linking their images to the cached files on the CDN automatically? Is that a build step? Or do users now have to use Netlify Image CDN in order for a website to serve images from the CDN?

Even though Netlify is caching the images during deployment my bandwidth is now 7x higher when the src of an image is served directly from the site like src=“/images/file.jpg”. Up until December Netlify’s system would automatically add the link to the src path even though the image post-processing supposedly stopped in October.

If all the image src paths in the html code looks like src=“/images/file.jpg” will the files still be served from the Netlify CDN automatically? Or does the CDN url have to be in the src path in order for the images to be served from the CDN? Or must I now switch over to using Netlify Image CDN if I actually want the images on the website to be served from Netlify’s CDN cache.

Bottom line is that the bandwidth has skyrocketed and the only difference is if the CDN is added to the src path of the image. Without the CDN in the url of the image src path my bandwidth usage is 7x normal.

All assets are always served from the CDN. Cloudfront !== CDN. Cloudfront or not, the assets are being served from the CDN.

If your images are not being compressed, I think this is expected.

Turns out, it was not “completely” stopped and was still silently running on some sites. That “bug” was fixed which is why you might have started seeing the change.

Yes. Everything that’s deployed to Netlify is served from the CDN.

The Image CDN is only for optimising images on the fly. Instead of compressing your images during build time that post-processing did, now it’s done on-the-fly with the Image CDN.

I understand, but to put this in other way, you were unknowingly saving bandwidth for a few extra weeks due to the mentioned bug, but other than that, we had issued a warning for quite some time that post-processing is going away. Now, you can either compress the images yourself so they take up less space and thus, less badnwidth or use the Image CDN to do that.

I really appreciate the detailed response as that clarifies the situation.

All images have been compressed and run through an optimizer but I will explore options for improving that, as well as considering the Image CDN.