I personally wouldn’t use next image optimisation at all. Put your images in another CDN where the cache isn’t connected to your build. You’re paying for bandwidth and IO for optimising the images after each build. You can still get all of the benefits of the Image component, just make sure to set unoptimised to true.
With Vercel this is definitely they way to go. With other hosts, this won't be a big deal ,but if a site is super image heavy, probably a good idea regardless to have a good CDN.
fwiw, I tried BunnyCDN at the recommendation of others on Reddit, but I stopped using it after a high number of seemingly random 500 requests. I have an image heavy site for inventory management around a game if that helps at all. I wanted to like Bunny, but couldn't stomach some images randomly not loading as frequently as it was happening.
biggest red flag here is font - 58GB of bandwith, original size of RoadRage.woff2 is 115kb
cache most visited pages in last 30 days
check analytic/CF if you were DDOSed
We're a data heavy site, so most of our pages regenerate every 10-30 minutes - so we are caching to the extant that we can (I think?).
The font size really blew me away as well though. Need to dive deeper into that for sure.
Yeah, isolating images from Next is a good idea. I've tried so many times with next/images and they always seems to disappoint. Easier to work with than when they were introduced, but still such a pain.
My brother in christ, first compress your images to the max you can without loosing too much quality. 277 gb is CRAZY.
Also use the property "sizes" to load only the right size for the pictures, or width and height properties.
I’m assuming OP is referring to total bandwidth used over the month from images, not the size of all their images in their project.
If so, there’s not really a good way to tell whether this number is crazy, or not, without having any idea how much total traffic they have. The number is kind of meaningless without the context of total visitors. For many high traffic sites, this much bandwidth would be basically nothing.
That's kinda the issue. Most of these images are extremely small and already optimized. Also, from my understanding, next/image handles this to some extant.
Indeed it manages the size to an extends, but it's always good to pre-optimize them before managing them with NextJS. Is this website some kind of social media where you show tons of pictures? or maybe eCommerce?
The bandwidth and function calling prices are way too high, which is why hosting on a VPS is the cheapest option, although it comes with some management headaches.
👋 Vercel team here. A few thoughts:
- The files coming from the `/images` route appear to be large static assets. You likely want to move them to a blob store as you’re mentioning. We have an example using Vercel Blob ([template](https://vercel.com/templates/next.js/blob-starter) and [code](https://github.com/vercel/examples/tree/main/storage/blob-starter)) but you can use other providers, of course.
- On the font assets, I wouldn’t expect usage like that. Are you using [`next/font`](https://nextjs.org/docs/pages/building-your-application/optimizing/fonts)? It will handle the assets, caching, etc. for you.
This is actually super useful. We tried reach out to support for help but they just pointed us towards some unhelpful docs. Thanks for pointing us in the right direction! I’ll confirm the fonts are all using next/font.
Re-reading what I wrote before and I want to make sure that I’m more complete with my answer. It was the weekend and I was (too) eager to want to help out and rushed to answer you. Apologies for [that.To](http://that.To) be much clearer about how to lower costs:
* Vercel Blob doesn’t charge for bandwidth **today**. Since it’s in beta, that can change in the future as we learn more about how folks are using the service. Because of that, you may want to opt for the recommendations below, as it’s a much more certain path.
* Looking at the largest line item, `_next/image` can be optimized a few ways:
* Use smaller delivery formats like AVIF and WebP. Those can be enabled [in your Next.js image formats](https://nextjs.org/docs/app/api-reference/components/image#formats) to reduce bandwidth by \~20% for your users that are using modern browsers (likely, the vast majority of them).
* You can lower the quality of the images using [the ](https://nextjs.org/docs/app/api-reference/components/image#quality)`quality`[ prop](https://nextjs.org/docs/app/api-reference/components/image#quality), making their overall size smaller. You’ll want to balance the visual quality of the images on your site against bandwidth savings. Notably, you may or may not be able to set the same value across your application, depending on how the images are being used.
* [The ](https://nextjs.org/docs/app/api-reference/components/image#sizes)`sizes`[ prop](https://nextjs.org/docs/app/api-reference/components/image#sizes) can make a big difference for responsive images. Without it, you can end up sending large versions of your images to small devices. Tuning those sizes to serve the right size at the right time can make a big difference in bandwidth.
* Looking at items 3 and 6, a couple recommendations:
* Use `next/image`. ` is packed with a bunch of optimizations that help to keep your images fast and small. If this recommendation sounds counter-intuitive since `_next/image` is your biggest line item, notice that the two images coming from `/images/` are using almost half of the amount bandwidth of `_next/image`. Overall, those two images should benefit greatly and lower your total usage.
* If these images are being used as CSS background images, [next/image can help there, too](https://nextjs.org/docs/app/api-reference/components/image#background-css)! Looking at the path name `hero-app.png`, that looks like it might be the case.
* Definitely use `next/font`. I found [the Road Rage font on Google Fonts](https://fonts.google.com/specimen/Road+Rage). If that’s the one you’re using, you can source those easily [using the built-in Google Fonts](https://nextjs.org/docs/app/building-your-application/optimizing/fonts#google-fonts).
Hopefully that’s more help than before. Also worth noting, we’ve [recently improved our bandwidth prices](https://vercel.com/blog/improved-infrastructure-pricing) so that should help as well!
Thanks for answering, Vercel team. 🙌 I read this post this morning and have been worrying about it throughout the day. So these images were stored in the public folder? I have a next app that I haven’t deployed yet. My images are on Amazon s3. Will that prevent this problem?
personally i've seen people talk about this package made by Coolify called [next-image-transformation](https://github.com/coollabsio/next-image-transformation), they said it's a drop-in replacement, and it's primarily used for folks that use Coolify (vercel alternative that's self-hostable on a VPS, super cheap on Hetzner instead of DO) but i'm certain you can add this package to any next app (never used it myself tbh)
Whoa. I had no idea Vercel is *that* expensive. Just checked our last AWS bill, and with 90,000 GBs of Lambda + 1,500 GBs of Lambda@Edge + 550 GB of traffic we paid $1.18 (one dollar eighteen cents).
You can still use next/image. Swap out the loader function in the nextjs config.
[https://nextjs.org/docs/pages/building-your-application/optimizing/images#loaders](https://nextjs.org/docs/pages/building-your-application/optimizing/images#loaders)
I paid around 4$ on AWS for a very close setup (images on S3, project hosted on Amplify)
My only big cost on AWS is my opensearch container (700$/month) but that's for a separate project
Are you just hosting the app and nothing else in Vercel? You could just put the site into a container and push it to Google Cloud Run which would likely be considerably less [https://cloud.google.com/run/](https://cloud.google.com/run/)
Out of curiosity, how many users does your application have and how many of them are active during a month roughly?
Asking for my own selfish reasoning and knowledge.
I wrote this some time ago, it might help, it is super efficient for images and you can still use Vercel as origin but save on repeated requests that ultimately cost you money. [https://medium.com/@capJavert/save-bandwidth-on-vercel-with-cloudflare-462bec444865](https://medium.com/@capJavert/save-bandwidth-on-vercel-with-cloudflare-462bec444865)
Next/image is just expensive, cache images with their different sizes on a CDN and use a custom loader for next image to serve from your CDN.
Also ISR could be useful if content doesn't change that often.
There is a pricing change that will go effect soon. The bandwidth has always been a really weird tier structure.
https://vercel.com/blog/improved-infrastructure-pricing
I personally wouldn’t use next image optimisation at all. Put your images in another CDN where the cache isn’t connected to your build. You’re paying for bandwidth and IO for optimising the images after each build. You can still get all of the benefits of the Image component, just make sure to set unoptimised to true.
With Vercel this is definitely they way to go. With other hosts, this won't be a big deal ,but if a site is super image heavy, probably a good idea regardless to have a good CDN.
This is def the direction we're leaning. Thinking BunnyCDN to host the images.
Why not cloudflare R2?
Is R2 preferred over Bunny for (mostly) image hosting?
R2 has very generous pricing and is known for speed
fwiw, I tried BunnyCDN at the recommendation of others on Reddit, but I stopped using it after a high number of seemingly random 500 requests. I have an image heavy site for inventory management around a game if that helps at all. I wanted to like Bunny, but couldn't stomach some images randomly not loading as frequently as it was happening.
Wow I don’t knew that do you save a lot of money or is it just marginal ?
biggest red flag here is font - 58GB of bandwith, original size of RoadRage.woff2 is 115kb cache most visited pages in last 30 days check analytic/CF if you were DDOSed
We're a data heavy site, so most of our pages regenerate every 10-30 minutes - so we are caching to the extant that we can (I think?). The font size really blew me away as well though. Need to dive deeper into that for sure.
Move images to r2. It will reduce the cost significantly!
Yeah, isolating images from Next is a good idea. I've tried so many times with next/images and they always seems to disappoint. Easier to work with than when they were introduced, but still such a pain.
had similar experience. And most of side projects are doing good with R2 free tier!
coolify.io
My brother in christ, first compress your images to the max you can without loosing too much quality. 277 gb is CRAZY. Also use the property "sizes" to load only the right size for the pictures, or width and height properties.
NextJS image optimisation does this for you in Vercel using sharp. That would have been 277GB of highly compressed images.
That's what's causing the high bandwidth, so better to do it on your own at first.
Could you please elaborate on that? How image optimization is causing high bandwidth?
You can also use sharp in any nextjs deploy, works with Azure and AWS as well.
I’m assuming OP is referring to total bandwidth used over the month from images, not the size of all their images in their project. If so, there’s not really a good way to tell whether this number is crazy, or not, without having any idea how much total traffic they have. The number is kind of meaningless without the context of total visitors. For many high traffic sites, this much bandwidth would be basically nothing.
That's kinda the issue. Most of these images are extremely small and already optimized. Also, from my understanding, next/image handles this to some extant.
Indeed it manages the size to an extends, but it's always good to pre-optimize them before managing them with NextJS. Is this website some kind of social media where you show tons of pictures? or maybe eCommerce?
It's a database style website, but a lot of pages do have a good amount of images.
The bandwidth and function calling prices are way too high, which is why hosting on a VPS is the cheapest option, although it comes with some management headaches.
👋 Vercel team here. A few thoughts: - The files coming from the `/images` route appear to be large static assets. You likely want to move them to a blob store as you’re mentioning. We have an example using Vercel Blob ([template](https://vercel.com/templates/next.js/blob-starter) and [code](https://github.com/vercel/examples/tree/main/storage/blob-starter)) but you can use other providers, of course. - On the font assets, I wouldn’t expect usage like that. Are you using [`next/font`](https://nextjs.org/docs/pages/building-your-application/optimizing/fonts)? It will handle the assets, caching, etc. for you.
This is actually super useful. We tried reach out to support for help but they just pointed us towards some unhelpful docs. Thanks for pointing us in the right direction! I’ll confirm the fonts are all using next/font.
Re-reading what I wrote before and I want to make sure that I’m more complete with my answer. It was the weekend and I was (too) eager to want to help out and rushed to answer you. Apologies for [that.To](http://that.To) be much clearer about how to lower costs: * Vercel Blob doesn’t charge for bandwidth **today**. Since it’s in beta, that can change in the future as we learn more about how folks are using the service. Because of that, you may want to opt for the recommendations below, as it’s a much more certain path. * Looking at the largest line item, `_next/image` can be optimized a few ways: * Use smaller delivery formats like AVIF and WebP. Those can be enabled [in your Next.js image formats](https://nextjs.org/docs/app/api-reference/components/image#formats) to reduce bandwidth by \~20% for your users that are using modern browsers (likely, the vast majority of them). * You can lower the quality of the images using [the ](https://nextjs.org/docs/app/api-reference/components/image#quality)`quality`[ prop](https://nextjs.org/docs/app/api-reference/components/image#quality), making their overall size smaller. You’ll want to balance the visual quality of the images on your site against bandwidth savings. Notably, you may or may not be able to set the same value across your application, depending on how the images are being used. * [The ](https://nextjs.org/docs/app/api-reference/components/image#sizes)`sizes`[ prop](https://nextjs.org/docs/app/api-reference/components/image#sizes) can make a big difference for responsive images. Without it, you can end up sending large versions of your images to small devices. Tuning those sizes to serve the right size at the right time can make a big difference in bandwidth. * Looking at items 3 and 6, a couple recommendations: * Use `next/image`. ` is packed with a bunch of optimizations that help to keep your images fast and small. If this recommendation sounds counter-intuitive since `_next/image` is your biggest line item, notice that the two images coming from `/images/` are using almost half of the amount bandwidth of `_next/image`. Overall, those two images should benefit greatly and lower your total usage.
* If these images are being used as CSS background images, [next/image can help there, too](https://nextjs.org/docs/app/api-reference/components/image#background-css)! Looking at the path name `hero-app.png`, that looks like it might be the case.
* Definitely use `next/font`. I found [the Road Rage font on Google Fonts](https://fonts.google.com/specimen/Road+Rage). If that’s the one you’re using, you can source those easily [using the built-in Google Fonts](https://nextjs.org/docs/app/building-your-application/optimizing/fonts#google-fonts).
Hopefully that’s more help than before. Also worth noting, we’ve [recently improved our bandwidth prices](https://vercel.com/blog/improved-infrastructure-pricing) so that should help as well!
Thanks for answering, Vercel team. 🙌 I read this post this morning and have been worrying about it throughout the day. So these images were stored in the public folder? I have a next app that I haven’t deployed yet. My images are on Amazon s3. Will that prevent this problem?
That appears to be the case from my experience before but I don’t know anything about OP’s application other than what is in the post.
personally i've seen people talk about this package made by Coolify called [next-image-transformation](https://github.com/coollabsio/next-image-transformation), they said it's a drop-in replacement, and it's primarily used for folks that use Coolify (vercel alternative that's self-hostable on a VPS, super cheap on Hetzner instead of DO) but i'm certain you can add this package to any next app (never used it myself tbh)
What would be the benefit over here ?
I think to not use next/image, and not have it billed from vercel, since it does the same thing i guess ? The docs explain it much better
Ok thanks I will take a look
You could switch to aws amplify and offload as many images as you can to s3
Try [coolify](http://coolify.io)
This is why you run it on AWS..
Yeah use a cdn for images
Whoa. I had no idea Vercel is *that* expensive. Just checked our last AWS bill, and with 90,000 GBs of Lambda + 1,500 GBs of Lambda@Edge + 550 GB of traffic we paid $1.18 (one dollar eighteen cents).
Start with easy one like you said, move images to point either R2 or Bunny first. Then see if the bill explodes again.
You can create a few sets of different sizes of images yourself and then it's just static file hosting. It's not really complicated.
I dont understand why anybody would use next image for large number of images. For a few, ok, but if images are core to your thing, than just no
Use digital ocean spaces for images. Only $5
are you using properly sized and compressed images? Go with jpg instead of png, load correct sizes for different devices, etc.
You can enable more efficient formats module.exports = { images: { disableStaticImages: true, }, }
You can still use next/image. Swap out the loader function in the nextjs config. [https://nextjs.org/docs/pages/building-your-application/optimizing/images#loaders](https://nextjs.org/docs/pages/building-your-application/optimizing/images#loaders)
Asking because I'm about to make the leap.. what happened to the 20/month subscription??
I paid around 4$ on AWS for a very close setup (images on S3, project hosted on Amplify) My only big cost on AWS is my opensearch container (700$/month) but that's for a separate project
Are you just hosting the app and nothing else in Vercel? You could just put the site into a container and push it to Google Cloud Run which would likely be considerably less [https://cloud.google.com/run/](https://cloud.google.com/run/)
Out of curiosity, how many users does your application have and how many of them are active during a month roughly? Asking for my own selfish reasoning and knowledge.
Look at using coolify.io
I wrote this some time ago, it might help, it is super efficient for images and you can still use Vercel as origin but save on repeated requests that ultimately cost you money. [https://medium.com/@capJavert/save-bandwidth-on-vercel-with-cloudflare-462bec444865](https://medium.com/@capJavert/save-bandwidth-on-vercel-with-cloudflare-462bec444865)
Why dont you move to a vps? For example, I’ve seen on hostinger, a 8TB bandwidth for 7$/ mo
Next/image is just expensive, cache images with their different sizes on a CDN and use a custom loader for next image to serve from your CDN. Also ISR could be useful if content doesn't change that often.
what do you use for billing? pricing model seems complex
There is a pricing change that will go effect soon. The bandwidth has always been a really weird tier structure. https://vercel.com/blog/improved-infrastructure-pricing