Last reviewed by Netlify Support: April 2024
Netlify does not want to make money charging you for unnecessary bandwidth overages. Our Starter plans come with 100 GB of bandwidth included. We’ve found over time that this allotment is more than sufficient for most non-commercial websites. What you may not realize is that we don’t want to make money this way - we intend to be a business focusing on collaboration tools and we provide web hosting to achieve that goal - so we don’t want you to waste your money on bandwidth, either!
However, suppose you’ve found yourself with an unexpected bandwidth bill from Netlify for exceeding the 100 GB in a given month. Your site doesn’t get a lot of traffic. So, what could have caused this, and what can you do to prevent future surprises?
There are a few areas that you can investigate and perhaps adjust to minimize bandwidth usage. This Support Guide will walk through various reasons your bandwidth usage may be high, as well as ways to reduce your usage without reducing traffic. Let’s dive in!
Did you know you can see the bandwidth breakdown on a per-site basis in the Netlify admin UI? Check it out by going to Billing > Current services > Team plan and clicking the caret down icon. This information updates in near real-time!
Adjust your images
If you have many images, videos, and animations on your site, it is a good idea to ensure that your files are appropriately sized in order to keep bandwidth usage low. This can be done manually as well as through the use of our Image CDN. One of the benefits of using the Image CDN is that you can specify defaults like file size, format and quality. Doing this will help you automate the process of optimizing your images. For more details on how to configure the Image CDN, take a look at our docs.
For additional context, here are a couple of articles that talk about image optimization in more general terms:
- For image optimization: https://www.shopify.com/blog/7412852-10-must-know-image-optimization-tips
- For video optimization: https://www.smashingmagazine.com/2021/02/optimizing-video-size-quality/
- Choosing the right image formats can give major returns! http://slides.com/verythorough/speedy-images can show the way.
Modify your caching settings
Another way to reduce bandwidth usage is changing fewer files per build where possible. Changing fewer files per build means that browser-based caches can cache more, more effectively.
Our CDN tries very hard to make optimal use of browser caches. This Support Guide discusses how to get the most out of our CDN cache, by building your site smarter. Some people or frameworks decide they want to override our default caching, which we allow you to do - but we suggest you do not, without good reason. This blog post explains why you should not increase the cache timeout natively, but it is also worth considering not changing it at all (unless you have a very specific use case): Better Living Through Caching
Lazy load images and resources
It’s a web best practice to load images and other resources as-used, rather than all upfront. For example, imagine you have an online product catalogue. You won’t want to load all images in your catalogue at once. Instead, you create pages of products and allow your visitor to load additional items, along with their associated images, as-needed or when clicking through to the next page.
One of my colleagues once reduced his monthly usage by a terabyte by changing his event calendar to load no images at first, and only load images of a selected event upon request. This increased the usability of his site, too - the pageload went from >100MByte with hundreds of images down to a few MByte with no images on first load. The page loaded about 30 seconds faster on the average mobile client! This is also true for other resources, such as JSON files that you may load once per product; don’t load dozens with every pageview if you don’t need to.
Watch your monitors
Another way to reduce bandwidth usage is to make a tiny file called /status.txt that contains the text “OK”, and just monitor that file for that string. Loading 2 bytes every minute will not add up to 100 GB over the course of a month. Setting up availability monitors is also popular way to get notified if your site goes down or has loading trouble. However, you’ll want to watch out as those monitors can load huge amounts of data unnecessarily!
Synthetic and Real User monitoring are test types that perform one or more full page loads. While this could be useful to measure, if you are looking to determine uptime, taking this measurement at a high frequency is not ideal. Alternatively, you could consider doing one of the following:
- Choose to load less, or load less frequently - eg. check every 10 minutes instead of every minute.
- Choose only the region where most of your customers are, rather than several regions, to load on a schedule.
- Use the Lighthouse Build Plugin to test your site upon deploy
In the end, you control how much data is used, so configure your monitors wisely!
Consider situations in which caching doesn’t help
It is the case for both synthetic/real user monitoring, and for our prerendering service, caching is a bit more interesting. In these cases, there generally isn’t a single browser making each request; instead, it’s a new instance of the browser each time, for each URL. In this case, you are penalized for monitoring 2 pages in a way a human visitor using a single browser instance wouldn’t be. The human visitor loads all of your dependencies from the first URL, and those are cached for reuse with the second URL. Essentially, if it is the same URL across both pageloads, resources will not be loaded twice due to our default caching behavior .
If much of your page traffic comes via social sharing (i.e. sharing a direct URL to your site), or if you must monitor 10 pages on the same site, what can you do to minimize the impact? Since both of these types of services can require loading all resources with each pageload (prerendering caches by URL, so reloading the same page quickly on facebook shouldn’t cost you money; but if your site has 100000 URL’s, they all have to be fully loaded and cached separately), look to optimize what must be loaded. For instance:
- Minify your Javascript.
- Don’t include large “common” files which aren’t used (perhaps you can use a subset of jquery as described here, rather than loading the whole thing and using very little of it): https://stackoverflow.com/questions/1333465/is-it-possible-to-extract-a-subset-of-jquery
- Don’t include wrong-sized images that you scale down to display.
- For catalogue sites and other potentially long lists of content, try not to include your entire catalog/all items in the listing on each pageload.
- Consider doing some “conditional” loading for these monitors; they typically use a standard User-Agent HTTP request header, and your code can use a pattern like this to not load a “heavy” section of a page (e.g. “items 10-999 in the catalog” or “our support chat widget”) when a link is shared via Facebook or any other social service which supports Netlify’s prerendering:
const isPrerender = /HeadlessChrome/.test(window.navigator.userAgent)
if (!isPrerender)
{ // do load our helpdesk chat widget in this case }
Note that if your site does not use Netlify’s prerendering service, our usual caching takes care of most of this for you - so, if you don’t need prerendering for your site to function turning it off might save you appreciable bandwidth!
Onwards and downwards
We hope the tips in this guide help you reduce unexpected bandwidth usage. There are a variety of options for you to reduce unnecessary bandwidth usage! If you have further questions, please open a thread in our Forums so that we can further discuss options.
, Netlify’s image optimization feature by default, delivers WebP images, an image format with wide browser support that usually generates smaller files than PNG or JPG, if the browser supports it. You can configure the supported image formats in your